Support use of ES8 code in gadgets. This involves confirming that Grade A browsers support ES8 syntax, switching the Peast validator to ES8 mode, and changes in the JS minifier.
Description
Description
Related Objects
Related Objects
- Mentioned In
- T374768: Provide a polyfill for Object.fromEntries
T370304: Bursts of occasional severe contention on s4 (commonswiki) primary mariadb causing recurrent user-facing outages on all wikis
T358416: Support OO.Factory class keys (ES6) in OOUI WindowManager
T362855: remove requiresES6 from most code
T277675: Add native support for ES2016-ES2020 or higher versions - Mentioned Here
- T271001: Transition to MathML rendering as default
T367821: Discovery: Deprecation of TLS 1.2
T342267: Investigate surprising "10% Other" portion of Analytics Browsers report
T75714: Update JavaScript syntax checker for gadgets and user-scripts for ES6 and later
T76204: Enforce JavaScript syntax check when editing user/site script pages
T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015)
T277675: Add native support for ES2016-ES2020 or higher versions
Event Timeline
Comment Actions
Which browsers are those? If my understanding is correct (per T178356#8782595), all Grade A browsers (that pass the current feature check) fully implement ES8. Even if MediaWiki core and extensions are still written for ES6, I don't think it's reasonable to disallow gadgets from using features that are supported in all browser clients.
Async/await has been around for quite a while now. It goes a long way in improving the gadget ecosystem, and even makes the language more accessible to people accustomed to writing in non-async systems like in Java. We should not expect people learning JavaScript today to learn the legacy technique just for MediaWiki scripting. After all, they are volunteers with limited time. Online courses on JavaScript today hardly mention anything other than async-await for asynchronous code.
If we want to be safe and ensure ES8 gadgets don't break the core experience in some as-yet unknown browser that we consider supported but doesn't support ES8, we can just put all gadgets in a dedicated RL group.
Comment Actions
I feel that the only thing that blocks the switch to ES8 is that async is not yet fully supported in the minifier (per T277675).
Comment Actions
I just want to add a few things to those already quoted by @SD0001 (thanks).
I've tested building my DYK tool with Babel.
- The build is significantly slower. Think multiple times slower. This will differ very much on specific build tools. It takes 1,7 seconds to exec my build via gulp of which the actual build is 485 ms. And with babel+uglify I get 5-7 seconds (yes, that's from 0.5 s to 6 s).
- The build is significantly larger. I had to uglify it make this reasonable even... It is still about 48% larger then the original. Quite a lot for adding no features.
Also worth noting that JS is not enabled on Windows XP on Wikipedia. I use it as a reference point because even Firefox on Windows XP has async support (see also: T178356#9458355).
And to make this versions less abstract here is a list of changes for each JavaScript (EcmaScript) version:
| Version | Released | Main Changes |
| 6 – ES2015 | June 2015 | Syntax changes: Classes (class), modules (import), const and let declarations, arrow functions, default function parameters, function rest parameters (...args), object literals ({variable1,variable2}), for/of loops, template literals (text = Description: ${variable}.;), destructuring assignments, generators (yield), new Unicode sequences, function call checks as classes (new.target). Others include collections (''Set'', ''Map'' etc.), typed arrays, proxies (meta objects). |
| 7 – ES2016 | June 2016 | Exponentiation operator (**), Array.prototype.includes. |
| 8 – ES2017 | June 2017 | async functions and await expressions, String.prototype.padStart/padEnd, Object.values/entries. |
| 9 – ES2018 | June 2018 | Asynchronous iterators, object property rest syntax, new regular expression features (including named groups), finally function for promises. |
| 10 – ES2019 | June 2019 | Array flattening methods (flat), changes to array sorting method and Object.fromEntries method. |
| 11 – ES2020 | June 2020 | Optional chaining operator (a?.b) and nullish coalescing operator (??), BigInt primitive. |
| 12 – ES2021 | June 2021 | String.prototype.replaceAll(), Promise.any(), weak references (including WeakRef), logical assignments, long number separators (thousands). |
| 13 – ES2022 | June 2022 | Class fields, static class properties, private class methods, Object.hasOwn, cause exception property, /d option for RegExp. |
| 14 – ES2023 | June 2023 | [].findLast, [].findLastIndex, support for hashbang. |
Comment Actions
It's not that simple I'm afraid. To diverge browser support in Gadgets from the rest of MediaWiki in this way you'd need customisation for mw.loader, for startup.js, script validation override, opt-out from edit save hooks for T76204, as well as messaging on Special:Preferences, and presumably some level of education/awareness to deal with the fact that some modules can no longer be safely loaded as dependency by other modules. For example, extensions sometimes await user, site or a specified plugin/module for VisualEditor.
This would incur high tech debt and take a significant step back for accessibility. It favours a reality in which most developers will (unknowingly) pretend something works that in fact does not. The jump from Basic to Modern is fairly easy to test and explain. A secondary gap within this layer is not likely to receive the same level understanding.
This is an excellent argument against such build step! We generally don't use one for MediaWiki. Do you still need it? For many devs, they mainly did this in ~2013 as a way to get "Package files" and ES6 syntax. These are supported natively now. Build tools now mostly a left-over trend from the 2010s era of frontend development, involving needless complexity for largely unproven and misunderstood benefits.
Having said that, I believe the slow down is avoidable, and likely originates from non-standard features (like Webpack or TypeScript), or needless transpilation (e.g. Babel is often configured to with a legacy ES5 target).
If the Git repo for your gadget uses standard JavaScript, and esbuild with --target=es2016, you can enjoy async-await today with fast and reasonably sized build outputs.
I believe you're quoting the date when the TC39 committee publishes their annual revision to the formal ECMAScript specification.
This is different from when browser engine vendors implement the first of these features.
This is different from when browser engine vendors implement the last of these features.
This is different from when browser engine vendors ship releases.
This is different from when browser app vendors update their forked or embedded engines.
This is different from when customers upgrade their devices or apps.
I've shown in previous tasks how we measure, analyze, and verify browser support. As well as examples of sometimes surprising delays in adoption in some cases. See also:
- T178356#8740573
- https://timotijhof.net/posts/2023/browser-adoption/
- https://codepen.io/Krinkle/full/OJoVqXm
- https://analytics.wikimedia.org/ and its data measurement flaw: T342267: Investigate surprising "10% Other" portion of Analytics Browsers report
I would not describe ES6 Promise as a "legacy" technique. It is very much a part of JavaScript today. The language is, to a first approximation, only getting bigger, not smaller. In any event, this point is exactly why we developed the Principles section in our guidelines:
By structuring it this way, we mostly avoid arguments about productivity. These can't "win" over the user experience. In practice, however, I find it also saves developer cost. This is because it means we reduce the need for smaller communities to duplicate efforts by developing their own tools merely because someone upstream couldn't be bothered to spend a few seconds to satisfy an extra lint check.
This is important because one could make a variant of your point about every ES version, including version ES2023 of last year. Knowing what exists is not enough to decide where to draw the line. Another way to look at it, is that we shouldn't encourage adoption of technologies that alienate part of our "Modern" audience, and further the equity gap within a given population group.
Of course, when a technology is ready, we should adopt it! ES2023 isn't ready yet. But is ES2017? It might be!
Now that we have well-maintained validators and minifiers that are easy to update, the blocker here is not technical, but one of proof, usage data, social awareness, and management decision. Once a decision is made, relevant folks can make the needed tweaks. I recognise that patches by Hannah and myself on T277675, may have confused you. The only reason you saw us working on that was because it made for a good on-boarding task to explain the code base to a new member of the team. Normally, we'd do that during a week or two after a decision is made, not before.
I suggest renaming this task and focussing your effort instead on raising the requirement for MediaWiki in general. You could then also kickstart it by identifying the relevant browsers/devices in question. Specifically, the "Practical implications" and "Browser support matrix" tables, noting that for Chrome/Firefox.
Further reading:
Comment Actions
[…] I've tested building my DYK tool with Babel. The build is significantly slower. […]
This is an excellent argument against such build step! We generally don't use one for MediaWiki. Do you still need it? For many devs, they mainly did this in ~2013 as a way to get "Package files" and ES6 syntax. These are supported natively now. Build tools now mostly a left-over trend from the 2010s era of frontend development, involving needless complexity for largely unproven and misunderstood benefits.
I agree with the first sentence. I don't want to take that step. I want MediaWiki to support ES 2017 for gadgets :-)
Actually, I would love it if the minifier supported ES2020 (e.g., optional chaining) and let me decide which browser I need to support in a specific gadget, depending on the gadget audience.
Version: 8 – ES2017
Released: June 2017
Syntax changes: async functions and await expressions, String.prototype.padStart/padEnd, Object.values/entries.I believe you're quoting the date when the TC39 committee publishes their annual revision to the formal ECMAScript specification.
...
Yes, but Firefox 52 was also released in 2017 (2017-03-07 to be exact). MDN added release dates to their compat tables. You can click on each version and see when was its release. For Chrome that was version 55 Released 2016-12-01.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function#browser_compatibility
Also worth noting that the TC39 process now requires that there is an implementation already before proceeding to the final stage of releasing an ES standard.
Polish Wikipedia has a good article on that ;)
https://pl.wikipedia.org/wiki/TC39
I suggest renaming this task and focussing your effort instead on raising the requirement for MediaWiki in general. You could then also kickstart it by identifying the relevant browsers/devices in question. Specifically, the "Practical implications" and "Browser support matrix" tables, noting that for Chrome/Firefox.
I strongly disagree here. Things that are not equal should not be treated equally. All gadgets are, by definition, enhancements. Core functions are already available from well... the MediaWiki core team(s). Community developers provide add-ons based on core functions. Gadgets are only loaded when they are enabled. If they don't work, people can disable them and still be able to perform all tasks without them.
As I said, gadgets are enhancements. Core is core, core needs to work. Gadgets work if they work.
Comment Actions
As I said, gadgets are enhancements. Core is core, core needs to work. Gadgets work if they work.
As someone who spent years maintaining user scripts and gadget on en.wp and providing support for users on WP:VP/T..... There is some truth to that, but I'd argue that a significant amount of the userscripts and gadgets are continuously broken. They cause issues for people where their javascript sometimes doesn't load. They cause errors to show up in the WMF logging.
Additionally, gadgets can be enabled by default. That means that your code runs on ALL browsers that support (right now) ES6. This can create a lot of noise for all of us. And that is WITH the most basic of guards (syntax compatibility checks). You argue that people will be 'just fine' without guardrails. And maybe en.wp would be. But lots of the smaller wiki's definitely would not.
Comment Actions
As someone who spent years maintaining user scripts and gadget on en.wp and providing support for users on WP:VP/T..... There is some truth to that, but I'd argue that a significant amount of the userscripts and gadgets are continuously broken. They cause issues for people where their javascript sometimes doesn't load. They cause errors to show up in the WMF logging.
Is that related, though? People always report on Discord or Village Pump first. Most people don't know how to use Phabricator. When I suggest to people to report problems here, they are usually reluctant to do so. So when things break, communities notice quite fast and help each other. The type of error doesn't really mater that much. The more severe error the sooner people notice ;)
Also, personally, I have access to logstash.wikimedia.org and... the most errors are on: en.wikipedia, en.m.wikipedia, fr.wikipedia, zh.m.wikipedia, commons.wikimedia, zh.wikipedia. Mostly TypeErrors.
Comment Actions
(off-topic: I'm really sorry to hear that fr.wikipedia is still amongst the most error-throwing wikis. I had a look for requesting Logstash access, but that sounds just a bit too cumbersome to me. Though, would it be possible to provide me some information to spot the most problematic codes, without breaking the NDA?)
Comment Actions
This is no more than logical. The most used wikis will generate the most errors. As such, the top 10 wikis will always be disproportionally be represented in the logging compared to the actual error surface.
Though, would it be possible to provide me some information to spot the most problematic codes, without breaking the NDA?)
I can copy paste a few stack traces to a pastebin. But please file a separate ticket for that and assign it to me, so that I don't forget. I can't do that right now, nor does it particularly have anything to do with this ticket.
Comment Actions
Most gadgets are written for a limited audience; IMO the gadget author is usually best placed to know that audience and make productivity / inclusivity tradeoffs. The question is how much work on the platform itself it requires to make such tradeoffs safe to do, and is that a worthwhile investment compared to other things that could be done with that amount of effort. I think it would need
- replacing requiresES6 with something more meaningful and accurate like requires=ES2018
- having peast validate that the gadget really conforms to the given version
- disabling minification for versions not supported by the minifier (and probably warning the gadget author about this fact)
- having ResourceLoader detect the level of support in the browser and failing with a clear error message if an unsupported module (or a module with an unsupported dependency) is requested
- having Gadgets detect the level of support in the browser and indicating to the user on the preferences page when they cannot use a gadget because their browser doesn't support it.
...which seems like a fair amount of work.
Comment Actions
I think (fwiw) async/await is the standout feature here, with everything else being possible to work around in various ways (transpiling, polyfills, do-it-the-old-way, etc.). I wouldn't want to argue in favour of raising browser requirements for that other stuff, and I wouldn't want to argue for generally raising it (with all that implies) for just the one language feature.
But when you have a pattern that wants async/await you really want async/await, so I think one can choose to view this task as "Is there any reasonable way we can enable Gadgets to use async/await without triggering all the other thorny issues?"
I'm not aware that any of the relevant components support cherry-picking individual language features to enable so I'm assuming the answer to that is "no", but at least that's a slightly narrower scope to discuss.
(Did I mention I really need async/await just now, to replace some old cut&paste agglomeration of code that uses XmlHttpRequest to fetch a wikipage with &raw just to check whether it exists or not? For every path component in a subpage structure? On every flipping page in our main content namespaces as well as in our main project space? In a Gadget that's enabled by default? Rewriting this pile of [redacted] to something at least minimally sane is enough of a pain without having to turn it inside out to fit the old asynchronous pattern. I would commit crimes if it would give me async/await right this instant!)
Comment Actions
No customisation is required when gadgets are in a separate group. If any of them contain an ES8 feature which is not supported in the browser, the bundle doesn't work – which at the maximum can only cause other gadgets to not load, which seems like a reasonable tradeoff considering that no one so far has brought up a single example of a Grade A browser that doesn't support ES8. Even if one exists, gadgets are optional enhancements without which the site still works. Quoting from the frontend best practises: "Embrace that every page starts with basic HTML and CSS, and that JavaScript adds optional layers that may or may not arrive. Its eventual arrival depends on numerous factors, and may vary over time even for the same person"
script validation override, opt-out from edit save hooks for T76204
All user JS (gadgets plus 'user' and 'site' modules) can have the same level of validation, so no override or opt-out is needed.
and presumably some level of education/awareness to deal with the fact that some modules can no longer be safely loaded as dependency by other modules. For example, extensions sometimes await user, site or a specified plugin/module for VisualEditor.
When an extension relies on a user-level module it can and should handle possible error cases, per the "never trust the client" philosophy. RL sets the module state to 'error' and mw.loader.using() returns a rejected promise if the module fails to execute, so it's nothing that can't already be done today.
In any event, this point is exactly why we developed the Principles section in our guidelines:
By structuring it this way, we mostly avoid arguments about productivity. These can't "win" over the user experience.
In the context of Gadgets, I would say the gadget authors come in the "users" category, which is why I'm bringing up the benefits of ES8 only from their perspective. Adopting ES8 in core/extension-loaded JS would be great too, but that is admittedly just a "developers"-level improvement.
This is important because one could make a variant of your point about every ES version, including version ES2023 of last year.
Well, classes from ES6 and async functions from ES8 are two seminal features which justify all the hue and cry over extending support to include them. Nothing in ES'18 to '23 comes close. They do have some useful new syntax (the optional chaining operator, for instance) but can easily be substituted with older syntax.
I suggest renaming this task and focussing your effort instead on raising the requirement for MediaWiki in general.
That can be done as well but I suspect that is going to be a long drawn out process and is not easily volunteer driven.
Comment Actions
I agree with those best practices, but I want to take this a bit further even. There are many types of gadgets and more layers to browser support over the layers provided by MediaWiki core and a layer of extensions provided by WMF teams.
- Core and main extensions are things that most have to be accessible in some way. These have well-defined levels/grades of support: https://www.mediawiki.org/wiki/Compatibility#Browsers
- Skins and extras supported by WMF. Old skins should work, but if they break, users can still try other skins. E.g., the mobile skin doesn't support everything, but we can still switch to desktop skins.
- Default gadgets. For anons, so should be close to what WMF provides. This can be things like "Report a bug". This should be well tested as advanced users might not be using that (and problems might not be reported).
- Beginners' gadgets. There are some gadgets targeted at beginners. If those break, people are less likely to report problems.
- Advanced gadgets. Requiring specific, mid-level permissions.
- Sysop gadgets. Requiring sysop permissions.
The last two (advanced) groups are where I would say ESnext gadgets are best suited. Advanced users, especially sysops, will report problems quickly and might even personally know the creator of the gadget. So basically, they know where to ask if things break. I also expect sysops to update their browsers for the sake of their security and, by extension, Wikipedia's security. So, if users with advanced permissions use old browsers, this is basically on them, and one could argue it is a good thing some enhancements don't work until they update.
Comment Actions
In addition to Nux's points, the communities have a much better understanding of the scope for compatibility for some things; be it CSS features, what they put in Common.{css, js}, which Gadgets they make default, what skins they support for a given script or Gadget, etc. I know the four users still using Monobook on enWS and which Gadgets need to maintain compatibility with it; but also that nobody much beyond those four use it so I can ignore that skin for other Gadgets.
A case in point: the horrible mess of a user-script-pretending-to-be-a-Gadget I wanted async/await for in my above comment mostly just pre-fills some boilerplate templates on certain pages (think the equivalent of inserting {{information}} on File: pages on Commons). This is an entirely optional QoL-type function that it is ok if it only works for "most people". It's limited to edit-mode (no readers are affected), and only when creating entirely new pages (somewhat experienced editors), and only automates adding the standard templates that the edit notice tells you to add manually (for convenience only).
You can't make that call with a broad brush like "all of MediaWiki" (or rather, you can only do so extremely conservatively), but when we're talking Gadgets we're inherently at a level of granularity where the community not only can, but is actually best situated to make calls like that. De-coupling MediaWiki and Gadgets on this would allow for more nuanced approaches, and allow communities some reasonable scope for exercising that judgement.
Comment Actions
A granularity that however runs inside the same execution pathways of mediawiki, and thus mixes in with all the other code. It is cool you want to do some redecorating, but we are living in the same house. If you poke a hole in the roof, the whole house has a leak, not just your room.
De-coupling MediaWiki and Gadgets on this would allow for more nuanced approaches, and allow communities some reasonable scope for exercising that judgement.
But that would also mean more variance across Wikimedia that people need to maintain. From security to the site requests and the maintenance scripts that have to run.
Like I get the desire, but you also have to look at the impact of that desire for others.
Comment Actions
We don't disagree on the broad principles, but I'm saying there is scope within that to enable some more granular approaches. In your analogy WMF and core devs are the landlords for the MediaWiki deployment, and needs to make sure the building is wheelchair accessible, conforms to building and fire codes, and so forth. But if I want to hang a picture that requires 3D glasses to view or want to put a smart lock that only works with iPhone (vs. Android) in my room that's not something the landlord should care about or regulate. I am already not allowed to knock out walls or disconnect the sprinklers, but maybe it'd be ok if I bought a stove top with Bluetooth?
It's entirely possible to have the platform as such remain at the status quo, but still provide the technical ability for the community to opt in on a case by case basis to different feature-vs.-availability tradeoffs.
I can already say "Monobook users don't get this Gadget" and potentially exclude more users than serving it with async/await code. I am (speaking as an active Interface Admin on my project) generally going to be in a much better position to make that call for a particular use case than "the landlord".
If you want to argue based on increased complexity by enabling ES8 in Gadgets (e.g. requiresES8), or based on the cost—benefit, or prioritising scarce developer resources, those are all fair points. But I don't see anything that fundamentally makes this impossible or undesirable; and it would provide a safety valve that gets us past the async/await hump without the massive expenditure of time and resources (and a decade of waiting, and...) we had to get past the ES6 hump. If anything, enabling opt-in ES8 for Gadgets under community control is going to reduce the pressure to move the needle on general Grade A and postpone the need to do so by some factor (possibly measurably, possibly not).
Comment Actions
As you're well aware, there are ways the execution of gadgets can be isolated from that of mediawiki's own javascripts. This was how the requiresES6 feature used to work.
De-coupling MediaWiki and Gadgets on this would allow for more nuanced approaches, and allow communities some reasonable scope for exercising that judgement.
But that would also mean more variance across Wikimedia that people need to maintain. From security to the site requests and the maintenance scripts that have to run.
Can you be more specific how it increases the maintenance overheads? For whom? What about the overheads in the other direction – people have to deal with writing and maintaining code which does not conform to what the rest of the internet uses any more. At some point we have to support ES8 anyway, so new gadget code being written today would need to be rewritten, which is a lot more of an overhead.
Comment Actions
Just mentioning that soon TLSv1.2 will be phased out and given https://caniuse.com/?search=tls%201.3 vs https://caniuse.com/?search=await users who can't use async/await won't be able to connect at all so the whole discussion here about compatibility and impact is moot.
Comment Actions
Crosslink: T367821: Discovery: Deprecation of TLS 1.2. However once Mathoid is sunset (T271001: Transition to MathML rendering as default)}, any Chrome<109 (those without native MathML support) user which does not enable JavaScript (including those using Chrome<63) will not see math formulas properly.