bun VS ozzo-dbx

Let’s say you are interested in learning more about Bun and probably give it a try. Bun has a website, where you can learn more about Bun and its features (including all the benchmark data captured in this issue), and here is the link.

I found Bun to be faster. Monorepo support is a bit kludgy though. Once you know of the workarounds, it's ok. See my comment on https://github.com/oven-sh/bun/issues/5413#issuecomment-1956...

AFAIK, Pnpm monorepos do not follow standard npm. Bun does follow standard npm monorepos.

I was quite curious about the .bunx file format. I think this could be a quite a useful thing, a universal binary format. Some tech companies have internal implementations of this sort of system. Then I see the shim DLL:

https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...

Even before this past week's XZ backdoor revelation, checking binaries into source control rather than building from source seems quite questionable. In fairness to the Bun developer's, they have a comment in their build.zig file acknowledging that this shim should be built more normally rather than being checked in.

Then I look into the source for it:

https://github.com/oven-sh/bun/blob/801e475c72b3573a91e0fb4c...

For no discernible reason, it is using a bunch of undocumented Windows APIs. The source cites this Zig issue as one reason for why they think it is OK to use undocumented APIs:

https://github.com/ziglang/zig/issues/1840

I don't see any good reasons here cited for using undocumented, unstable interfaces. For Zig's part, there seems to be some poorly-explained interest in linking against "lower level" libraries without any motivating use case (just some hand waving about security and drivers, neither of which makes much sense. Onecore.lib is a thing if you wanted a documented way of linking an executable that run on a diverse set of Windows form factors. And compiling drivers may as well be treated as a seperate target, since function names are different). For Bun, I assume they are trying to have low binary size. But targeting NTDLL vs. Kernel32 should not make a big difference, especially when the shim is just doing basic file IO. For an example of making small executable with standard API, you can make hello world 4kb using MSVC just by using /NODEFAULTLIB and /ENTRY:main with link.exe and this program :

    #include 

Kind of. When you do try to run bun in production you'll find out that it has significant differences to node -- like not handling uncaught exceptions: https://github.com/oven-sh/bun/issues/429

Then you'll use bun build and run node in production, only to find that sourcemaps don't actually work at all: https://github.com/oven-sh/bun/issues/7427

So you'll switch to esbuild + node in production :)

Definitely excited for the promise of bun, but it's not quite baked yet.

Looks like it, it seems the 2% are mostly odd platform specific issues that the authors' did not deem very important (my assumption for the release happening anyway). AFAIK this[1] PR tries to fix them.

[1]: https://github.com/oven-sh/bun/pull/9729

Yeah I saw a Github discussion where he mentioned that the code for uploading telemetry data was disabled, but he also said he plans to re-enable that at some point: https://github.com/oven-sh/bun/discussions/2605

Granted, this was a year ago, so the Bun team's plans might have changed.

You can track the progress here: https://github.com/oven-sh/bun/issues/1825

There's still a ways to go but folks are actively contributing.

Install Node.js (or Bun, or Deno, or whatever JS runtime you prefer) if it's not there

I think maybe I was unclear. I'm talking about writing libraries that abstract across these differences and provide a single API, as sibling describes. I already know it's possible. I made a simple filesystem abstraction here[0] and a very simple HTTP library that uses it here[1]. They both work in Node/Deno and the browser. Unfortunately I ran into issues with Bun's slice implementation[2]. But I suspect there's a much better way of detecting and using the different backends.

[0]: https://github.com/waygate-io/fs-js

[1]: https://github.com/waygate-io/http-js

[2]: https://github.com/oven-sh/bun/issues/7057

For, for more speed (requires installing bun first):

If you are looking for a query builder only, I also could recommend https://github.com/go-ozzo/ozzo-dbx (it doesn't seem to be maintained but its stable and so far I haven't stumbled on a bug using it for an internal tool)