ECMA TC39: “SmooshGate” was officially resolved by renaming flatten to flat

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.

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"

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.

Monkey-patching is not in itself a problem though since it just overrides the built-in functionality. The problem in shooshgate was (if I understand correctly) specifically monkey-pathing Array and relying on the added property to be enumerable. This meant JavaScript could not introduce a non-enumerable property with the same name without breaking code.

While monkey patching in general is problematic, monkey-patching Array or Object is much worse than monkey-patching Window.

I don't see the point either, a good backward compatibility is useful but a 100% backward compatibility even with unspecified behaviour is a recipe for disaster.

Imagine if books became unreadable the day the author died.

Some people care about books, even books written by people long dead. And some people care about the content on some older websites, even if they are not using the newest flashy framework.

As developers, we hate the demands of legacy code and backward compatibility. We would like to scrap everything and rewrite in the cool new language and framework every few years. But a browser is not only a fun playground for developers. It is a tool for accessing information for people who couldn't care less about what an identifier is called in JavaScript. They just want it to work.

>Who ever thought future progress can be sacrificed just so that some obscure website (obscure because it is no longer supported, people no longer care) can work for 22 years during which the world has changed so much that this website is probably no longer relevant under any objective measure.

The alternative would to design the web so that only popular and "relevant" sites can expect to be viewable in the future, and to arbitrarily break everything else. But the web isn't (or shouldn't be) structurally biased towards the size or traffic of a few specific sites, and an obscure decades old site no one cares about has just as much of a right to remain functional as any other.

Thanks. That makes the previous post even less convincing :) Over 1 in 100 is not vanishingly remote, and that's just on the top 500k sites (who knows how representative that sample is of the whole web).

It is true that very occasionally features are removed from the web platform. It is also true that the incentive structures that exist hugely favour not removing features or otherwise breaking existing content. For a feature to be removed there needs to either be an incredibly compelling reason (e.g. a security problem), preferably so obvious and widely agreed on that vendors are able to make simultaneous releases containing the change in order to mitigate the effect on the competitive landscape, or there needs to be a negligible measured usage of the feature. The latter is most usually the case when the feature was never widely implemented in the first place e.g. some (but not all) vendor extensions.

If it were easy to remove unpleasant features from the platform, browser vendors would be the first people clamouring to make it happen. For example, off the top of my head, there is widespread agreement that it would be good to get rid of, or otherwise improve in backwards-incompatible ways:

* Sync XHR * document.open * document.write * AppCache * localStorage

But that can't happen, because the desire of browser implementors to simplify their implementation is less important than the need to keep sites running. Apart from anything else, as stated uptrehad, breaking sites is a sure and certain way to get people to switch to a different browser.

Yes, but security is also the only reason users would accept losing access to certain websites - and then only grudgingly!

Tell a regular browser user they will lose access to their favorite website forever because JavaScript developers prefer writing "flatten" to "flat".

>Because sometimes you want a new feature but the current API does not support it. So you break it and make a new one, keeping the old intact.

This is how things should work. But other than impossible to remove proponents of hardcore live versioning, there are even more proponents of "Keeping 20 years old websites intact without changing a single line of code." So a valid JS 1.0 must still also be a totally valid ECMAScript 2017.

Those believe that it is somehow physically possible to engineer the language parser that it use some extremely sophisticated lexic tools to guess what version of JS something the code refers, those also are the proponents of "lets guess the api version by counting the number of arguments, and if we need a new one, we just add one more"

This is bad.

Why such people can't be taken down from standard committees? One of reason that people close to web standards making process don't want to discuss is that "tech/corporate strategists" at top dotcoms misguidedly believe that by making web standards an impossibly complex to implement thing, they can prevent appearance of newcomers to the browser market, thus making browsers a moat for competitors to drown in.

As Joseph Stalin said - "In a democratic society, the people who rule are not the ones who vote, but ones who count those votes." Those corporate appointees surely share this ideology - Ones who control the Internet business are not companies who run websites, but ones who write browsers to browse them: want to kill an advertising supported website? Put them into Google's secret bad websites list; want to displace a credit card processing competitor? Ban him from using the credit card API to which the browser is locked; want to kill a legal video streaming website? Deny him rights to DRM extensions in the browsers; and like this for all and everything.

This is also why HTML has moved to a "living standard". To avoid versions. The philosophy is to only introduce backwards-compatible changes so everything can be handled by a single engine.

If you prevent builtin overrides now, you'll break the API. We should start discouraging it, as Mozilla does in its MDN. Maybe some deprecationwarning is a good point to start with.

By the way, Javascript was designed in two weeks. I doubt a lot of thought went into such specific details. And the fact that the language doesn't prevent it doesn't make it a good idea - otherwise I'd claim that UB in C is a good idea.

Oh yes, I missed the lack of `prototype`. Sorry for the noise!

You must enjoy commenting without reading the article. The website in question is 22 years old.

The downmod makes it seems like I may have been unclear for those who aren't from a sysadmin background:

an unmaintained website is likely already cracked.

It's not tc39's job to dish out vigilante justice probabilistically for poor operational practices.

It is tc39's job to add js features without breaking websites, however likely they are to be compromised.

Well looking at the form the other operations (map, reduce, filter, etc..) are they usually describe what is being done to the source as a way to describe the output. As opposed to just describing the outcome. That being said there are some weird ones like "some" or "every". Regardless though some other well known FP languages use flatten so it lowers the barrier to entry on the API for people familiar with them.

Personally I somewhat lean towards the side of breaking the library in question, which could be ok if enough warning is given. They mentioned being worried that not everyone would fix their unmaintained sites but I don't think unmaintained sites make a lot of long term promises anyway. Space Jams aside of course.

So while I don't necessarily agree with the decision I completely understand it, their motivation is very noble. And again, it's not that big of a deal as a one off decision.