3 ms·

> The future of scripting languages is browser JavaScript. The fundamental mistake of Node.js was diverging from the browser as new APIs were standardized, inve

> The future of scripting languages is browser JavaScript. The fundamental mistake of Node.js was diverging from the browser as new APIs were standardized, inventing too much. In 2010, we didn’t have ES modules, but once it was standardized it should have been brought into Node Everyone likes s**g on JS/Node.js, but things are a lot more nuanced than this. In Javascript it's been normal that first there's some user-land fix to some problem, then it's implemented within the language core, and then things move over, including (not surprisingly) ESModules. The problem is that the way ESM was implemented was totally incompatible with CommonJS, making the transition a really painful one. On the other hand and TBF, Node.js innovation has slowed significantly and instead focused on stability, which is good to some but not to others (see the founder creating Deno with an implementation closer to the browser). So what has happened is, effectively, what has always happened: Node.js ("userland" for the standard) introduces new concepts, then the ECMAScript body makes it a standard that it's similar but not the same, then Node.js has to change everything to adapt to that standard, and it's a PITA and leaves everyone scalded and burned out. Node.js in particular had to innovate a lot since it's running the same language in a different context, so all of these have followed that path: AJAX, fetch(), crypto, pipes, promises, request handling, Buffer, ESM/commonjs, etc. Most of the things we use day-to-day.

capableweb 4y ago
> In Javascript it's been normal What you're describing is not just "normal", but the way standards works in the web space, both in theory and in practice, driven by both browsers and the standard bodies. 1. Developers/browser developers want to be able to do something in browsers 2. One engine implements it, developers start building with it 3. Second engine implements it 4. Work begins to standardize it 5. Both (all) engines starts moving from their implementation, to the standardized one If the step after one of the steps doesn't happen (like only one browser implements a new API), the next step doesn't happen. Standards are not created for one engine, but if at least two engines have implemented something.

capableweb 4y ago

> In Javascript it's been normal What you're describing is not just "normal", but the way standards works in the web space, both in theory and in practice, driven by both browsers and the standard bodies. 1. Developers/browser developers want to be able to do something in browsers 2. One engine implements it, developers start building with it 3. Second engine implements it 4. Work begins to standardize it 5. Both (all) engines starts moving from their implementation, to the standardized one If the step after one of the steps doesn't happen (like only one browser implements a new API), the next step doesn't happen. Standards are not created for one engine, but if at least two engines have implemented something.