That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevant users for all or even most projects will be on the latest evergreen browsers. Several large groups, including business users on IE and mobile users on slightly older devices, probably won't be.
I know there's a certain type of web developer who would love for everyone to have updated their browser within the last five minutes so all the new toys are available universally, but that has never been the nature of web development. Deliberately breaking major infrastructure is just going to make JS development even more screwed up than it already is.
Which leads me to wonder: are developers that are so willing to advocate breaking compatibility with older browsers actually deploying real sites that have normal representative user audiences? Or is this an insular group of developers mostly making things for each other?
So while there's still likely an insular group at play, it's not limited to just developers.
IE11 is a different case entirely, though. Almost everything still gets significant traffic on that platform, and in the business world supporting it is pretty much essential. Not much ES6 support there, though.
Then, I don't understand the rest of the argument. Open Source software has simply won in the marketplace, mostly because of it's openness, rarely because of it's price.
Example: Operating Systems, which is the rare beast where an actual closed-source competitor still exists. Yet the Windows marketshare on the server is around 10%, and I doubt that it's the price that encourages all those Unicorns to chose Linux. Databases are a similar story.
> Neither of these necessarily implies writing or maintaining ideal tools to support web development more widely
It doesn't necessarily do that, but in the case of Google specifically, it does: they need the open web as a platform to compete against the "walled gardens" of Apple and Facebook. Their interests happen to be aligned with those of web developers, which is why Chrome has revitalised browser competition, easily beating the laser-focused team at Mozilla.
> Unfortunately, because so much of the influence is now concentrated with so few organisations or even individual people
The influence is spread out far wider today than it was at the time where Microsoft and Flash were able write APIs without asking anybody.
But, more importantly, I'm unsure what you want? A version of React that supports IE 6 and lynx? They have that, it's called XHTML 1.0 Transitional.
If there's no Good chosen, then it all gets crufty and full of tech debt. So someone else thinks they can do better, and starts developing a replacement. In order to get traction, though, they need to make it Free and develop it Fast, so after a while they start taking a few short-cuts, and round we go again.
I have faith that it'll settle down eventually, but until then...
Recently, I updated the browser support docs for my employer, and was surprised to note that IE11 is now the oldest browser with standard vendor support, so everybody on older versions of IE is either working for a company with specific extended support contracts with Microsoft, or they are running with no support at all.
Make sure to state "For security reasons" policies always have that even when it's not true, or bad security, because most people don't question it.
Sure, google.com probably needs to support IE 6. For my own business, I'm not willing to make compromises for browsers below 2%. That currently means Safari 10, Chrome 56, and IE 11. And IE 11 is really stretching it by now–next time it gets in my way, I'll give people a reason to upgrade.
Now I don't have "enterprise" customers, and it's a rather small business. For anything medium-size up, the calculus changes, and probably makes it worthwhile. But at some point, these mystical "enterprises" really have to get their act together and stop dragging technology back to 2006.
But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.
No, it isn't. For a lot of web developers, two of those aren't major browsers at all and you've missed the 800lb gorilla. You're also ignoring older versions of mobile browsers, the current Firefox ESR, and at least one other browser that has a larger market share than several of the above in parts of Asia, among other things.
But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.
And consequently, the entire community has to start incorporating a heavyweight build process that relies on third party tools just to use modules from the de facto standard package repository, and everyone also has to take extra time checking the exact requirements for every module they directly or indirectly depend on to make sure their build process supports it. In an ecosystem with absurd levels of microdependencies, which is certainly what we have today in JS world, the last thing we need is moving goalposts on the basic assumptions that everyone makes. This sort of thing is exactly why proper, long-lived standards are important as the foundation of a productive development ecosystem.
Not sure the 800lb gorilla you're referring to, but maybe UC Browser? That thing is so odd it's difficult to know what it supports, and it's not supported in nearly any popular CI service. I'm sure all kinds of things are broken on it, but you can still compile your app to ES5.
And ES6 _is_ a proper long lived standard. I'm not sure what would be more standard.
Compiling dependencies is not that heavyweight, especially when there is no configuration. Babel and TypeScript are fast. The results can be cached, it can be done on the fly for dev servers. Requirements shouldn't need to be checked - I'm not advocating for distributing code using decorators or class properties, nor modules (which without the HTML spec on module specifiers isn't a fully functional spec anyway) just plain ES6.
ES5 and ES6 classes cannot coexist on the same proto chain. Compiling to ES5 prevents things like mixins being usable against ES6 superclasses, so you force all dependents to be ES6. If you're going to force one way or the other, force in the future direction where there's still the option to compile the whole app to the older version of JS. ES5 classes can't extend subclassable built-ins like Array, Promise, Set, Map, HTMLElement, Error, etc. ES5 is now mostly slower than the equivalent ES6, it also doesn't minify as well as ES6.
IE11, older FF and Chrome, and especially older mobile devices with older Webkit based browser (Android and iOS)
