Open main menu

The Hero JS Needs

•

Table of Contents

status
dsq_thread_id
I’m a fan of Bun, the TypeScript runtime. I’d like to share some thoughts on why it’s great.

Bun.sh

What: JavaScript and TypeScript runtime.
Why it’s great:
  • Bun doesn’t want your attention, it wants to get out of your way. This is different than almost every other JavaScript-related technology, which wants to to learn it’s specific way of doing things.
  • It roughly Just Works™, which is a tremendous productivity boost in JavaScript land.
The less you focus on your JS toolchain the more actual work you get done. Bun shines by taking care of the stuff you shouldn’t have to worry about.

The hero JS needs

When JS gained traction on the server with Node.js a new way to modularize code was popularized—using a special require function with the path to another JS file. The frontend side very reasonably also wanted to modularize code, and this method of code importing gained wide adoption.
Then at one point the JS ecosystem saw all the fun Python was having with v2 vs v3 and decided we, too, wanted some of that action. Another way of importing code emerged on the scene and countless dev hours were squandered as a result.
Why the backstory? Because at long last we have a technology that adopts the only reasonable stance on this messyness—to abstract it away from the developer. You, dear developer, should not have to care about various types of code importing schemes. Use require , use import, Bun will figure out how to make it work.
This is so much more productive than previous alternatives it almost feels unreasonable. Otherwise… why have we been worrying about toolchain configuration all this time? Indeed.

First-class TypeScript

I’ve long felt (and clearly others have too) that TypeScript should just be a language in its own right. it’s very useful, but the tooling required to use typescript can be a pain to set up. Bun solves this.
My pet theory on why Next/Sveltekit/Nuxt have gained popularity is that they handle configuration of finicky JS toolchains for you. All the rest is secondary.

A full toolchain

When you build a web app project you’re going to want a few things:
  • Package manager
  • Testing lib
  • Bundler
  • Runtime
Bun provides all of this.

Bun has made TS fun again

TypeScript (or JavaScript) is a great scripting language with bun. You write your code, you run your code. Simple!

Why not Deno?

In short, a different mindset. Bun wants to achieve Node.js compatibility, so that you can use it as a drop-in replacement. Deno on the other hand wants you to use new APIs. Bun also has proprietary APIs and wants you to use them, so whats the difference? It’s a difference in their mindset. If an existing node module doesn’t work in Bun they consider it Bun’s responsibility to fix it. Deno on the other hand seems a bit torn. They also want you to be able to use Node.js modules but only as a stepping stone to web-standard APIs.
I don’t have anything against web standards, but if I have some perfectly good node.js code chances are good that I don’t want to rewrite it. This is what Deno seems to miss. They want you to continue to put in effort, rather than simply get out of your way. At least that’s the impression I got after a couple years of being an observer.
At the risk of repeating myself, if Deno wants wide adoption they need to not only accept but embrace the users that are looking for a simpler toolchain but don’t want to change any code whatsoever. Users that just want to use TS in Node.js without a build step. They need to give up on the vision of everyone using web-standard APIs, because learning those APIs takes effort, effort that developers would rather not spend.

Risks

So, what’s not to love?

Is it a business?

Bun is VC funded, and will need to make money eventually. I’m skeptical yet another hosting service will be enough. To reiterate, here are some things that make Bun great as a user:
  • Free and open source
  • Relatively low switching costs
If Bun runs low on cash, will these virtues remain? I certainly hope that Bun can become a big business on the back of hosting TypeScript apps, but it seems a bit unlikely.
The happy-path here is probably Bun getting acquired by, say, Microsoft and getting folded in to a larger developer ecosystem org such that they don’t need to directly turn a profit.

In summary

Bun is a breath of fresh air because it doesn’t want me to learn anything new. The JS ecosystem somehow seems to want us to focus on the tech itself, not what we can do with it. There’s a tendency in JS land to spend an unthinkable amount of time in the bike shed tweaking syntax or configuration.
Bun does none of this, and for that I applaud them. It gets out of my way so I can simply write software, while still benefiting from the good parts of the broader ecosystem as well as incremental typing.