With a PHP port of babel.js (or some wrapper) this should be possible in theory, but:

In T96901#3170211, @Krinkle wrote:

Switching is trivial from an interface perspective (we have very few directly callers to this library), however it's complicated because we have very high performance requirements. There aren't many performant JavaScript parsers/minifiers for PHP. And last time we checked we couldn't find any to the point that one of our volunteers (Paul Copperman) actually wrote a high-performance parser just for our use case.

How performant does it need to be? This operation only has to be run after a Javascript file is saved, not every time it is served.

Hi @Machineghost and welcome. Could you please rephrase the task summary? Is this a bug report (something not working)? Is this a feature request (then what exactly is requested and which exact problem would the proposed solution solve)? Is this a general question how things work (which would be better suited in a support forum)? Something else? Also see https://www.mediawiki.org/wiki/How_to_report_a_bug - Thanks for clarifying :)

Honestly I wasn't sure myself. As I said, I started with a Super User question for that very reason, but then when it didn't get any responses I brought it here.

It's sounding like there is no built-in way to accomplish this however, and that it should be a feature request, so I'll change the subtype to that unless anyone says otherwise.

Thanks for the quick reply. What exactly is the "this" in "accomplish this"? :)

Some related discussion / background might also be in T108655: Standardise on how to access/register JavaScript interfaces

What exactly is the "this" in "accomplish this"? :)

In short "this" = MediaWiki having a way to automatically run saved Javascript through a 3rd-party program.

Specifically, I'd like to run ("pipe") it through Babel, but the functionality doesn't seem like it needs to depend on Babel: people might also want to run code through Prettier or another code formatter, for instance.

This would allow the following scenario:

1. Advanced wiki user goes to "wiki.example.com/Mediawiki:SomeFile.js"
2. Advanced wiki user edits the code and saves modern Javascript: "const foo = () => 1;"
3. Wiki takes their code, saves it in temp.js, runs the command "npx babel temp.js newTemp.js", and after the command completes it saves the contents of "newTemp.js" in the database (or filesystem, or wherever it saves it) instead of the user's original temp.js
4. When any other wiki user loads the Javascript, they see the converted/browser-friendly version ("var foo = function() { return 1; }") ... which still works even if that user is on Internet Explorer 8 for some reason

P.S. Another way people may find this same functionality useful is in CSS. Both the popular LESS and SCSS libraries involve doing the exact same thing with CSS code (passing it through a "translator" to output browser-readable code but let people write non-browser-readable code first).

I personally don't need either library, just saying if you have a way to make it work for CSS, others might find that valuable too.

From the support angle for site admins, the answer is that Babel.js conversion is not a feature that MediaWiki offers currently. And from the perspectives of performance, security and portability, it is unlikely for that to be provided and maintained by WMF in the short to medium term.

For the core experience, we have yet to find use cases that couldn't be implemented with ES5 (in particular because that's what would end up served anyway). I'm focussing our efforts on T178356 instead, which makes ES6 transformation unnecessary. There is also the option of transforming your code prior to deployment.. For example, as part of a pre-commit hook or as part of your deployment system. This would generate the files in-place and MediaWiki wouldn't need to know where they came from.

For site admins with engineering capacity and interest to implement this for themselves, I can say that ResourceLoader provides an extendable interface for use cases like this. The ResourceLoaderModule class is abstract and allows scripts to come from anywhere. For example, we have implementations that read files from disk, but we also have implementations that fetch them from wiki pages or external urls. Similarly, one could implement a class that takes a filename and shells out to Node.js to generate ES5-compatible JavaScript code. Whether from Babel, TypeScript of CoffeeScript, there are no limitations.

With all due respect, the difference between this ticket and T178356 is the difference between saying "I'll fix things for a (small) category of users" and saying "screw those users!"

