3 ms·

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

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.

RobertKerans 7y ago
Bloody regenerator is the worst for this (I know, IE11 support and all...). Or, even worse, the "regenerator runtime is not defined" error
lioeters 7y ago
> even though everything is written in ES6, it's shipped as ES5 and you're saddled with this polyfilled crap This is somewhat mitigated by the use of babel-preset-env and browserslist. https://github.com/browserslist/browserslist https://github.com/browserslist/browserslist 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.

RobertKerans 7y ago

Bloody regenerator is the worst for this (I know, IE11 support and all...). Or, even worse, the "regenerator runtime is not defined" error

lioeters 7y ago

> even though everything is written in ES6, it's shipped as ES5 and you're saddled with this polyfilled crap This is somewhat mitigated by the use of babel-preset-env and browserslist. https://github.com/browserslist/browserslist https://github.com/browserslist/browserslist 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.