Bosen, ek minute, ami ticket ta likhe dei. I have been at this counter since the year of the Awami League sweep in 2000, 26 years now selling tickets through the same brass grille at counter 9, and every so often the company painted on the side of the bus changes. Hanif becomes Shyamoli, Shyamoli becomes Green Line on the longer routes, and lately a new operator with a logo the colour of flame has been outbidding the old families on the Chattogram contract. The passenger I am writing about, a young software bhai who came through last Saturday for the five o'clock to Chattogram, asked me the question they all ask. Is the new company with the air conditioning reliable? Will the bus leave on time? Does the seat recline the way the old one did? The road to Chattogram has not been resurfaced in twelve years, the stops at Cumilla and Feni are where they have been since I started this job, and the question of which company painted the bus is mostly a question about which logo is on the ticket.

A team switching JavaScript runtimes, from Node to Bun, to Deno, or to whatever Cloudflare and Vercel have been cooking on the side, is doing roughly what the passenger was doing when he asked me about the new operator. He was changing which logo went on his ticket. The road did not move, and the reason the journey was going to feel different was almost never the bus itself. It was the things he had packed into his hand luggage and forgotten about, the thermos that was already half broken, the cousin's medicine that needed refrigeration, the suitcase whose wheel had been jammed since the trip to Sylhet in 2023.

The runtime your team argues about at standup is the bus. It is a paint job over a standardised set of seats and a standardised engine, all built in the same factory under the same loose specification. The factory is V8 (or in Bun's case, JavaScriptCore) and a shared understanding of what a JavaScript runtime is supposed to provide on top of it. The Bun documentation keeps a running compatibility chart, and the headline says roughly 90% of Node's stdlib runs unchanged. The remaining 10% is the bit your team will lose three weeks to, because the 10% lives inside whichever transitive dependency has been quietly carrying your luggage since 2021.

The dependencies that break are consistent enough that I can list them the way I list the buses that always run late on Eid weekend. Native modules built against a specific Node ABI top the list, because the binary compiled against Node 20's headers is staring at JavaScriptCore and not recognising any of the furniture. Anything with node-gyp in its install log wants a recompile, and roughly half the time the maintainer has already shipped a binary that works with Bun. The other half you are reading a GitHub issue six months old at midnight, and the package is usually one your team adopted three years ago for one feature and forgot about.

The cultural part of the resistance is more interesting than the technical part, because the cultural part is what produces an estimate of three weeks for a migration that actually takes one day. James Snell, who has done the slow labour of keeping Node's performance trajectory honest for the better part of a decade, has written periodically about how much of Node's perceived stability rests on the fact that nobody has the appetite to challenge a working setup. The bus that has been running since 2019 has a driver who knows where the rough patches are, and the institutional memory of which seat squeaks costs a sprint to rebuild.

The Deno team, whose philosophy posts on what a JavaScript runtime should owe its caller have aged surprisingly well, made the case as early as 2018 that most of what people called "Node" was a set of accidental choices. Those choices, about module resolution and packaging, did not have to be the way they were. Bun is the third or fourth attempt at revisiting those choices with hindsight, and shipping a bundler, test runner, and package manager in one binary is less a feature than an admission that the npm ecosystem grew sideways for fifteen years. It compresses the distance from installing a new TypeScript project to actually running it, from eight minutes down to under thirty seconds, which is enough to let a team prototype something real on a Friday afternoon instead of pushing the spike into next week.

The reason migrations feel scary, when they feel scary at all, is that they force the team to confront the parts of their setup that were already half broken, the ones Node's implementation tolerances had been quietly carrying. The luggage check at the bay always reveals which items in the bag have been held together with twine. The thermos was already broken long before the runtime changed, and the new bus only sat on the highway long enough for the leak to finally become visible. Treat a migration as an audit of the dependency graph rather than an architectural leap, and the timeline collapses from three weeks to about three days.

The young bhai came back through my counter the following Wednesday and told me the migration had cost his team a Saturday afternoon and one fix to a bug on the Monday morning. Two dependencies wanted updates, one carried a deprecation warning, and the thing he kept returning to was how boring it had been.

He had booked the whole weekend for it.

Sirajul bhai drove the coach the whole way down through Daudkandi and Feni, exactly as he would have if Hanif still held the contract, and not one passenger on that bus knew or had any reason to care whose contract it was. The paint on the side was different and the orange on the ticket stub was a slightly wrong shade.

That is the whole of what a runtime change is supposed to look like from the seat, and I still cannot decide whether that is reassuring or exactly the problem, since the people who signed the new contract are betting real money on nobody at counter 9 ever noticing.