We're a full-stack TypeScript shop, and I manage ~50 internal libs and ~500K LOC of TS. Last month I tested out both Deno and Bun as alternative runtimes for us. TLDR: for any semi-complex codebase we have, Bun almost always works, Deno almost never works. We now run all our tests in both Node.js and Bun, and gave up on trying to make Deno happen.
The "semi-complex" code is legacy code, aka revenue code. Started with plain JS in CJS on Node 12 and evolved to strict TS/ESM on Node 20. A lot of cruft built up from that multi-year evolution.
These days, if you're authoring from scratch, just write idiomatic TS in ESM, and you'll be fine. Even if targeting only Node, prefer to use Web standards (e.g., fetch, Request/Response, WebCrypto, Web Streams, URL, AbortController) as Node is migrating in that direction, and standard-compliant code will give you optionality in runtimes (Bun/Node/Workers).
Thanks for the reply! I'm just writing TS code that utilizes Deno/Oak and their MySQL support, to present a REST-style API. I don't know enough to say whether these depart from the standards you're recommending. If they do, I don't know how I would do routing and API support using only the things you mentioned. I'm a one-man band writing both a mobile app and the server to support it. I also know very little about scaling, which I anticipate hiring outside expertise on.
I want to invest my time wisely and learn portable techniques, but I realize the scope of my ignorance may exceed what you can address in a comment forum!
I have the luxury of toying with tech because the business around it is relatively successful. Engineering deep-dives are a lagging indicator of success (your own or your employer's) and almost never a leading one. All those "we did X/Y/Z with cutting-edge stuff" blog posts are overwhelmingly written by people who don't need to worry about bringing in money to pay for the time spent on that stuff.
Choose the tech stack that allows you to rapidly experiment in building something other people will give you money to use. That means choosing DX and iteration speed over runtime speed. That means using whatever gives you the most joy, so you're incentivized to build more often. That means something high-level so you don't waste time re-building components your customers don't care about, so you spend fewer hours on invisible, undifferentiated, but complex and time-consuming stuff.
If you're most effective with JS, Node is fine. Bun is fine. Deno is fine (for greenfield). One is super stable, battle-tested, and has 10x more contributors and 100x more libraries than the other two (most of them are trash). This maturity gap may not matter at all or may break your startup if you must re-implement something complex or continuously spend hours understanding and battling your runtime with minimal information on the web from others who encountered the same problem before. The same goes for your prod infrastructure, mobile app architecture, business ops, infosec, etc. Choose boring technology https://boringtechnology.club
Thanks for that. I'm in the middle situation, in that I'm somewhat in a hurry but not desperate (yet). So far I've been pretty encouraged by how quickly I've gotten something working with Deno; the main reason I went with it over PHP 8 is that I wanted to learn JS/TS. Second, the author's goals of addressing Node shortcomings and providing a cleaner import mechanism resonated with me. Thus far it hasn't annoyed me, which is a miracle because I'm easily annoyed. I think sifting through a vast collection of libraries (mostly junk, as you say) would annoy the shit out of me but more importantly waste valuable time.
I learned that problems that seem simple and solved apparently often aren't, regardless of how many blog posts and HN posts there are about the framework of the week. I needed to define an API, so I did so using OpenAPI. While the idea and standard seems mostly sound, the tooling (from editing to code generation) is absolute trash. I wasted soooo much time trying to make it work. Should I ever use it again, I'm writing my own tools. But right now I do just need to get stuff done.
1. Missing `node:http2`
2. Missing `node:test`, so it's more difficult to execute the same test files within Bun as we do via Node. I wrote a custom Bun loader to mock parts of `node:test`.
3. Vite and ESLint do not work.
4. Still occasionally segfaults, and it's difficult to find out why/where.
5. Surprisingly, some code runs slower in Bun than in Node. For example, generating JWE with symmetric encryption. But this might be WebCrypto vs OpenSSL.
6. Subtle differences between WebKit and V8 (e.g., how they handle dates).
I am annoyed with the bombastic claims behind bun.
I wasted a day trying to get vite to work when they first announced it. Really excited about not needing >1gb of ram to compile a react project... Boggles my mind that react bundling uses more RAM than compiling linux.
It is still unable compile http://chatcraft.org due to some problem with wasm plugin.
They also said that bunx --bun option was a pre-1.0 workaround, and didn't keep that promise.
Performance-wise their claims are suspect, safari js engine was always better at startup and memory use at the expense of a relatively weak JIT. They paired that up with a ton of stuff reimplemented in native code to make their cli and hello world workflows fast. This means people will be in for a perf surprise when they start bottlenecking in JS hotpaths.
And you're right to be skeptical. With performance, so much depends on your actual code and program-specific bottlenecks. The difference in runtime speed between JSC and V8 is minimal, so a lot of Bun optimization must be in the gaps between your code and the core JS engine or in startup time (e.g., running `bun install` or `bun test`).
In my benchmarks, our actual runtime performance of long-running JS code is ~25% faster under Bun than under Node. However, sometimes Bun is ~25% slower - notably with tasks that require binary processing (e.g, fflate, sharp) or encryption (e.g., jose). We're committed to JS and will be constrained by its performance for a long time, so a "free" 10-30% speed up at runtime is worth the effort, but it's not a 10x slam dunk like the benchmarks on Bun's homepage imply.