Like it or not (and I don't), people still use IE8 or other outdated browsers. Some companies require it, because they use software that was written for IE8 that they don't want to pay to rewrite. If you work at such a company, you may have no control over your choice of browser. There are similar situations with other outdated desktop browsers, plus lots of mobile browsers with similar/related issues (such problematic browsers are especially popular in countries with only low bandwidth internet access available).

Mediawiki can tell those people to go suck eggs (ie. T178356). As a web developer myself I'm extremely sympathetic to taking that stance ... but MediaWiki doesn't have to! It can make it possible for wiki-editors to write modern Javascript, while transpiling that code back to something the IE8 users can handle ...

... and all it takes is a single mechanism that enables a wiki admin to run /MediaWiki:*.js through Babel.

As for timing, I'm still failing to understand the issue. Before the file is saved, you have an old version (or no version). However long it takes the wiki to run the file through Babel after it's saved, there is no (technical, that I can see) reason why it can't keep displaying the old (or no) version ... for days if necessary ... until the new version is ready.

Of course in reality it won't even take minutes, but if someone re-edits during that time you just throw out the incomplete version. Users always still see at least the old JS, and get the new JS when it's ready.

Countless responsible/serious/corporate sites develop using modern JS, yet still support even IE8. If you make millions in sales every day, even 0.5% of those millions is nothing to sneeze at, so you try to support everyone (even though you only care about money and not people). All those corporate sites use Babel to support minority/outdated browser users, and if they can, why can't "the people's wiki software" do it?

If it can't, you're choosing to doom such users (and yes ... I understand and agree that they're a very small minority ... you're choosing to doom a small minority of users), of countless wikis across the Internet, as soon as their wiki upgrades ... all for lack of a single text pipe and the will to use the same (extremely popular) software used elsewhere :(

Like it or not (and I don't), people still use IE8 or other outdated browsers.

According to https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix , IE versions 6-10 are under "Basic (Grade C)" which already means that "these browsers do not get JavaScript features."

Some companies require it, because they use software that was written for IE8 that they don't want to pay to rewrite.

Indeed, companies are free to not care about the [in]security of their own infrastructure, but that's not a good argument to encourage such behavior. :)

why can't "the people's wiki software" do it?

I get zero results on Google for the phrase "the people's wiki software". Not sure what that phrase is supposed to imply, but I guess it should not imply that maintainers should always accept additional code covering uncommon use cases and then maintain that code for years.

See https://www.mediawiki.org/wiki/Bug_management/Development_prioritization : "Some tasks might also be very complicated to fix (software architecture issues where efforts might outweigh gain), considered too risky, or the maintainers consider it out of scope of the functionality that the software should cover."

People and companies are however free to take the MediaWiki source code and change it to cover their needs.

As Andre shows, we are not dooming any users. MediaWiki embraces HTML and CSS for an essential experience. This does not involve any unnecessary JavaScript. Grade A support for IE8 was removed more than three years ago already. MediaWiki currently requires IE11+ before loading the Grade A code. See https://www.mediawiki.org/wiki/Compatibility for more information. When Wikipedia traffic shows ~99% or higher using a browser with ES6 support, we might consider raising this again. Perhaps in 2020.

If you wish to write ES6 code today, I have explained two ways that developers can do that (transform ahead of time, or develop a MediaWiki extension that provides the functionality at run-time for files or wiki pages). This is indeed possible and entirely your choice.

In T232285#5493623, @Machineghost wrote:

Before the file is saved, you have an old version (or no version). However long it takes the wiki to run the file through Babel after it's saved, there is no (technical, that I can see) reason why it can't keep displaying the old (or no) version ... for days if necessary ... until the new version is ready.

It is not that simple. MediaWiki offers high guarantees about version consistency. All code served to a user must come from a specific snapshot in time of the deployed state. We cannot serve older versions of one file whilst serving new versions of something else. If you do not require this consistency for your own website, it is within your control to bypass this in a MediaWiki extension. For Wikipedia, this would require a storage system to save the Babel-transformed output of previous wiki page versions. And to store older backup versions of the core and extension JS code as well, so that if a deployment and we need to run a Babel transformation, that all code is still served from the previous version - which would no longer exist on the hard drive. This storage cannot be a normal cache, as otherwise it can expire and then there is no code to serve.

Our current performance for on-demand transformation is < 1 ms on average, with 95% taking less than 5 ms, and to build dozens of modules together on the same page view in less than 100 ms most times (75th percentile). (Dashboard 1, Dashboard 2). There is no space in those performance levels for something like Babel.

There are also risks in exposing a Babel transformation to the public Internet. There is CPU load, and rate limits to be made as otherwise it can be abused, overloaded. As site administrators, you would then also need to install Node.js, Babel, the 233 packages needed for Babel.js, on all web servers. And to continuously keep these up-to-date to mitigate the latest security issues. Probably best to run inside a VM so that in case of compromise, it cannot access sensitive files or your database. This is not something currently on the roadmap for MediaWiki core or Wikipedia. But as website owner, this is something you can decide to do, or pay for.

I will gladly offer help with any issues you encounter in using the ResourceLoaderModule plugin interface.

According to https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix , IE versions 6-10 are under "Basic (Grade C)" which already means that "these browsers do not get JavaScript features."

And that is EXACTLY why web developers use Babel: to give them their missing features.

Look, you can talk about grades of support all day if you want, but ultimately they're just labels for "people I don't want to have to deal with". But whatever label you give them, they're still people who won't be able to use wikis (fully) because of your choice.

Indeed, companies are free to not care about the [in]security of their own infrastructure, but that's not a good argument to encourage such behavior. :)

I would argue it's not MediaWiki's place to judge other companies on how they run their business (regarding their choice of browser or otherwise). I would argue that MediaWiki's business is accommodating wiki users though.

I get zero results on Google for the phrase "the people's wiki software".

Yes I made that specific term up, but look, wikis are inherently a populist idea. And here's an actual quote for you, from Wikipedia's page on wikis (emphasis added):

Ward Cunningham and co-author Bo Leuf, in their book The Wiki Way: Quick Collaboration on the Web, described the essence of the Wiki concept as follows:[8]

A wiki invites all users ...

I also found this page of Media Wiki's Principles: https://www.mediawiki.org/wiki/Principles. Not only do those principles seem consistent with being inclusionary and not exclusionary, they also state that MediaWiki is the platform for the Wikimedia Movement, and that movement is VERY CLEARLY inclusionary:

a collection of values shared by individuals (freedom of speech, knowledge for everyone, community sharing etc.);

I sincerely believe that what you're doing (excluding people for not having a browser you approve of) goes against wiki principles and therefore very likely MediaWiki principles.

I just don't believe you could go to the people that started this project and say "yeah I can't be bothered to deal with people with old browsers, and they don't deserve full access to enjoy MediaWiki because I disagree with (say) their boss's decision on which browser to use" ... and Jimmy Wales would be like "Yes! That is what wikis are all about!"

As for all the technical excuses ... you're describing how things currently work, not what's reasonably possible. Again, Babel is one of the most popular pieces of software running on web servers today: literally millions of servers have solved this problem already. You don't strike me as a stupid person at all: your responses have shown a great deal of intelligence. Unfortunately however you've focused that intelligence on finding excuses to deny people access to wikis.

What if instead you directed that intelligence towards trying to find a solution to allow more people to enjoy wikis? Could you maybe try a thought experiment right now? Just give this annoying Internet stranger 20 seconds of your time, and for those twenty seconds please close your eyes, try to forget that mountain of excuses, and just think "if I wanted to let everyone enjoy MediaWiki, am I smart enough to think of a way to do it (especially since someone already wrote the software that solves the problem for me, and all I have to think up is some way to fit it into MediaWiki)?"

Isn't that what anyone who cares enough about wikis to volunteer their time to work for the Media Wiki org should care about? Surely you didn't get into all this to tell people with unfortunate life circumstances (like having a bad browser) that they don't deserve to be able to use wikis the same as anyone else?

I will re-open if I can get https://phabricator.wikimedia.org/T232953 through.

You're making it sound like we're preventing people from viewing/reading MediaWiki instances... Which we're not.

What necessary function is broken?

@Machineghost I believe we agree in principle, but there may be some misunderstandings. Please consider the following and let me know if this makes sense.

• We are not excluding access to primary features from Grade C browsers. IE6+ can read, edit, and otherwise contribute.
• Adding Babel to MediaWiki today would make no difference in how many users may receive the JS-based features of Wikipedia. The input to Babel is ES6 javascript, and its output is ES5 javascript. Today, our JavaScript code is already written in ES5-compatible syntax. The same as Babel would produce. Older browsers like IE6-8 that do not support ES5 javascript, would remain on Grade C.
• Universal access is an important part of the mission, which I take very seriously. I consider myself conservative and possibly one very few people actively blocking the resolution of T178356, precisely for the reasons you describe. We will not be decreasing the proportion of users that receive Grade A javascript features. We do not require ES6 today. We require ES5. After the proportion of users with non-ES6 browser users is the same, or smaller, than the proportion of non-ES5 users was in 2015, then, and only then, will I consider raising the requirement.

Lastly, I leave you with a question: Do you agree that it is okay not to invest time and resources in JavaScript features for IE5 on Windows 95? If so, when should we treat IE8 the same way we treated IE5 in 2010? For Wikipedia, that time was 2016. Was this a mistake?

What necessary function is broken?

The "broken function" is not necessary. MediaWiki is designed to work without Javascript.

But does that mean that Javascript is meaningless? Did MediaWiki volunteer coders write thousands of lines of code for the MediaWiki project, and then did countless individual wiki admins write however many more thousand lines ... all because Javascript isn't important on wikis?

Of course not. Javascript improves people's ability to access and use wiki content.

We 100% agee that MediaWiki is not denying anyone access to HTML/CSS. What I'm saying is, it's great that we can show such users HTML/CSS ... so wouldn't it be similarly great if they could get Javascript features also? With Babel they can.

I believe we agree in principle, but there may be some misunderstandings.

That's great to hear, and I apologize for my part in any such misunderstanding. To your first point, please see the above. To your second:

Today, our JavaScript code is already written in ES5-compatible syntax. The same as Babel would produce. Older browsers like IE6-8 that do not support ES5 javascript, would remain on Grade C.

Sorry, this is entirely my fault. https://phabricator.wikimedia.org/T178356 got mentioned and I've sort of been taking it as a given.

I guess I should have posted there, but I really feel the angle that ticket is coming from is wrong. I feel like the question being asked there is "do we have few enough people to jettison them?"

I'm arguing the criteria should be "how can we reasonably accommodate as many as we can?" I think the focus should be on "reasonably " and "as many as we can" ... not picking on browser minorities.

But also as far as:

I consider myself conservative and possibly one very few people actively blocking

I think everyone can win if MediaWiki just adopts Babel.

Babel can potentially support a huge array of browsers. See the Babel documentation, specifically this page https://babeljs.io/docs/en/6.26.3/babel-preset-env, or read this article: https://blog.jakoblind.no/babel-preset-env/. Babel partners with browserslist to give its users an incredible level of control over what new features vs. what old browsers you want to support.

For instance, IE8 can almost completely be supported by Babel. The main issue is that getters/setters (which are a very minor piece of JS overall) don't work.

But really the decision of whether to support IE8 specifically or not is a technical one to be made by the people responsible. I just think the important criteria shouldn't be "have we lost enough of these losers that we can stop supporting the rest?" Also, I'm worried from the tone of both tickets that:

Universal access is an important part of the mission,

isn't a universal sentiment. (Thank you for saying that "out loud" BTW.)

Lastly, I leave you with a question: Do you agree that it is okay not to invest time and resources in JavaScript features for IE5 on Windows 95? If so, when should we treat IE8 the same way we treated IE5 in 2010? For Wikipedia, that time was 2016. Was this a mistake?

I was not aware of that, and whether it was a mistake or not depends on the details.

It seems reasonable that Wikipedia may not want to give up using getter/setters (they're dumb, but it's the principle of giving up a language piece), and if they didn't that'd mean the potential for bugs in IE8. They may have rather disabled JS than have bugs (and that same logic may well apply to MediaWiki; personally would rather have 95% functionality than 0%, but I don't have to deal with the bug reports of the 5%).

Here's what I will say is a mistake (in an inclusive org like a wiki project): choosing to deny users access (in part or full) to your wiki when there is a reasonable way to accommodate them.