From Node.js to Bun: A Developer's Journey
TL;DR: I migrated my Node.js stack to Bun over three months. Here's what worked, what didn't, and how bunWay made the web framework transition painless.
In late 2024, I decided to go all-in on Bun.
Not for the hype. Not because it was new. Because I was tired of slow installs, slow tests, and slow cold starts.
This is the story of migrating a production Node.js stack to Bun—the wins, the gotchas, and the tools that made it possible.
Why I Made the Switch
My Node.js setup was fine. It worked. But "fine" started feeling like "friction":
- npm install: 45 seconds for a medium project
- jest test suite: 12 seconds
- Lambda cold starts: 800ms
- TypeScript compilation: separate step, separate config
None of these were dealbreakers. Together, they were death by a thousand cuts.
Then I tried Bun:
- bun install: 2 seconds
- bun test: 1.5 seconds
- Cold starts: 150ms
- TypeScript: runs directly, no build step
The difference wasn't incremental. It was transformational.
Month 1: Local Development
I started where it was safest—local development.
Package Management
Replacing npm with bun was instant:
My node_modules worked. Dependencies resolved. No drama.
Gotcha: Some packages with native bindings needed Bun-compatible versions. Most worked, but I hit issues with bcrypt (switched to @node-rs/bcrypt) and sharp (worked fine actually).
Running Scripts
TypeScript just worked. No ts-node, no tsx, no build step for development.
Testing
Bun has a built-in test runner compatible with Jest's expect API:
My Jest tests needed minor changes (import from bun:test instead of @jest/globals), but the assertions were identical.
Result: Test suite went from 12 seconds to 1.5 seconds. Not a typo.
Month 2: The Web Framework Question
My Node.js apps used Express. Bun runs Node.js code, so Express technically worked. But I wasn't getting Bun's full performance—Express still used Node's HTTP layer.
I had options:
1. Keep Express — Works, but leaves performance on the table
2. Switch to Hono — Fast, but new API to learn
3. Switch to Elysia — Bun-native, but complete rewrite
4. Switch to bunWay — Express API on Bun's runtime
I tried each. Here's what happened.
Attempt 1: Keep Express
Result: Worked. Performance was ~20% better than Node.js (Bun's JS engine is faster), but not the 3-4x I expected. Express was the bottleneck.
Attempt 2: Try Hono
Result: Fast. But rewriting 50+ routes and 20+ middleware functions felt like too much work for an incremental migration.
Attempt 3: Try Elysia
Result: Blazing fast, beautiful type inference. But same problem—complete API rewrite required.
Attempt 4: Try bunWay
Result: Same Express API I knew. Changed imports, kept my routes. Full Bun performance.
I went with bunWay.
The Migration
Here's an actual diff from one of my services:
Time to migrate: 2 hours for the main service, including testing.
Month 3: Production Deployment
Docker Changes
Image size dropped from 180MB to 120MB. Build time dropped from 90 seconds to 25 seconds.
Serverless (AWS Lambda)
This was the biggest win. I used the Bun Lambda layer:
Cold starts went from 800ms to 180ms. My API Gateway timeouts became a non-issue.
Database Drivers
Most worked unchanged:
- Prisma: Full Bun support
- Drizzle: Native Bun support
- PostgreSQL (pg): Works
- Redis (ioredis): Works
- MongoDB: Works
Gotcha: Some older drivers with native bindings needed updates. Check the Bun compatibility list for your specific packages.
The Results
After three months, here's where I landed:
What Didn't Work
1. Some Native Modules
A few packages with C++ bindings didn't work:
- bcrypt → Switched to @node-rs/bcrypt
- node-canvas → Still an issue, used alternative
- node-sass → Already deprecated, used Dart Sass
2. Jest Plugins
Some Jest plugins (like custom reporters) needed alternatives. Bun's test runner is compatible but not identical.
3. Debugging
Bun's debugger is improving but wasn't as polished as Node's. I used more console.log than I'd like to admit.
4. Edge Cases
A few npm packages assumed Node.js-specific APIs. Most had fixes or alternatives, but required investigation.
Lessons Learned
1. Migrate Incrementally
Don't rewrite everything at once. My order:
1. Local package management (bun install)
2. Test runner (bun test)
3. Development server (bun run)
4. Web framework (bunWay)
5. Production deployment
Each step was independently valuable and low-risk.
2. Choose the Right Framework
If I'd tried to rewrite my Express apps for Hono or Elysia, I'd still be migrating. bunWay let me keep my code and get Bun's benefits immediately.
For new projects, I might choose Elysia. For migrations, bunWay is the clear winner.
3. Test Thoroughly
Bun is production-ready, but it's not Node.js. Some edge cases behave differently. Run your test suite and do real QA before deploying.
4. Check Dependencies Early
Before committing to Bun, audit your package.json. Most packages work, but a few don't. Better to know upfront.
Should You Switch?
Yes, if:
- You're frustrated with Node.js tooling speed
- Cold starts matter (serverless, edge)
- You want TypeScript without a build step
- You're starting a new project
Wait, if:
- You rely on packages with known Bun incompatibilities
- Your team isn't ready to learn new tooling
- Your current setup works and performance isn't a concern
Use bunWay for the web framework if:
- You have existing Express code
- You want Bun speed without API rewrites
- Your team knows Express patterns
The Bottom Line
Bun isn't hype. It's a genuine productivity improvement.
The migration wasn't zero-effort, but it was far easier than I expected. bunWay eliminated the web framework rewrite that would've been the hardest part.
Three months later, I can't imagine going back to Node.js for new projects. The speed difference in daily development is too significant.
Resources
- Bun: https://bun.sh
- bunWay: https://bunway.jointops.dev
- Bun Discord: Active community for troubleshooting
Have questions about migrating? Feel free to reach out on Discord and I’d be glad to help.
Tags: #bun #nodejs #javascript #typescript #migration #webdev #devops #performance