6 ms·

When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around? Catering to an implementation that does bad things is an awfu

by web007 8y ago

When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around? Catering to an implementation that does bad things is an awful way to build standards, but it's only going to happen again and again and again unless the developer is forced to pick a version and build / maintain compatibility with exactly that version.

komali2 8y ago
Wait, what would that look like? Because I don't know what would happen if you don't define your version in script tags, it'll default to I guess LTS, which wouldn't have fixed this issue, right?
- tejasmanohar 8y ago
  Couldn’t it also default to a “version” drawn from the superset of popular browser features at the time or the current year’s ES version?
  - iainmerrick 8y ago
    Right. It would have fixed this “flatten” issue, if the versioning change were done first, because those old sites wouldn’t have picked up the new “flatten” method. It would be opt-in.
baybal2 8y ago
>When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around? Unless there is a will to plow the ranks of committee sitters, and remove inadequate people, you will never see that till the moment the web platform kicks the bucket.
- olavk 8y ago
  You seem to think that the committee sitters which believe in "don't break the web" are "inadequate". But this philosophy is shared by the browser vendors - they are simply not going to implement a standard which "breaks the web". You will have to convince browser vendors they are somehow better off if their software stops working as intended.
  - baybal2 8y ago
    By far, it are those who oppose JS code versioning breaking the web. The number of breaking changes since nineties is high hundredth already. Just each time they were opting to "break just few percents of websites, after careful considerations"
ryanwatkins 8y ago
Version in the type attribute used to be there with Mozilla. They removed it. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc... https://bugzilla.mozilla.org/show_bug.cgi?id=1428745 https://bugzilla.mozilla.org/show_bug.cgi?id=1428745
- bsimpson 8y ago
  I believe MS has also moved away from its various JS modes. I suspect that the cost (in both maintenance hours and performance overhead) to maintain parallel JS engines is extremely non-trivial.
loftyal 8y ago
Couldn't we just have a JS style language compile down to web assembly?
olavk 8y ago
This is unlikely to happen. Browser developers don't want to maintain multiple forks of their JavaScript engines. They want new features introduced in a backward compatible manner so they can maintain a single engine. Imagine in 10 years if you had to maintain 7 slightly incompatible engines in parallel. A new browser written from scratch would have to implement all 7 engines since the older versions would never go away.
- web007 8y ago
  JS is no different from HTML in this regard. HTML has (at least) several variants of 4.x, quirks mode, HTML5, new features, deprecated features, etc. which all demand separate rendering engines. At some point, the browser stops supporting those things because they don't have to. I don't know what kind of backward compatibility is inherent in their designs, but just remember <marquee> if you think that browsers have to support all features ad infinitum.
  - olavk 8y ago
    In practice, browsers does not recognize HTML versions. All HTML is handled by the same engine. This is one of the reasons HTML has moved to a living standard - the versioning was purely an artifact of the standard document and did not correspond to versioning in the rendering engines. (XHTML did introduce branching front-end parsers, which was a lot of wasted work.) Adding new backward-compatible features does not require branching the engine, neither does removing older features. The quirks/standards-mode distinction did require branching engines, and it has lead to increased complexity and testing burden. It was necessary at the time to move forward so the cost was accepted, but it is a complexity burden all browser have to carry for the foreseeable future. There should be a very good reason to introduce such branching - wanting to write "flatten" rather than "flat" is not a good enough reason. Marquee was never supported by all browsers. But the article does mention some widely supported elements where support have been removed (<keygen>, <applet>) so it is not unheard of. But it requires that the element is almost never used on the web. Apparently this is not the case for MooTools library in question which still has some penetration.
whatever_dude 8y ago
This has been discussed at length and they have decided not to do it. It's not a missing feature, it's by design.

by web007 8y ago

komali2 8y ago

Wait, what would that look like? Because I don't know what would happen if you don't define your version in script tags, it'll default to I guess LTS, which wouldn't have fixed this issue, right?

tejasmanohar 8y ago
Couldn’t it also default to a “version” drawn from the superset of popular browser features at the time or the current year’s ES version?
- iainmerrick 8y ago
  Right. It would have fixed this “flatten” issue, if the versioning change were done first, because those old sites wouldn’t have picked up the new “flatten” method. It would be opt-in.

baybal2 8y ago

>When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around? Unless there is a will to plow the ranks of committee sitters, and remove inadequate people, you will never see that till the moment the web platform kicks the bucket.

olavk 8y ago
You seem to think that the committee sitters which believe in "don't break the web" are "inadequate". But this philosophy is shared by the browser vendors - they are simply not going to implement a standard which "breaks the web". You will have to convince browser vendors they are somehow better off if their software stops working as intended.
- baybal2 8y ago
  By far, it are those who oppose JS code versioning breaking the web. The number of breaking changes since nineties is high hundredth already. Just each time they were opting to "break just few percents of websites, after careful considerations"

ryanwatkins 8y ago

Version in the type attribute used to be there with Mozilla. They removed it. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc... https://bugzilla.mozilla.org/show_bug.cgi?id=1428745 https://bugzilla.mozilla.org/show_bug.cgi?id=1428745

bsimpson 8y ago
I believe MS has also moved away from its various JS modes. I suspect that the cost (in both maintenance hours and performance overhead) to maintain parallel JS engines is extremely non-trivial.

loftyal 8y ago

Couldn't we just have a JS style language compile down to web assembly?

olavk 8y ago

This is unlikely to happen. Browser developers don't want to maintain multiple forks of their JavaScript engines. They want new features introduced in a backward compatible manner so they can maintain a single engine. Imagine in 10 years if you had to maintain 7 slightly incompatible engines in parallel. A new browser written from scratch would have to implement all 7 engines since the older versions would never go away.

web007 8y ago
JS is no different from HTML in this regard. HTML has (at least) several variants of 4.x, quirks mode, HTML5, new features, deprecated features, etc. which all demand separate rendering engines. At some point, the browser stops supporting those things because they don't have to. I don't know what kind of backward compatibility is inherent in their designs, but just remember <marquee> if you think that browsers have to support all features ad infinitum.
- olavk 8y ago
  In practice, browsers does not recognize HTML versions. All HTML is handled by the same engine. This is one of the reasons HTML has moved to a living standard - the versioning was purely an artifact of the standard document and did not correspond to versioning in the rendering engines. (XHTML did introduce branching front-end parsers, which was a lot of wasted work.) Adding new backward-compatible features does not require branching the engine, neither does removing older features. The quirks/standards-mode distinction did require branching engines, and it has lead to increased complexity and testing burden. It was necessary at the time to move forward so the cost was accepted, but it is a complexity burden all browser have to carry for the foreseeable future. There should be a very good reason to introduce such branching - wanting to write "flatten" rather than "flat" is not a good enough reason. Marquee was never supported by all browsers. But the article does mention some widely supported elements where support have been removed (<keygen>, <applet>) so it is not unheard of. But it requires that the element is almost never used on the web. Apparently this is not the case for MooTools library in question which still has some penetration.

whatever_dude 8y ago

This has been discussed at length and they have decided not to do it. It's not a missing feature, it's by design.