* Vendor-locked-in with proprietary APIs like Bun.serve, Bun.file, etc.
What does this mean? Every JS runtime (node, deno, bun etc.) has its own set of APIs and they are generally not cross-compatible. The code for all the Bun APIs is open source so I'm not sure what makes them proprietary.
You can call JS in Bun, but you cannot call Bun APIs in JS
Bad use of terminology. JS is the language, JavaScript/ECMAScript, and every JS runtime (node, bun, deno etc.) is using it. So you definitely can call Bun APIs in JS.
That's not a big problem, e.g. if you are using a Bun API for speed or some other specific reason, you can always do:
if (typeof Bun === "undefined") {
// Node.js code
} else {
// Bun code
}
If you are writing a lot of Bun-specific code, yeah that will only work on Bun ofc. But I like that now I can add some small snippets of bun-optimized code in my libraries.
Otherwise, normally you'd use ESM APIs > Node.js APIs > Bun APIs, like if you are hashing something, right?
Comments
What does this mean? Every JS runtime (node, deno, bun etc.) has its own set of APIs and they are generally not cross-compatible. The code for all the Bun APIs is open source so I'm not sure what makes them proprietary.
Bad use of terminology. JS is the language, JavaScript/ECMAScript, and every JS runtime (node, bun, deno etc.) is using it. So you definitely can call Bun APIs in JS.
The catch is that Node APIs are supported by Node, Deno and Bun. But not vice-versa, which makes them vendor-specific
That's not a big problem, e.g. if you are using a Bun API for speed or some other specific reason, you can always do:
If you are writing a lot of Bun-specific code, yeah that will only work on Bun ofc. But I like that now I can add some small snippets of bun-optimized code in my libraries.Otherwise, normally you'd use ESM APIs > Node.js APIs > Bun APIs, like if you are hashing something, right?