I think I see what you're saying, and I agree about supporting older platforms.
But wow, when the ES6 features hit, and I could use them NOW, in spite of having to support IE? That was huge, and made the code so much nicer in so many ways.
I was really glad that I could, as the snaky folks say, "import from future".
I am biased from working so much with SPA frameworks like Angular and React, at this point I've given up. So many frontend processes these days involve some kind of build process to minify or transpile that I figure... why not always use the most advanced features?
May as well pick the JavaScript/TypeScript flavor with the best developer ergonomics.
Likewise. We have a big important codebase that was started a little before all the ES6 features hit. Had it been written in ES5 at the time it would be a pain to work in. However it's still a pleasure because it is ES6 with snippets from ES7. We no longer use the transpiler, and were disciplined about only using features that were definitely coming. I'm glad we did.
Yeah, there's no way to convince people to write ES5 once they've seen ES6+. :-) But the problem was that the JS ecosystem never totally got a consistent story about how to stop transpiling. They were transpiling in Node, which makes no damn sense. They were shipping transpiled bundles without the code needed to turn the transpilation off in the future. It was and is a big mess where now that ES6 is supported everywhere, you can't actually use it because even though everything is written in ES6, it's shipped as ES5 and you're saddled with this polyfilled crap even if you don't want it.
It's not the worst problem for an ecosystem to have, but as someone who wants to ship smaller JS bundles, I find it annoying.
Where I work, our build tool uses a list that's (very slowly) getting reduced to evergreen browsers. On some projects, a simpler list can be used for little to no polyfills.
> transpiling in Node, which makes no damn sense
A legitimate use case would be for server-rendered apps, where it's advantageous to share code with client-side, namely transpiling module import/export (rather than CommonJS) and JSX. I do enjoy how recent versions of Node.js are embracing modern language features, even pipeline operator. Still, there are situations where transpiling server-side code makes sense.
Another maybe more relevant reason is using TypeScript, which arguably provides a leap in developer experience and code quality, beyond what browsers (or the V8 engine) would implement in the foreseeable future.
But this is taking one of the worst parts of the Javascript ecosystem and inventing it for Ruby. Despite Ruby not suffering from Javascript problems like having a subpar standard library and missing essential language features like a standard import syntax.
But wow, when the ES6 features hit, and I could use them NOW, in spite of having to support IE? That was huge, and made the code so much nicer in so many ways.
I was really glad that I could, as the snaky folks say, "import from future".