Stop Using React + Express for Small Projects

I measured 1MB of RAM at idle. No build step. No node_modules bloat. A single process serving everything. Here’s how Bun + Hono changed the way I build my small projects, and why it might change yours too.

The Problem Nobody Talks About

Every time I spun up a new side project, the ritual was the same: npx create-react-app, scaffold an Express server, wire up CORS, configure Webpack or Vite, wait for 200MB+ of node_modules to install. For a to-do list app. For a dashboard. For a simple API proxy.

My self-hosted server was drowning. Each “small” project alone consumed 150–300MB of RAM while idle. Multiply that by five or six projects, and suddenly a 2GB VPS was nearing its breaking point – not from traffic, but from framework overhead.

The industry normalized it. We reach for React because it’s what we know. We reach for Express because it’s been the default for a decade. But defaults aren’t dictates – they’re habits. And habits have a cost.

Meet Bun + Hono

Bun is a JavaScript runtime written in Zig, using Apple’s JavaScriptCore engine instead of V8. It’s not just “faster Node” — it’s a fundamentally different approach. Bundler, transpiler, package manager, and test runner are all included. Single binary, no toolchain sprawl.

Hono is an ultra-lightweight web framework with zero dependencies (~14KB). It runs anywhere Bun, Node, Deno, Cloudflare Workers – everywhere. It’s TypeScript-first, with built-in middleware for CORS, caching, and logging. Think Express, but stripped of a decade’s worth of cruft.

Together, they allow you to serve an API and an SSR frontend from a single process, a single package.json, and a single Docker container.

The Numbers Don’t Lie

I built the same project twice – a Steam game review analysis tool – once with Node + Express + React, and once with Bun + Hono (using Hono’s built-in JSX for SSR). Here’s what I measured:

This isn’t a marginal improvement. This is a 99% reduction in idle memory usage and a 50x faster cold start. On a self-hosted server running multiple projects, this difference is the gap between “runs smoothly” and “out of memory.”

Why Is The Difference So Dramatic?

Bun: A Leaner Engine

Node.js loads hundreds of internal modules on startup. Bun only loads what you actually import – it uses lazy loading. JavaScriptCore (Safari’s engine) also has a smaller memory footprint than V8. Add in the fact that Bun doesn’t need separate tools for bundling, transpiling, or package management, and you eliminate entire categories of overhead.

Hono: Zero Dependency Philosophy

Express pulls in 30+ packages. Hono pulls in zero. Its router uses compiled RegExp patterns for instant route matching. Middleware is tree-shakeable – it won’t be loaded if you don’t use it. The entire framework fits within 14KB. That’s smaller than most favicons.

Monolith Trumps Micro Frontends

With Hono’s JSX support, you no longer need a separate React dev server. Your API and UI are served from the same process. No CORS configuration. No proxy setup. No duplicate node_modules. Single codebase, single deployment, single container.

What It Actually Looks Like

Here’s a complete Hono server with SSR — no React, no Webpack, no build step:

src/index.ts

Run it:

That’s it. Includes hot reloading. No nodemon, no ts-node, no tsconfig gymnastics. Bun understands TypeScript natively.

When Should You Still Use React?

To be clear,

this isn’t an anti-React post. React is excellent for complex SPAs with heavy client-side interactivity – dashboards with real-time updates, collaborative editors, design tools. If your UI has 50+ interactive components and complex state, React earns its weight.

But honestly ask yourself: does your project really need a virtual DOM, a component tree, client-side routing, and a bundler pipeline? For a blog, a landing page, a CRUD tool, an API with a simple UI, or a monitoring dashboard – the answer is almost certainly no.

The sweet spot for Bun + Hono:

• API proxies and microservices

• Internal tools and admin panels

• Landing pages and marketing sites

• Webhook handlers

• Server-rendered dashboards with Chart.js or HTMX

• Any project where server cost and simplicity are paramount

So What About Interactivity?

The missing piece is HTMX. It lets you make AJAX requests, trigger CSS transitions, and swap DOM elements – all from HTML attributes. No JavaScript. Load it from a CDN, add hx-get and hx-target to your HTML, and you have a dynamic UI without a framework.

Combined with Chart.js (also from a CDN) for data visualization, you get a fully interactive application with a zero-build-toolchain and zero client-side framework code.

The stack is simply:

Bun (runtime) + Hono (framework + SSR) + HTMX (interactivity, CDN) + Chart.js (charts, CDN) + Tailwind (styling, CDN). Single process, single package.json, single dependency.

Total idle RAM: ~1MB.

The Verdict

If your project doesn’t need React’s complexity, don’t pay React’s cost. Bun + Hono serves a modern, type-safe, full-stack web app in a single process that uses less RAM than a single Chrome tab. Your server—and your future self—will thank you.

Frequently Asked Questions

Is Hono production-ready?

Yes. Hono is used in production by Cloudflare, Vercel, and others. It has a stable API, strong TypeScript support, and an active community.

Can I migrate from Express to Hono?

Hono’s API is similar to Express. Most routes and middleware translate directly. There’s also an Express compatibility adapter for gradual migration.

Is Bun stable enough for production?

Bun has reached 1.x and is production-ready for most workloads. It passes the vast majority of the Node.js test suite and is actively maintained.

Can Bun + Hono replace Next.js?

For simple SSR applications, yes. For projects that require file-based routing, ISR, image optimization, and the full Next.js ecosystem – Next.js is still the better choice.