4 ms·

The argument is we'd be better off if ES Modules were never proposed or implemented because the require syntax is better. By splitting the ecosystem, the develo

The argument is we'd be better off if ES Modules were never proposed or implemented because the require syntax is better. By splitting the ecosystem, the developer experience has been made worse for no tangible benefit. Like this is not just the pain of transition from an old thing to a new thing, it's a straight up mistake and it should've never happened.

lelanthran 3y ago
When standardised languages lack a feature that the community needs, they tend to add it in. Leaving the module system undefined and unstandardised was going to be bad for JS. There is no future proofing at all. With standardisation comes strong guarantees of future proofing.
- jrochkind1 3y ago
  I am really not an expert at this area. It seems obvious to me too that leaving the module system not officially spec'd as a JS standard would be terrible to JS... but maybe not to OP? Or they think "exactly like what CommonJS currently is" could and should have been that standard? (I'm guessing there are reasons people, at least at the time, thought CommonJS wouldn't have worked as the standard, or needed to be improved upon and it was worth it to do so?) I wish the OP actually covered some of this stuff. Without it, not being an expert, I'm having trouble following what exactly their critique is, although I understand they wish they didn't have to deal with both CommonJS and ES Modules... but yeah, we clearly needed a JS standard, right? Or not?
  - WorldMaker 3y ago
    I think any discussion of the comparisons between CommonJS and ES Modules can be tough because "everybody" has already forgotten (or never learned in the first place) the lessons of AMD modules (and UMD modules). CommonJS cannot run in the browser unbundled. Eventually the Node ecosystem built a lot of good bundlers that fake it well enough to kill AMD (and UMD) modules, but before all of that AMD (and UMD, which was basically CommonJS in an AMD wrapper that could itself run as CommonJS, and exactly the turducken that sounds like as a design pattern) was built to solve real browser runtime problems that CommonJS ignored or never solved: browsers are inherently asynchronous (downloading a JS file from a URL takes wall clock time more often than not); browsers don't have any view of a server's file system beyond the basic HTTP verbs on previously-formed URLs and to query for files even if it isn't to download them is still a slow discovery process; etc and so forth. It was good riddance to AMD (and UMD) when bundlers killed them, but bundlers in turn gave too much of an impression that CommonJS was "sufficient" as people forgot the lessons of AMD modules. It kind of was sufficient, for a time, if you didn't mind browser code being trapped in bundlers and build processes for presumably the rest of time. ESM took the lessons of AMD and applied nice syntax to them (writing AMD modules by hand was an awful experience, from personal experience; it led me to adopting Typescript 0.x in a past life before Typescript was even officially "stable") with further advantages that even AMD didn't support. ESM is async-always (and tree shakeable) and makes no assumptions about server file system trees. Good riddance to AMD and UMD. I can't wait for CommonJS to go the way of that dodo and finally wish good riddance to "mandatory" bundlers for CommonJS dependencies, too. I'm glad so many frontend developers never experienced the pains of AMD that they've almost collectively lost the lessons of AMD already. I can't wait for CommonJS to similarly feel like a bad memory of an old nightmare.

lelanthran 3y ago

When standardised languages lack a feature that the community needs, they tend to add it in. Leaving the module system undefined and unstandardised was going to be bad for JS. There is no future proofing at all. With standardisation comes strong guarantees of future proofing.

jrochkind1 3y ago
I am really not an expert at this area. It seems obvious to me too that leaving the module system not officially spec'd as a JS standard would be terrible to JS... but maybe not to OP? Or they think "exactly like what CommonJS currently is" could and should have been that standard? (I'm guessing there are reasons people, at least at the time, thought CommonJS wouldn't have worked as the standard, or needed to be improved upon and it was worth it to do so?) I wish the OP actually covered some of this stuff. Without it, not being an expert, I'm having trouble following what exactly their critique is, although I understand they wish they didn't have to deal with both CommonJS and ES Modules... but yeah, we clearly needed a JS standard, right? Or not?
- WorldMaker 3y ago
  I think any discussion of the comparisons between CommonJS and ES Modules can be tough because "everybody" has already forgotten (or never learned in the first place) the lessons of AMD modules (and UMD modules). CommonJS cannot run in the browser unbundled. Eventually the Node ecosystem built a lot of good bundlers that fake it well enough to kill AMD (and UMD) modules, but before all of that AMD (and UMD, which was basically CommonJS in an AMD wrapper that could itself run as CommonJS, and exactly the turducken that sounds like as a design pattern) was built to solve real browser runtime problems that CommonJS ignored or never solved: browsers are inherently asynchronous (downloading a JS file from a URL takes wall clock time more often than not); browsers don't have any view of a server's file system beyond the basic HTTP verbs on previously-formed URLs and to query for files even if it isn't to download them is still a slow discovery process; etc and so forth. It was good riddance to AMD (and UMD) when bundlers killed them, but bundlers in turn gave too much of an impression that CommonJS was "sufficient" as people forgot the lessons of AMD modules. It kind of was sufficient, for a time, if you didn't mind browser code being trapped in bundlers and build processes for presumably the rest of time. ESM took the lessons of AMD and applied nice syntax to them (writing AMD modules by hand was an awful experience, from personal experience; it led me to adopting Typescript 0.x in a past life before Typescript was even officially "stable") with further advantages that even AMD didn't support. ESM is async-always (and tree shakeable) and makes no assumptions about server file system trees. Good riddance to AMD and UMD. I can't wait for CommonJS to go the way of that dodo and finally wish good riddance to "mandatory" bundlers for CommonJS dependencies, too. I'm glad so many frontend developers never experienced the pains of AMD that they've almost collectively lost the lessons of AMD already. I can't wait for CommonJS to similarly feel like a bad memory of an old nightmare.