41–50 of 152 posts
I guess it's all irrelevant when you don't use Node, aren't publishing libraries, and are compiling all JavaScript into bundles for deployment and never read the bundled code.
Wow that was informative. So ES Modules is really about the Red functions [1] getting module support. I find it fascinating watching our understanding of async computation mature over the years. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
The whole point of that article is that it hasn't really matured at all
I cannot find the others though.
And the article is not even talking about default imports on transpiling with tsc or babel (or both!). Too many combinations.
Rollup makes building both CJS and ES versions of a library fairly straightforward. https://rollupjs.org/guide/en/#outputformat
CJS has a single export which might be an object. And objects have named properties/fields.
On the other hand, ESM CAN have unnamed "default" export and CAN have arbitrary number of named exports.
I’ll conclude with three guidelines for library authors to follow: Provide a CJS version of your library Provide a thin ESM wrapper for your CJS Add an exports map to your package.json This seems like the same fallacy of python’s 2to3, and why they should have written 3to2 instead. If ESM is the new way, library authors should instead have a CJS shim to prevent fossilization of cruft.
2to3 was still useful because all code was in python 2 when python 3 first came out.
The (comparatively) few Python 2 projects that were alive by the release of Python 3 and still alive by the EOL of Python 2 could probably have been upgraded manually, rather than with a tool.
On the other hand, people not wanting to write new code in Python 3 because it would be incompatible with the Python 2 ecosystem – that was a real problem. That problem could have been prevented with a 3to2 tool, which would compile the Python 3 code to Python 2, allowing it to be used with the existing ecosystem.
If only people would have written new code in Python 3 right away, we would have been in a far better position by the time Python 2 would have been EOL'd, purely due to natural turnaround of code bases.
Porting Python 2 code to Python 3 was never the problem. Writing new code in Python 3 was.
I’ll conclude with three guidelines for library authors to follow: Provide a CJS version of your library Provide a thin ESM wrapper for your CJS Add an exports map to your package.json This seems like the same fallacy of python’s 2to3, and why they should have written 3to2 instead. If ESM is the new way, library authors should instead have a CJS shim to prevent fossilization of cruft.
This is incredibly insightful. I'm frankly a bit stunned. I would never have thought of this (and clearly the Python people also didn't) but it is absolutely true. It's also a very transferable strategy for any time compatibility is to be broken.
Is this an original thought of yours or do you have references to further reading?
In two-and-a-half months the last 5 stable releases on Node, the last 2 LTS releases of Node, and all current major browsers will support standard JS modules. It's time we all published standard JS modules and only standard JS modules to npm.
I feel the opposite. ESM is a nightmare and I hope I can avoid using it in node as long as possible.
IE had many non-standard APIs that were much more convenient to use than what the standard was providing (innerHTML, document.all)
And rather than moving to the standard, more and more code was written targeting IE which also had a conveniently large user-base.
ESM is the standard. CJS is the solution proprietary to node.js.