What does HackerNews think of esm?

> I think the biggest miss was not making mixed mode (default) for Node do it the way webpack/babel, etc did it by default in terms of interop. I get they wanted to make it more implicit to call cjs from esm, in the end it just inhibits conversion of existing libraries as dependencies are now a bigger hurdle.

Huge huge agreement.

I forget the specifics but there was some super tiny corner case around maybe default exports that could potentially create ambiguity & that spawned a multi-year bellyaching around doing anything at all for interop. What Node got was incredibly hard fought for against much resistance to interop.

But the final compromises made everything so much more painful for everyone. So many esm projects but oh look a .eslintrc.cjs, how unsurprising & sad.

It's extra maddening because node had a wonderful just works (except that tiny tiny tiny corner case) interop via @standard-things/esm, which seamlessly let the two worlds interop. It'd been around for years before node started shipping support, and it was no ceremony just works bidirectional interoperability, and it took basically no effort or thought from the developers point of view to use. It sucked seeing us walk back from great, mired by frivolous over concern for a obscure corner-case.

https://github.com/standard-things/esm

It is possible, but you have to hack the Node require() loader to do it, teach it a lot about ESM loading, and then hope the downstream CJS don't have timing bugs around "very long" synchronous require() loads.

https://github.com/standard-things/esm

Indeed, JS does not have classical inheritance. IMO introducing a class syntax that looks so much like the classes from other languages and yet behaves differently was a mistake.

The rest of your comment sounds a bit misinformed to me. You seem to have decided that prototypical inheritance is somehow inherently worse than classical inheritance, but don't mention why that would be. I have found very little practical difference between the classes in JS and other languages in everyday use, and can't quite imagine what the problems with it might be.

Furthermore, ES6 (ES2015) is not a "transpiled language". I think it's obvious that if you take a very new language, say, ES2018 and want to run it on your toaster that doesn't have support for such new languages, you are going to have to do some kind of precompilation step. That is true for ES2018 today and it will be true for ES2019 next year and for ES2020 the year after that.

ES2015, however, has been around for several years. All the modern browsers (that is, all major browsers except IE) support it already. Node 10 even supports the new module loading syntax (behind a flag), or you can use a very lightweight transformer like esm[1] for older Node versions.

And if you do end up using and having problems with, say, Babel, it would be more constructive to give concrete examples of the issues you've had. I personally have never faced a syntax problem where the issue would've been due to a bug in Babel instead of just my incorrect understanding of the language feature.

[1]: https://github.com/standard-things/esm

I know styfle is aware, but for others, you can unlock named exports of CJS modules with @std/esm:

https://github.com/standard-things/esm

https://medium.com/web-on-the-edge/es-modules-in-node-today-...