Why I Chose Hono over ASP.NET Core

I never thought I’d say this. C# was my first professional love. ASP.NET Core is a fantastic framework: mature, performant, well-documented. I’ve built dozens of APIs and web applications with it, and I’d still recommend it for certain use cases.

But for data-driven websites, web applications, and APIs? I now reach for Hono first.

Too much framework for too little problem

Over the last few years, I noticed a pattern. Many APIs that I was building were this: fetch data, transform it a bit, return JSON. Maybe render some HTML from a database. CRUD with some business logic on top. Not always, but often.

For these projects, ASP.NET Core felt like too much. You’d configure dependency injection, middleware pipelines, appsettings.json, and Entity Framework before writing a single line of business logic. Deployment means a server or container, and you’re paying for compute even when nobody’s using your app.

I kept asking myself: does this project really need all of this?

Why Hono?

Hono is a small, ultrafast web framework built on Web Standards. The core is under 14kB, zero dependencies, first-class TypeScript support. But what really sets it apart: Hono runs everywhere.

Cloudflare Workers, Deno, Bun, Node.js, AWS Lambda, Vercel, Fastly, Netlify. The same code, the same API, on any JavaScript runtime. No vendor lock-in. You’re not committing to a platform. You’re committing to a framework that respects your freedom to choose.

I primarily use it with Cloudflare Workers because the developer experience there is exceptional. Zero cold starts, global deployment across 300+ cities, and a generous free tier. But if you’re running Node.js on a VPS, Hono works there too. If your company lives on AWS Lambda, same deal.

Let me show you what I mean. A real API endpoint that returns users from a database:

ASP.NET Core:

// Plus: Program.cs, DbContext, User model, DI registration,
// connection string config, migration setup... 4-5 files minimum.

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    private readonly AppDbContext _context;

    public UsersController(AppDbContext context)
    {
        _context = context;
    }

    [HttpGet]
    public async Task<ActionResult<IEnumerable<User>>> GetUsers()
    {
        return await _context.Users.ToListAsync();
    }
}

Hono + Postgres.js:

// One file. Deploy with `wrangler deploy`.

import { Hono } from 'hono'
import postgres from 'postgres'

interface User {
  id: number
  name: string
  email: string
}

const app = new Hono()

app.get('/api/users', async (c) => {
  const sql = postgres(c.env.DATABASE_URL)
  const users = await sql<User[]>`SELECT * FROM users`
  return c.json(users)
})

export default app

Both return the same JSON. One took me 30 minutes to set up and deploy globally. The other… didn’t.

What I use now

Here’s my current stack for APIs:

Hono for routing and middleware
Cloudflare Workers as my preferred runtime (swap for Node.js, Bun, or Lambda if you prefer)
Cloudflare D1 or Neon (Postgres) for the database
Postgres.js for queries
Custom migration scripts
TypeScript everywhere

If tomorrow I decide to move off Cloudflare, I swap the runtime adapter and my Hono code stays the same. Compare that to a typical ASP.NET Core project: C#, Entity Framework, SQL Server, Docker, Azure, maybe a reverse proxy. Each layer adds complexity and cost.

AI tools and the feedback loop

Here’s something I didn’t expect: AI coding tools gave this stack a second speed boost.

Claude Code and GitHub Copilot are part of my workflow now, and probably yours too.

To be fair, AI tools have gotten quite good at C#. They understand ASP.NET Core patterns and Entity Framework reasonably well. But TypeScript and JavaScript have an edge. They dominate open-source repos, tutorials, and Stack Overflow. More training data means more accurate, more up-to-date output. When I ask for a Hono route with Postgres.js, it’s usually ready to use. With C#, I find myself correcting small things more often. A deprecated API here, a slightly off pattern there. Not a massive gap, but it adds up.

The real game-changer, though, is the feedback loop.

Write code. Save. See the result instantly because the dev server reloads in milliseconds. Something breaks? Paste the error into your AI tool, get a fix, apply it, keep moving. The whole loop takes seconds.

With ASP.NET Core, every step in that cycle is a bit slower. Build takes longer. Server restart takes longer. Error messages are more verbose. Individually, none of these are deal-breakers. But multiply it by a hundred iterations in a day, and you feel the difference in your bones.

The tightest feedback loop wins. Not because any single iteration is dramatically faster, but because you get ten iterations done in the time it used to take for three.

I’ve shipped features in an afternoon with Hono that would have taken me a full day in .NET. Not because .NET is slow, but because the entire experience is optimized for tight, fast iterations. In 2026, with AI tools becoming a core part of how we write code, that matters more than most people realize.

When I’d still choose ASP.NET Core

I want to be honest. Hono isn’t the right choice for everything.

Complex domain logic with rich business rules? C# and .NET give you a stronger type system and better tooling for large codebases.
Enterprise environment where the team, infra, and CI/CD are all .NET? Switching stacks creates more problems than it solves.
CPU-intensive work like number crunching or large file processing? .NET’s performance there is still hard to beat.

The best tool is the one that solves your problem with the least unnecessary complexity.

The TypeScript switch

The TypeScript switch deserves a mention. C# is a more mature language, no question. But TypeScript has gotten remarkably good. Postgres.js gives you tagged template queries that are safe from SQL injection by default, and with TypeScript generics you get typed results back. And there’s a practical benefit that’s easy to underestimate: one language for everything. Frontend, backend, database schemas, deployment config. No context switching. No separate build systems.

I also noticed something I didn’t expect: I enjoy building side projects again. With ASP.NET Core, the overhead of starting a new project sometimes killed my motivation before I even wrote the first feature. With Hono, I just start building. That’s worth more than any benchmark.

Bonus: Use both

Here’s the thing. You don’t have to pick one. Use Hono for APIs and web-facing stuff, and keep ASP.NET Core around for the heavy lifting.

The setup is simple. Run your .NET service on a cheap Hetzner VPS (you can get a solid one for a few euros a month) and expose it through a Cloudflare Tunnel. No public IP needed, no firewall headaches, no reverse proxy to configure. The tunnel handles all of that for you.

Your Hono API runs on Cloudflare Workers at the edge, handling requests globally with near-zero latency. When it needs something compute-heavy, like PDF generation, image processing, or running complex business logic, it calls your .NET service through the tunnel. The .NET side does what it does best: raw performance on CPU-bound work.

You get the best of both worlds. Fast, globally distributed APIs with Hono. Cheap, powerful compute with .NET on a VPS. And Cloudflare Tunnel stitches them together without the usual infrastructure pain.

Give it a shot

If you’re a .NET developer who’s never tried building something outside the Microsoft ecosystem, try Hono. Not because .NET is bad, but because a different approach changes how you think about problems.

Start small. An API for a personal tool. Spin it up on Cloudflare Workers, Node.js, or Bun. Whatever works for you.

You might come back to .NET for your next enterprise project. That’s fine. But for data-driven websites and APIs where simplicity and speed matter most, you might find, like I did, that less framework means more productivity.

Don’t be afraid to challenge your defaults. The tool you’ve used for 15 years doesn’t have to be the tool you use for the next 15.