I have been incredibly impressed with Bun after using it in some smaller projects. Compared to Deno, it feels like a true alternative to Node.js. It’s so nice to have a TS-native runtime.
I really want a runtime that actually leverages the type hints for JIT optimization.
(I find the experience of -using- what it actually has to be excellent but 'native' is definitely an overloaded usage here)
But ultimately the way a JIT like Turbofan works is that it will do better optimizations if your JS code is already monomorphic (functions signatures, object fields and so on).
Now TS sort of nudges you that way if you write simple TS code. But due to structural typing, expressive type golf features and the fact that TS is generally unsound I doubt it would be easy to leverage type hints much beyond that.
Here are two talks that are very much related and give some insights into how difficult these kinds of problems are:
https://thestrangeloop.com/2022/of-javascript-ahead-of-time-...
https://www.thestrangeloop.com/2019/typing-the-untyped-sound...
It would be an extra constraint for an extra layer of guarantee and ideally performance.
Although my feeling is that typescript’s idea of a type system living on a separate plane was one of the greatest ideas of all time. Never felt so good about something that is basically js. With strict semantics like Rust/C++/Zig/Go it would be just a weaker clone of those with all the usual strings attached.
But I’ve got projects that are now as “correct” as possible, with full validation at deserialization and such and I just wish a compiler could take things an extra mile.
Asking as someone who has yet to try either.
Deno made a very deliberate compatibility break from the Node ecosystem. They wanted fresh start, to make smarter choices and ditch historical baggage. They thought people would be motivated to push through the adoption friction. I think that plan has been less successful than hoped, and Deno keeps walking it back. They're more compatible than before, but aren't a drop-in replacement. IMHO they prefer it that way.
Bun, on the other hand, explicitly feels that any compatibility gap with Node is a bug. Bun wants to beat Node at its own game, wants adoption to be as easy as running `bun index.js` instead of `node index.js`. Then you opt into their special APIs as-needed. Bun's headline feature is "free speedup", but they also target many of the same DX conveniences Deno does, like trivial TS integration.
When Deno came out, the question was "how is Deno better than Node?". Deno had strong answers, give or take the compatibility differences. But today you could instead ask, "why port to Deno instead of just dropping in Bun?", and that's more complicated to decide.
Knowing that even if there's a bad package, it can't call any external server or write/read files from disk.
Even generally, I now know that the code I wrote don't do any unauthorized things I didn't explicitly tell it to do.
If you think someone is reviewing all the code every time a new release is cut... popularity means it's one of the hottest targets.
Surprised I haven't run into any of these incompatibilities.
Sounds like I have some reading to do.
Bun has better speed and great documentation. And they're shipping new features very fast.
(a) With npm, Microsoft is the gatekeeper of everything NodeJS. URLs are the most decentralized way to do dependencies.
(b) Self-hosting can help with some security issues with npm. Makes it easier for private projects to not have to trust npm hosted third party libraries, which is important in many corporate environments.
I got some problems and it started leaking Node diagnostic messages all over the place. Was not impressed with how easily the facade fell over when I tried to do things just a little bit different from the happy path.
It’s also possible you ran a package.json script that had the #!/usr/bin/env node shebang at the top, which Bun by default respects. You can force it to use bun by prefixing the command with “--bun”, like “bun --bun my-executable”
What error did you run into?
I think it's a gotcha to run a script with another runtime than the one I launched from the terminal, though.
If I launch a script directly with a runtime, I expect it to disregard any shebangs.
I strongly suspect that what you saw was from running a script with a #! line that specifies node, because bun honours #! lines by default.
If you use <bun run --bun> that will tell it to use bun instead when it sees a node shebang.
When did you use it?
I do think it's a gotcha to run a script with another runtime than the one I launched from the terminal, though. If I launch a script directly with a runtime, I expect it to disregard any shebangs.
But I really want to have explore alternatives to Noe, so I will give Bun a new look soon.