3 ms·

> there are 2 standards (CommonJS and ES6 modules), and that require is CommonJS and import is ES6 modules Kind of, but not really. There are JavaScript modul

by cxr 5y ago

> there are 2 standards (CommonJS and ES6 modules), and that require is CommonJS and import is ES6 modules Kind of, but not really. There are JavaScript modules as defined by the ECMAScript standard and implemented in Web browsers and anyone else who cares about implementing the spec, and then there is NodeJS, which has its own way of doing things, along with people who refuse to give it up and insist on dragging those headaches into places where you should not otherwise expect to see them. People call the latter "CommonJS modules" (including e.g. the TypeScript team), but in fact CommonJS is a whole thing on its own that NodeJS doesn't actually follow. The thing that CommonJS and NodeJS-style imports have in common is that both used the `foo = require("bar")` convention. To understand the mess that is the current JS ecosystem (and hopefully how to get out of it), people really need to come to grips with recognizing NodeJS's role as an IE-like entity: - 800-pound gorilla - not under the control of the best and the brightest - implements its own share of proprietary (vendor-specific) shenanigans - the people who shamelessly target it and see nothing wrong with doing things this way are the source of the the worst problems within the ecosystem or on a given project - responsible for a massive corpus of legacy junk that you are expected to be familiar with and that it will take years to clean up

have_faith 5y ago
Using ES mudules everywhere seems to be picking up steam recently. It is annoying jumping between frontend files and backend files in the same project using different module systems. I think in about 6 months not touching common js modules from front-to-back for a whole project will be viable without major quirks.
jsmith45 5y ago
To my knowledge what node implements is nearly a superset of CommonJS. It is true that a pure CommonJS implementation cannot handle many node packages due to additional features that node has added to the module descriptor, or due to use of node specific built-in packages/globals/extra properties on require, etc. But I was under the impression that node could generally import and handle strictly conformant CommonJS packages just fine in practice. Of course, I won't argue that many npm packages not being conformant CommonJS packages makes things difficult for non-node server-side javascript environments, since they either need to add additional node compatibility, or might need their own package repository.

by cxr 5y ago

have_faith 5y ago

Using ES mudules everywhere seems to be picking up steam recently. It is annoying jumping between frontend files and backend files in the same project using different module systems. I think in about 6 months not touching common js modules from front-to-back for a whole project will be viable without major quirks.

jsmith45 5y ago

To my knowledge what node implements is nearly a superset of CommonJS. It is true that a pure CommonJS implementation cannot handle many node packages due to additional features that node has added to the module descriptor, or due to use of node specific built-in packages/globals/extra properties on require, etc. But I was under the impression that node could generally import and handle strictly conformant CommonJS packages just fine in practice. Of course, I won't argue that many npm packages not being conformant CommonJS packages makes things difficult for non-node server-side javascript environments, since they either need to add additional node compatibility, or might need their own package repository.