Bun and ambition in software: why we should aim higher

Have you ever watched npm install run and thought "that's just how it is"? That resignation is the subject of a post by Dan Luu, We should be more ambitious with the software we build. To me, Bun is the best recent example of what happens when someone refuses to accept "that's just how it is". In this article I bring the two together: Dan Luu's challenge and what Bun teaches, in practice, about technical ambition.

What Dan Luu is saying

Dan Luu has been writing for years about a frustration every dev knows. Computers got absurdly faster, but software didn't keep up. In older posts he measured keyboard latency on machines from 1977 and 2017, and the numbers didn't favor the new ones. He also wrote about web bloat: pages that weigh megabytes to show three paragraphs.

The core idea now is simple. We got used to aiming low. We accept slow tools, heavy apps and five-minute builds because "everyone uses them". And when someone suggests rebuilding something from scratch, the default answer is "don't reinvent the wheel".

But sometimes the wheel is square.

Why Bun is the perfect example of ambition

Remember the JavaScript ecosystem in 2021? You needed Node to run things, npm or Yarn or pnpm to install, Webpack or esbuild to bundle, Jest or Vitest to test, ts-node or tsx to run TypeScript, and dotenv to read .env. Every piece had its own config, its own bugs and its own version fights.

Jarred Sumner looked at that and decided to do it all at once. Runtime, package manager, bundler and test runner in a single binary, written in Zig and running on JavaScriptCore. At the time, plenty of people thought it was crazy. One person (later a small team) trying to replace the work of thousands of maintainers?

You know how it turned out. bun install finishes before you can switch tabs. TypeScript runs directly, with no compile step. And the project got serious enough that Anthropic bought the company at the end of 2025, because Claude Code runs on top of it.

Sometimes the wheel is square, and reinventing it is the only honest option.

The point isn't that Bun is perfect. It isn't. The point is that it only exists because someone found unacceptable what everyone else found normal.

What changes in your code when the tool is ambitious

Tool ambition turns into simplicity in your project. Look at an endpoint that reads from PostgreSQL using only what ships with Bun:

import { serve, sql } from "bun";

serve({
  port: 3000,
  routes: {
    "/api/users/:id": async (req) => {
      const [user] = await sql`select id, name from users where id = ${req.params.id}`;
      return user ? Response.json(user) : new Response("Not found", { status: 404 });
    },
  },
});

Notice what's missing. No Express. No pg. No dotenv, because Bun reads .env on its own and sql picks up DATABASE_URL from it. The package.json for this service can have zero runtime dependencies.

And testing comes built in:

import { test, expect } from "bun:test";

test("sum", () => {
  expect(1 + 1).toBe(2);
});

bun test and you're done. No preset, no transformer, no jest.config.js that nobody remembers why it exists.

In practice, here's what I feel day to day:

• Fewer dependencies means fewer security alerts from Dependabot.
• Less config means faster onboarding for whoever joins the project.
• Faster feedback means I actually run the tests, instead of leaving them to CI.

That last one is the most underrated. A slow tool doesn't just waste your time. It changes your behavior. If tests take 40 seconds, you run them less. If they take 2, you run them all the time.

"But isn't rewriting from scratch always a mistake?"

That's the classic objection, and it has merit. There's a famous post by Joel Spolsky saying that rewriting software from scratch is the worst strategic mistake a company can make. He was talking about Netscape, and he was right in that case.

But the advice became dogma. And dogma is laziness dressed up as wisdom.

The difference is in what you're rewriting and why. Netscape rewrote a product that worked, and lost years and the market. Bun didn't rewrite Node on a whim. It went after a measured problem: install time, startup time, number of tools in the chain. Every decision had a number behind it.

Ambition isn't "I'll redo everything because the code is ugly". It's looking at a metric everyone accepts and asking if it has to be that way. Sometimes the answer is yes. Sometimes it's "this could be ten times better".

And an honest warning: Bun still has rough edges. Some Node APIs behave differently, the odd native library is a pain, and for critical production I still test thoroughly before switching. Ambition costs something in maturity, and early adopters pay part of that bill.

How to bring this ambition into your project

You don't need to write a runtime in Zig. The ambition Dan Luu argues for fits into small everyday decisions. Here are some I apply:

1. Measure before you accept. How long does your build take? Your cold start? The first page load on 4G? If you don't know the number, you don't know if it's bad.
2. Question every dependency. Before running bun add, ask if the platform already handles it. fetch, crypto.randomUUID(), Intl, structuredClone: many popular libs are now just nostalgia.
3. Treat slowness as a bug. If a screen takes 3 seconds, open an issue. It's not a "future improvement", it's a defect.
4. Pick tools that shorten the chain. Replacing four tools with one has value even if none of them is bad on its own.

A quick test I like: run time bun install and time npm install on a clean project of yours. Not for the score, but to feel the difference between "acceptable" and "nobody had tried to make it better".

My take: the problem is rarely technical

What struck me most in Dan Luu's post is that the barrier is almost never the hardware or the language. It's expectations. We look at a chat app eating 1 GB of RAM and think it's normal, because the previous one did too.

Bun is a reminder that one stubborn person with a well-measured problem can shake up an entire ecosystem. That doesn't mean you should go migrate everything tomorrow. It means it's worth being suspicious every time you catch yourself saying "that's just how it is".

I'd rather err on the side of too much ambition than spend my career optimizing how fast I accept bad tools. If you want to see where I've been applying this, including Bun in production, take a look at my projects.

Ever watched `npm install` run and thought "that's just how it is"?

Dan Luu has a post that stuck with me: we got used to aiming low. We accept slow builds, heavy apps and ten tools to do the basics.

Bun shows the opposite. One stubborn person packed a runtime, bundler, test runner and package manager into a single binary. A lot of people called it crazy.

Today I ship an endpoint with PostgreSQL without Express, without pg and without dotenv. A test that runs in 2 seconds is a test I run all the time.

"Don't reinvent the wheel" became dogma. Sometimes the wheel is square.

I wrote about technical ambition, Bun's rough edges and how to bring this into your daily work. Link in the comments.

#Bun #JavaScript #TypeScript #SoftwareDevelopment #DeveloperExperience