In the section related to node.js compat, they state:
> Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.
The detailed breakdown explicitly states which modules are not supported.
> Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.
The detailed breakdown explicitly states which modules are not supported.
---
[1] Not a drop-in replacement
That's up to you, and society. Do you accept that tall people exist?
Right. Now exactly what height do you need to be a "tall person"?
This is the same. I haven't used it so I can't say how optimistic their "drop-in replacement" claim is, but they certainly don't need it to work 100% of the time with 100% of project with 0 changes to make that claim.
If you call something a drop in replacement and it is not a drop in replacement, it's simply a lie.
That's obviously wrong, because there are things that could be different while the API/compatibility is still matching 1:1, such as:
- speed, memory usage, memory safety
- additional features, more capabilities
- simple licensing stuff
Imho, a drop-in replacement actually suggests that you can simply swap out the runtime and expect your code to work out of the box.
It does generally suggest a high degree of compatibility to me though.
> [Drop-in replacement] refers to the ability to replace one hardware or software component with another one without any other code or configuration changes being required and resulting in no negative impacts.
But it works enough of the time without any changes that it's reasonable to call it a drop-in replacement.
It seems the note mentioning this feels buried for me under a large banner image, instead of near all the other text about compatibility.
Anyway, glad it is there, hope that their communications design improves in the future as at least a few others got caught with mismanaged expectations.