4 ms·

> unburdened by the historical baggage of Node Is this even possible anymore? Deno made a valiant attempt, but with every release, the best received update se

by sramam 4y ago

> unburdened by the historical baggage of Node Is this even possible anymore? Deno made a valiant attempt, but with every release, the best received update seems to be the node/npm compatibility.

brundolf 4y ago
I see NPM compatibility as a temporary stopgap. They tried to make a hard break all at once, and then Bun made it clear that no, actually people still really want access to that existing ecosystem for now. But new code written for Deno starts out on that better foundation without CommonJS, several different module-resolution algorithms, manual transpilation, competing linting and testing standards, etc etc. They just need to bridge the gap in the meantime, until Deno's own ecosystem gets more filled out. That's the dream anyway.
- SOLAR_FIELDS 4y ago
  The pedigree of Deno does speak for at least something as well. Who better to address the flaws of a lasting project someone created than the creator themselves? Just from incentive alignment it’s a powerful motivator.
lucideer 4y ago
What's interesting though is that the compatibility effort seems to be on all sides. Deno has acted somewhat like a forcing function - I think a lot of Node folk want to move away from CommonJS in general (even staying within the NPM ecosystem) & having multiple targets for modules you write has given that effort some good pushes. A simple example of this in my mind is the node: prefix added to CommonJS functions in NodeJS. This has some perf/caching advantages, which may have been the main driver, but also introducing a protocol prefix to module strings happens to improve extensibility/flexibility/compat across the ecosystem - there are transpilers that change e.g. import to require() or vice-versa, so extra context in module strings is helpful there. Deno's npm: prefix has a similar effect (it would be cool if this made it into Node someday - having control over module locator strategy at import granularity seems interesting; it would certainly make a lot of bundler hacks currently in use for things like CSS/etc. simpler)

by sramam 4y ago

> unburdened by the historical baggage of Node Is this even possible anymore? Deno made a valiant attempt, but with every release, the best received update seems to be the node/npm compatibility.

brundolf 4y ago

I see NPM compatibility as a temporary stopgap. They tried to make a hard break all at once, and then Bun made it clear that no, actually people still really want access to that existing ecosystem for now. But new code written for Deno starts out on that better foundation without CommonJS, several different module-resolution algorithms, manual transpilation, competing linting and testing standards, etc etc. They just need to bridge the gap in the meantime, until Deno's own ecosystem gets more filled out. That's the dream anyway.

SOLAR_FIELDS 4y ago
The pedigree of Deno does speak for at least something as well. Who better to address the flaws of a lasting project someone created than the creator themselves? Just from incentive alignment it’s a powerful motivator.

lucideer 4y ago

What's interesting though is that the compatibility effort seems to be on all sides. Deno has acted somewhat like a forcing function - I think a lot of Node folk want to move away from CommonJS in general (even staying within the NPM ecosystem) & having multiple targets for modules you write has given that effort some good pushes. A simple example of this in my mind is the node: prefix added to CommonJS functions in NodeJS. This has some perf/caching advantages, which may have been the main driver, but also introducing a protocol prefix to module strings happens to improve extensibility/flexibility/compat across the ecosystem - there are transpilers that change e.g. import to require() or vice-versa, so extra context in module strings is helpful there. Deno's npm: prefix has a similar effect (it would be cool if this made it into Node someday - having control over module locator strategy at import granularity seems interesting; it would certainly make a lot of bundler hacks currently in use for things like CSS/etc. simpler)