Readit NewsDeleted Comment
This crusade is nowhere near zealous nor righteous enough against the infidels & non-believers.
But it also hasn't been effective enough at supporting/supplying the crusade either.
Matteo's statement was that Node hasn't stabilized their loader support so tools have a harm time migrating to esm. Imo it's a pity ecmascript never stabilized a module registry, that esm 1.0 shipped & most people thought it would happen; it's long felt like a bait & switch. But it wasn't a feature browsers needed or really wanted so that unfulfillment was unsurprising. Anyhow, IMO Matteo is making a technical point that it's still hard to finish the move, which is a different spin IMO than a "advocated a moderate approach".
Given the hurt we legitimately experience, I really wish Node and/or WinterCG or someone would prioritize figuring out & implementing whatever needs to go into a module registry/loader. And then beg the big tool chains that need this stuff to expedite their migrations, pretty pretty please.
It only became awful for me when people started publishing pure ESM packages; `npm i node-fetch` suddenly began resulting in broken scripts and I had to learn why. Prior to that, I happily used CJS outside of the browser and what I suppose is ESM in the browser (the `import` syntax provided by bundlers).
> a different spin IMO than a "advocated a moderate approach".
He said, "If your module target the Browser only, go for ESM. If your module target Node.js only, go for CJS."
This is moderate compared to the "Pure ESM" approach. The fetch API is built into browsers so I don't see why anyone would use `node-fetch` outside of Node.js, and yet the maintainers of `node-fetch` went Pure ESM anyway. Also that GitHub issue is titled "When will CommonJS modules (require) be deprecated and removed?" and his response was "There is no plan to deprecate CommonJS"[0].
0 - https://github.com/nodejs/node/issues/33954#issuecomment-776...
Sindresorus wrote a gist "Pure ESM modules"[0] and converted all his modules to Pure ESM, breaking anyone who attempted to `require` the latest versions of his code; he later locked the thread to prevent people from complaining. node-fetch released a pure ESM version a year ago that is ~10x less popular than the CommonJS version[1]. The results of these changes broke a lot of code and resulted in many hours of developers figuring out how make their projects compatible with Pure ESM modules (or decide to ignore them and use old CommonJS versions)--not to mention the tons of pointless drama on GitHub issues.
Meanwhile, TC-39 member Matteo Collima advocated a moderate approach dependent on where your module will be run [2]. So the crusade is led not by the Church, but by a handful of zealots dedicated to establishing ESM supremacy for unclear reasons (note how Sindresorus' gist lacks any justifications and how weak TFA's justifications are). It's kind of like the Python 2 to 3 move except with even less rationale and not driven by the core devs.
0 - https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3...
1 - https://www.npmjs.com/package/node-fetch?activeTab=versions
2 - https://github.com/nodejs/node/issues/33954#issuecomment-924...
React had some obvious red flags; it seemed unwise to re-render entire components each time and regenerate the DOM instead of trying to work with it; it's a hack. It's not difficult to think of scenarios were it fails; for example think of what happens to an element's scroll bar after it has been re-rendered from scratch; it resets... Yet people kept coming up with workaround after workaround to all these kinds of issues. If they had tried PolymerJS (which was going for a native Web Components approach and interfaced nicely with the DOM instead of bypassing it), they would have questioned React's merits. When the useEffects hook was introduced in React, to me, that was a vindication of Polymer's stance (which it had figured out years earlier) that you couldn't completely pretend that DOM elements don't exist, yet React's solution was not as elegant as Polymer's as it was tacked on as an afterthought rather than as a carefully thought out design decision.
Nowadays, with native Web Components (HTMLElement) in most browsers, I don't see why people would still start projects with React, especially given the massive number of dependencies it typically introduces and how often they keep changing stuff and breaking compatibility.
They promised a simple component library which would be the answer to our prayers. What we got instead is a 7 year religious pilgrimage which involved a million developers simultaneously trying to make sense of it; attempting to discover its true form by inventing abstraction upon abstraction and growing increasingly fanatical as it devolved into a wicked monstrosity which should have brought the wiser among us to our knees, begging for JQuery.