Hono v4.0

fast = fast routing / throughput

lightweight = small code size

web standards = not node apis (fetch, not http.createClient, etc.)

runs on any JS runtime = runs in deno/node/bun/workers/etc

---

But yes the project is meant to be read by someone already in the field.

The people who actually know how to use it.

Yes it seems like a fancy combo of words if you don't know what they mean, but that's true for anything.

it's a much faster, leaner, express.js on the edge.

you can't run traditional http servers in edge sandbox worker environments.

frameworks like these target deno deploy, cloudflare workers, aws lambdas, etc.

they are small to fit in worker 1mb~ limits and use browser apis instead of node apis to fit the env.

bonus: sharing the same apis on the server and client also result in being able to share code client/server side.

You'd only care if you were in the "serverless" field, and then you'd likely already know about Hono since it's linked in many documentations like Supabase, Cloudflare, Deno, etc.

But you may not know about Hono because there are many options and some ways to be in serverless without seeing it yet and it's the newest framework I know of. (also my favorite so far other than raw deno)

--

This particular release was linked since it's one update that turns it into a real framework like Next or Astro.

They added 3 major features:

- Static Site Generation

- Client Components

- File-based Routing

Static site generation (SSG) would mean certain routes compile at build time and the worker won't compute them on the edge.

Client components means they now support client side rendering (CSR), before Hono was only used for server side rendering (SSR).

File-based routing is instead of coding your paths, the folder structure is used for routing, similar to Next which mimics how traditional http web serving works.

--

This is important for users of Hono as it unlocks features that exist in larger frameworks while still staying extremely minimal and flexible.

Here's two posts I wrote on how I do email tokens and async workers:

• https://taylor.town/pg-email-token

• https://taylor.town/pg-task

Here's a condensed version of how I do login/signup:

  app.post("/signup", async c => {
    const body = await c.req.parseBody();
    const usr = {
      email: body.email.toString(),
      password: sql`crypt(${body.password.toString()}, gen_salt('bf', 8))`,
    } as Record<string, unknown>;
    const [{ usr_id, email, token }] = await sql`
      with usr_ as (insert into usr ${sql(usr)} returning *)
      select usr_id, email, email_token(now(), email) as token from usr_
    `;
    await sendVerificationEmail(email, token);
    await setSignedCookie(c, "usr_id", usr_id, cookieSecret);
    return c.redirect("/u");
  });
  
  app.post("/login", async c => {
    const { email, password } = await c.req.parseBody();
    const [usr] = await sql`
      select *, password = crypt(${password.toString()}, password) AS is_password_correct
      from usr where email = ${email.toString()}
    `;
    if (!usr || !usr.is_password_correct) return c.html(<p>Your password was incorrect.</p>);
    if (!usr.email_verified_at) await sendVerificationEmail(usr.email, usr.token);
    await setSignedCookie(c, "usr_id", usr.usr_id, cookieSecret);
    return c.redirect("/u");
  });

I’ve never used Hono, I’m just interested in it. I think the AWS Lambda limits are something like 50Mb compressed and maybe 200Mb uncompressed. I might be a little off, I’m on my phone right now.

Prisma doesn’t help matters but right now I take that hit on every function package anyway.

I might just need to try it one day (move my existing app to Hono to see if it would work).

> But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs.

Yeah, thankfully SST [0] does the heavy lifting for me. I've tried most of the solutions out there and SST was where I was the happiest. Right now I do 1 functions per endpoint. I structure my code like url paths mostly, 1 stack per final folder, so that the "users" folder maps to "/users/*" and inside I have get/getAll/create/update/delete files that map to GET X/id, GET X, POST X, POST X/id, DELETE/id. It works out well, it's easy to reason about, and deploys (a sizable a backend) in about 10min on GitHub Actions (which I'm going to swap out probably for something faster).

I agree with the secrets/permissions aspect and I like that it's stupid-simple for me to attach secrets/permissions at a low level if I want.

I use NodeJS and startup isn't horrible and once it's up the requests as very quick. For my needs, an the nature of the software I'm writing, lambda makes a ton of sense (mostly never used, but when it's used it's used heavily and needs to scale up high).

[0] https://sst.dev

It was a pretty lazy one-off router, nothing too fancy. I use deno's file API to scan a `routes` directory and modified a copy of Astro's router to parse filenames and prioritize route matching patterns.

API-wise its very similar to most other file-based routers, including HonoX. Each file exports `GET`, `POST`, etc functions to handle requests.

I've used it with nuxtjs (front-end) and it's the greatest thing ever. Forces Junior devs to make front-end files that can be inuitively found by the nature of what they are (the file's filename has a logical relationship with it's URL in the browser), no longer need to maintain large garbage piles called router files. Objectively, there's literally no advantage to manually managing a router file. NuxtJS proves this for the front-end SPA.

I've been looking for a backend nodejs HTTP framework that is a) Typescript-first b) actually good that has file-system-based routing and so far haven't found anything. Adding HTTP methods on top of what nuxtjs' filesystem based routing does has me a little skeptical of what's possible, but I'll investigate Hono on this basis alone.

Also the "Edge-first" thing tells me this backend framework is probably better tree-shakable than what most other ancient/modern nodejs http servers have been doing. Cold starts will be better no matter where you deploy.