Open Arkanosis opened 5 years ago
This is a good point. In fact, I think it will never be installed on Wikimedia wikis (because it goes in the opposite direction with the actual UI/UX directives, and it will be seen as a duplicate from the new [[Special:RecentChanges]] page).
I'm still writing this as if it was a MW extension for three reasons:
The only server-side part is here to load the JS modules on a specific special page (and it will not go any further). That still permit to use tools like webpack to package it for the gadget deployment :)
Does this seems legit to you ?
I understand the benefits of writing a MediaWiki extension when special access is required for the tool to function, but I fail to see which is needed for LiveRC. Do you have any in mind? I believe EventStream and the Action API is all that is needed, and that are public APIs.
I have to confess that I'm not well versed at all in JavaScript packaging for MediaWiki, so I might very well have missed something important, but…
Developing LiveRC as a user script / gadget has an immense benefit, which is to be testable and hackable by pretty much anybody with only very basic JavaScript skills. You copy the code in your
common.js
, you press F5 and that's it. Setting up a MediaWiki extension is way above the actionability threshold for pretty much anybody apart from MediaWiki developers.The way I see it (and I'm open to criticism), the new LiveRC is built with modern tooling (git, JS frameworks, possibly even TypeScript), but remains deployable, testable and if needed hackable by anybody. That's something I think is quite easily achievable with a tool like webpack: write code in JavaScript, TypeScript, SASS, you name it, spread it across hundreds of files if it makes it easier to manage, package it to pure JavaScript + CSS using webpack, and then anybody can deploy it as a user script. No need to be a sysop. No need to be an interface administrator. No need to be a developer. No need to be a WMF system administrator.
Local gadgets go through ResourceLoader anyway, so I don't think any approach is more efficient than the other.
Thanks!