3 ms·

do you foresee having to make more decisions that come down against web standards for the sake of node compatibility? any tough decisions on the roadmap? to be

by rmorey 4y ago

do you foresee having to make more decisions that come down against web standards for the sake of node compatibility? any tough decisions on the roadmap? to be clear i think you made the right call, but i’m curious if you think this is going to be a recurring issue

eyelidlessness 4y ago
I can’t speak for Jarred or other Bun devs, but I think this has a pretty straightforward answer: if the goal is transparent support for packages written for Node (or some defined subset thereof), that inherently means bug/quirk/extension compatibility too (for whatever subset is being targeted). IMO (not strongly held, largely as a spectator so far), it’s probably a bad thing in the long run for Bun (and Deno, and other JS server/CLI runtimes) to be so beholden to Node compatibility. I’d much rather see these compatibility efforts devoted to isolating Node-specific considerations, with clear guidance on how to migrate existing projects to more portable APIs. Node has already shown positive signs of embracing portability as contenders have also done. In the short term “works with stuff written for Node” is very appealing, but in the long term “Node works for stuff written for standards” is much more appealing than that. The more each of these runtimes courts the former, the more the latter is protracted.
- brundolf 4y ago
  This was the battle I was excited for Deno to take a hard stance on, but it seems like even they have been forced to make some compromises now. It still seems like they envision people moving (gradually instead of all at once) to more consistent and standardized practices, but it doesn't look like we get to cut off the long tail of compatibility after all
Jarred 4y ago
Recent versions of Node.js implement many web APIs. The ecosystem is converging on a mix of web APIs and Node.js APIs. Excluding a few cases (like setTimeout), this won’t be a recurring tradeoff for Bun's runtime APIs (module resolution, however, is complicated).
- DanielHB 4y ago
  A problem I had in NodeJS the other day, NodeJS has 3 stream classes: require("stream").ReadableStream require("stream").Readable require("stream/web").ReadableStream I was using node-fetch and fastify but I decided to remove node-fetch to just use global.fetch and everything broke. Turns out node-fetch and fastify uses require("stream").ReadableStream, but global.fetch() uses require("stream/web").ReadableStream (because it is a web standard). Took me a few hours to figure out why it wasn't working, getting some "ReadableStream is not a ReadableStream" error is very fun to troubleshoot I don't know what approach Bun should take in this regard, but I would like to see NodeJS deprecating non-standards as much as possible so eventually this problem can go away. ECMA should also standardise things required for server-side code more

by rmorey 4y ago

eyelidlessness 4y ago

I can’t speak for Jarred or other Bun devs, but I think this has a pretty straightforward answer: if the goal is transparent support for packages written for Node (or some defined subset thereof), that inherently means bug/quirk/extension compatibility too (for whatever subset is being targeted). IMO (not strongly held, largely as a spectator so far), it’s probably a bad thing in the long run for Bun (and Deno, and other JS server/CLI runtimes) to be so beholden to Node compatibility. I’d much rather see these compatibility efforts devoted to isolating Node-specific considerations, with clear guidance on how to migrate existing projects to more portable APIs. Node has already shown positive signs of embracing portability as contenders have also done. In the short term “works with stuff written for Node” is very appealing, but in the long term “Node works for stuff written for standards” is much more appealing than that. The more each of these runtimes courts the former, the more the latter is protracted.

brundolf 4y ago
This was the battle I was excited for Deno to take a hard stance on, but it seems like even they have been forced to make some compromises now. It still seems like they envision people moving (gradually instead of all at once) to more consistent and standardized practices, but it doesn't look like we get to cut off the long tail of compatibility after all

Jarred 4y ago

Recent versions of Node.js implement many web APIs. The ecosystem is converging on a mix of web APIs and Node.js APIs. Excluding a few cases (like setTimeout), this won’t be a recurring tradeoff for Bun's runtime APIs (module resolution, however, is complicated).

DanielHB 4y ago
A problem I had in NodeJS the other day, NodeJS has 3 stream classes: require("stream").ReadableStream require("stream").Readable require("stream/web").ReadableStream I was using node-fetch and fastify but I decided to remove node-fetch to just use global.fetch and everything broke. Turns out node-fetch and fastify uses require("stream").ReadableStream, but global.fetch() uses require("stream/web").ReadableStream (because it is a web standard). Took me a few hours to figure out why it wasn't working, getting some "ReadableStream is not a ReadableStream" error is very fun to troubleshoot I don't know what approach Bun should take in this regard, but I would like to see NodeJS deprecating non-standards as much as possible so eventually this problem can go away. ECMA should also standardise things required for server-side code more