Comment by stupidcar | Hacker News Reader

Comment by stupidcar | Hacker News Reader

The "don't break the web" excuse is the same old bad-faith nonsense:

1. The number of websites using the old version of Mootools is vanishingly remote, relative to the number of existing websites not using it, and the number of as-yet-unmade websites who will also not use it (but who will be harmed by the committee's dedication to retarding the development of the language).

2. Of those websites using this old version of Mootools, the number that use flatten, and do so in a way that would definitely be broken by the introduction of standardised "flatten", and wouldn't be fixed thereafter is, statistically speaking, zero.

3. Most of the same people who are affecting concern about backwards compatibility in the case of the web work for tech giants who regularly retire products and APIs that are relied upon by thousands of people, and make backwards incompatible changes to their operating systems that break masses of unmaintained apps.

But the fact is, you can't make arguments like this to groups like the TC39 and expect to even get a hearing. Despite their occasional spiel about seeking outsider feedback they are, like any institution, happy in their long-settled groupthink positions, and reflexively frightened and dismissive of any challenge or criticism by outsiders.

You saw this when the whole "smoosh" affair first broke. There was a long, passionate, but civilised debate about it on GitHub (https://github.com/tc39/proposal-flatMap/pull/56 ) which was abruptly cut off by a TC39 committee member, who locked out non-contributors entirely, with the dishonest claim that things had become "too heated". What he really couldn't stand was the sight of the committee's dogma being challenged.

Remember that next time the representative of a standards body whines about lack of participation in the process by regular web developers. It's a lie. These groups are only interested in the opinion of outsiders if they align with a set of fixed and unchallengeable precepts, and they will revert to depressingly familiar suppression of speech the moment it looks like things aren't going their way.

Frankly, as an outsider, your post doesn't convince me. Where's your source for (1) and (2)? I read the whole GH thread and didn't find anyone presenting credible data. (3) is even weaker; it's perfectly reasonable to distinguish between an external API and the runtime of the web (it's also fine to disagree with this distinction, of course).

Also, at least two, maybe three comments were moderated for violated the code of conduct, and the commenter admitted his language was inappropriate. So there's an argument to be made that the conversation was too heated. Again, you can disagree, but your opinion doesn't make anyone else's invalid or bad-faith.

I also saw multiple committee members discussing the counterarguments, and by the time the thread was locked it was essentially just rehashing the same points. So I find it hard to agree with your claim that they refused to hear dissenters.

A link in TFA that contains 'The 1.3% of HTTPArchive's URLs that have MooTools present.'

https://gist.github.com/paulirish/a135445fc84f7ca5c486b52d56...

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).

The big problem is the incentive structure.

TC39 can't introduce breaking changes because browsers won't implement breaking changes.

Browsers won't implement breaking changes because users would switch to other browsers which don't implement breaking changes.

It doesn't matter whose "fault" it is, if a website works in one browser but not in another, users are going to use the browser it works in.

This is not true, browsers have removed language features before, typically for security reasons.

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".

I've made most of these points before https://certsimple.com/blog/break-the-web, but will add: we now have a bunch of verbs you can do with an array - like splice, join, shift, reverse - and suddenly we have a noun method called flat.

Inconsistency aside, naming non-accessor functions and methods nouns is a bad practice anyway.

The discussion comes down to whether a significant amount of websites (in absolute numbers) will break. The article hints to "extensive telemetry" to figure out the number of affected sites but doesn't cite any numbers. On the other hand you don't cite any numbers or empirical evidence either.

Reply on news.ycombinator.com