Hono's middlewares, especially zod-openapi[1] and @scalar/hono-api-reference[2], make it really easy to define your REST endpoints once and get full typesafe routes with request/response validation, an automatic OpenAPI spec, a beautiful OpenAPI browser and you can even reuse the typings in your frontend with Hono's RPC[3] middleware, essentially giving you end-to-end type-safety without any code-generation.

Its maintainer yusukebe is a really nice guy who is always being helpful and very active. I want Hono to become the modern successor of Express. :)

[1] https://hono.dev/snippets/zod-openapi

[2] https://www.npmjs.com/package/@scalar/hono-api-reference

[3] https://hono.dev/guides/rpc

    import { z } from '@hono/zod-openapi'
    import { createRoute } from '@hono/zod-openapi'
    import { OpenAPIHono } from '@hono/zod-openapi'

> beautiful OpenAPI browser

> end-to-end type-safety without any code-generation

That's a great sales pitch - I'd looked at Hono before but now I've opened all the links you mentioned and will try it out.

But I want to use a server other than the default provided by Remix, i.e minimal Express. So, I found Hono. It looks interesting because it can run on many runtimes, and this time I want to try using Bun.

After researching Hono, it turns out it can render JSX directly from the server, which piqued my interest. Then I tried to make the JSX interactive, and finally, I used htmx. Lol.

And just yesterday, after spending hours I found a way to use PDFKit with Hono (Bun runtime), so I created a gist for reference:

https://gist.github.com/mansarip/eb11b66e7dc65cee988155275a1...

Anyway I'm still cautious about putting this Hono + htmx stack into production use.

The README.md says RegExpRouter uses no loops and just regular expressions, presumably it maps a route to a hashmap matched entry?

Related but slightly different:

I am curious because NFAs, deterministic automata are interesting to me. I remember one person on HN talked to me about using regular expressions to match event sequences. (That is: don't match against strings but match against tokens)

I am not a Rust developer, but the pattern of using Rust sum types and pattern matching or OCaml dispatch based on types are similar to me intuitively.

What are your thoughts on this style of programming?

I feel so much of modern business programming is dispatch logic!

If you think of Redux and state machines and event sequences in GUIs for behaviour, I feel there is a lot of untapped potential ideaspace here.

They also have a similar trie router, but my understanding is that it's not as fast.

1. In a serverless environment, _the whole point_ is that the requests are essentially all concurrent. If you get 1000 requests at T+0, you get 1000 concurrent invocations of your function. The overhead of the worker doesn't stack unless you hit a concurrency limit, which most folks won't.

2. The overhead of the framework is a rounding error. The slowest framework benchmarked clocks in at over 200K QPS. That's ones of microseconds of overhead from the framework per request. HonoJS is still ones of microseconds per request. If your application code takes one millisecond to return meaningful output, that's _hundreds of times slower_ than the overhead, and the framework's performance is already moot.

Choose a framework that is nice to use and gives you all of the features you want. Shaving off a handful of kilobytes of source code _on the server_ is premature optimization. Shaving off a few microseconds from the request time is premature optimization. Even "heavy" frameworks like Koa and Express will give you good-enough performance that you probably wouldn't ever even notice. What matters is the tool you choose that helps you build useful stuff faster.

> It works on any JavaScript runtime: Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, AWS Lambda, Lambda@Edge, and Node.js.

Not sure it counts as “any JS runtime” if it does not work in browser (e.g., worker context), but judging by the rest of the docs it might work there, too.

Does it work in the browser as well?

It would free things up so much - the backend team can focus on JSON/HTML templates, the designers can work directly with the website without necessarily going through dev (for better or worse ;), marketing can add all their little trackers, easy to outsource parts, and you could build up an entire cross-language ecosystem of plugins that manage anything from user accounts, billing, wikis, blogs, knowledge base, admin CRUD systems, ... yet it's all on the same site from the end user's perspective.

I think there are multiple enterprises that have (also re-)invented this architecture, but I haven't seen any serious open source offering that focuses on this type of use.

If the actual backend renders HTML and JSON and we have a CDN for static assets I'm not sure what's missing.

Sure bringing stuff onto the edge is great but if the edge needs to always forward requests upstream there is limited gain here.

For me it kind of feels you need some runtime and DSL to enable all requirements in web. And Google Tag Manager isn't it.

I'm not saying we should go back to XML and XSLT but some separation of concerns would help: data, display, events, animation.

To me a backend framework is more like Rails or ASP.NET. Hono is more like an http router.

Both frameworks support route groups, middleware, context, and mounting apps from other frameworks.

Both are WinterCG compliant - deployment to platforms other than your own server or Docker, such as Cloudflare or Vercel Edge, should not be an issue.

Hono appears to be very focused on serverless and edge runtimes like Fastly Compute, Lambda@Edge, Supabase Functions, etc.

Both offer their own RPC implementations:

- Hono: RPC in Hono: https://hono.dev/concepts/stacks#rpc

- Elysia has Eden—its own end-to-end type safety RPC: https://elysiajs.com/eden/overview.html

So, it's a matter of preference, I would say.

I'm personally using ElysiaJS in production and have zero complaints.

The docs[0] are not instructive on this point.

[0] https://hono.dev

So if you’re streaming tokens from an LLM and you cancel the request from the client you’ll be wasting money.

AICI takes a more abstract approach here - first everything not related to prompt or token compilation is out of scope. So your api is not wasm-ed. Second, the job of creating the wasm prompts is your responsibility - use what you will. While we fundamentally try to answer the question "how can prompts and chains be expressed in a WASM friendly way without locking urself to the language and having it as a config"

What does this mean?

I don’t know what that might cover, but it might be things as basic as parsers for headers and cookies. Which I applaud, because me personally, that’s shit I’ve never wanted to think about.

Python with its seven circles of infinite package hell also demonstrates the limits of this approach. It’s not very useful that the language gives you two AA batteries when your application needs a megawatt of power (metaphorically).