Requests for a feature that would allow loading JavaScript (and also CSS) on a per-page basis using wikitext have been requested for a while (T8883) to avoid loading large JavaScript files on pages that don't need them.

Use case?

I think it's important in software development, especially at our scale, to start conversations about new products and features like these with a concrete user-facing problem rather than an internal-facing solution about how a certain implementation might provide a puzzle piece that others can use to solve problems that are never described or known to developers.

It would help to focus first on specific end-user needs as they relate to presentation of knowledge and other content, and/or as they relate to editor workflows for creating or reviewing content etc.

Can you provide an example of where youd like to use this? What is the use case you would like to see solved and why? Based on that, we can find an appropiate technical solution. It might look similar to what is proposed here, or it might look very different internally but work all the same or better for you. It might end up solving other use cases that would be powered by "UseResource" but not per-se. It's possible that it might be better to solve some of the use cases another way.

Gadgets?

There are a lot of factors to consider with a change like this and if the conversation starts with "we want this very specific technical change" then we can either do it or not do it, and in that case I think it's likely the the answer will have to be "we can't do it", which doesn't help anyone :)

I love gadgets and produced a fair number myself, but the deeper they are integrated with content, I find, generally the more inaccessible and re-usable the knowledge and content becomes, and the worse the user-experience becomes as well. Such deep integration encourages creation of content with a high dependence on client-side JavaScript. Promoting the false idea that it is okay for content to be interdependent on execution of such JavaScript code. Thus not realizing that on less stable internet connections or computing devices, that these scripts may not ever arrive in time and thus leave gaps. Thus not realizing that content is also used outside our projects such as in Kiwix offline readers, mobile apps, IPFS via offline dumps, Siri, Apple Dictionary Look up, and so on. These contexts cannot and should not involve execution of JavaScript. Gadgets also tend to load lalter and thus cause flickering orr re-drawing of content. I think a certain amount of indirection is generally beneficial to encouraging conversations to happen about what a specific tool is meant to do, and how it could be solved more generally at scale, at least to try to have those proposals come to light more often.

If a solution has to involve client-side JavaScript, though, as a gadget, then per my comments at T63007, it would be better to at least not hardcode such references directly in wikitext and that (like above) I think makes it too easy to assume scripts are non-optional and makes the content also harder to re-use outside our projects. I proposed a more progressive solution where certain enhancements can be enabled via the Gadgets extension based on e.g. a category association. Which can be changed over time without editing every page individually.

The most recent use-case I can think of is when some editors wanted to add some rich content to articles about chess, using a script-based chess viewer that would appear on a very small set of overall articles. We declined the proposed solutions on-wiki as bad design, as even the "lightest" version would require running a script on every page load to check for some trigger to then load more scripts, and this was not a sustainable model for anyone who wanted to add script based rich content. (c.f. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_132#PGN_viewer_1). The script-loader script design would become cumbersome and fragile to maintain as small use-cases grow.

I envision all of these use cases to be for rich content additions, not for presentation of core information to viewers - anymore then any other site-local scripting should be.

The chess example sounds like better implemented via an extension, like ChessBrowser ?

@Aklapper so in general I agree that something like the game view (chess) would be better as an extension; however it is at a cost of innovation. The barrier to entry to getting a production extensions (esp on a WMF property) is significantly higher - leading to what could be an improvement for many content consumers to simply never happen.

One-off pages running scripts via a loader such as seen here:

• https://meta.wikimedia.org/w/index.php?title=MediaWiki%3ACommon.js&type=revision&diff=21065393&oldid=19983611

Is the weak workaround to the lack of this functionality that also avoids the high barrier to a new extension. While that example is meant to be temporary, is on a low volume project, and is also not primarily about viewer content, it is certainly not scalable to run "is this page title like %; then load xyz.js" for the PNG game viewer examples.

The other workaround that has been used due to lack of this functionality is via the Snippets loader technique (https://www.mediawiki.org/wiki/Snippets/Load_JS_and_CSS_by_URL) - which is somewhat fragile and requires the user to follow a link to initiate it.

In T275403#6852029, @Aklapper wrote:

The chess example sounds like better implemented via an extension, like ChessBrowser ?

For the record I believe ChessBrowser is indeed the extension implementation of that script, being worked on by @Wugapodes

In T275403#6852064, @Xaosflux wrote:

Is the weak workaround to the lack of this functionality that also avoids the high barrier to a new extension.

I'm afraid that sounds like pushing the additional maintenance costs lower down the stack, making it even harder to fix the Gadget architecture in the long run. :-/

Per previous comments, I assume this should realistically be declined?