I’m encouraged by the 2018-04-11 meeting and its discussion of use cases and feature requirements, and the reevaluation of the Node modules effort’s overall goals. I hope that this leads to a final result that works better for everyone.
I wanted to add another goal, or metric of success, or something; I’m not sure where it belongs so I’ll just say it here:
Node should support ES modules without requiring extra tools for what users want to do.
Over the years, when Node has added support for new syntaxes, they’ve “just worked.” If I had been using the syntax before and transpiling via Babel, say, I would turn off that transform in Babel and my code would execute the same as before. I think average users would assume that the same should be true for import and export statements.
This article by @giltayar about Node’s --experimental-modules implementation has a great section near the end about how to create dual-mode packages, that can be imported by a project using either ES modules or CommonJS. The instructions describe using Babel via an NPM script to transpile .mjs files into .js files, to create entry points for each mode. Reading this, I feel like the development team missed the point. So in order to use Node’s “native” module support, I need . . . Babel?
I think that most users would treat interoperability with the existing Node ecosystem as a non-negotiable requirement of any project they work on. If forced to choose between using Node’s native ES module support or preserving interoperability, users are going to choose interoperability (either via CommonJS or tools like Babel or esm). If too many projects have too many “must-have” use cases that preclude them from using Node’s native ES module support, the native support will struggle to find usage. There’s not much point in building a feature that most people won’t use.
Node’s native ES module support needs to be better, both in performance and convenience, than Babel and esm. Those tools are the competition. Every implementation decision that differs from how those tools do things should have a very strong justification, especially if it makes working with modules harder or requires a sacrifice that those tools don’t ask the user to make. Eliminating barriers to adoption and ensuring seamless interoperation with the existing Node ecosystem should be overriding goals of the design of the implementation, above any other concerns.
I’m encouraged by the 2018-04-11 meeting and its discussion of use cases and feature requirements, and the reevaluation of the Node modules effort’s overall goals. I hope that this leads to a final result that works better for everyone.
I wanted to add another goal, or metric of success, or something; I’m not sure where it belongs so I’ll just say it here:
Node should support ES modules without requiring extra tools for what users want to do.
Over the years, when Node has added support for new syntaxes, they’ve “just worked.” If I had been using the syntax before and transpiling via Babel, say, I would turn off that transform in Babel and my code would execute the same as before. I think average users would assume that the same should be true for
importandexportstatements.This article by @giltayar about Node’s
--experimental-modulesimplementation has a great section near the end about how to create dual-mode packages, that can be imported by a project using either ES modules or CommonJS. The instructions describe using Babel via an NPM script to transpile.mjsfiles into.jsfiles, to create entry points for each mode. Reading this, I feel like the development team missed the point. So in order to use Node’s “native” module support, I need . . . Babel?I think that most users would treat interoperability with the existing Node ecosystem as a non-negotiable requirement of any project they work on. If forced to choose between using Node’s native ES module support or preserving interoperability, users are going to choose interoperability (either via CommonJS or tools like Babel or
esm). If too many projects have too many “must-have” use cases that preclude them from using Node’s native ES module support, the native support will struggle to find usage. There’s not much point in building a feature that most people won’t use.Node’s native ES module support needs to be better, both in performance and convenience, than Babel and
esm. Those tools are the competition. Every implementation decision that differs from how those tools do things should have a very strong justification, especially if it makes working with modules harder or requires a sacrifice that those tools don’t ask the user to make. Eliminating barriers to adoption and ensuring seamless interoperation with the existing Node ecosystem should be overriding goals of the design of the implementation, above any other concerns.