You Should Drop Express and Try Hono

Welcome to Syntax. In this episode, this Monday hasty treat, we have CJ Reynolds on, and he's going to share with us why you should be checking out and using Node.

Hono being the modern new JavaScript, I don't know, JS that back end framework or is it a server? I don't know. We're gonna learn from CJ what the heck this thing is and why you should use it. My name is Scott Tolinski. I'm a developer from Denver. And with me JS always is Wes, but also CJ. What's up, CJ?

Not much. Super excited to talk about Hono. I've released a video on building an API with it, and, more videos coming soon on Hono. So, yeah, Hono is great. I've been loving it. Sick. Cool. Well, we're super stoked.

If you are using Node, you probably have an application you wanna make sure. Maybe it's your 1st time using Hono, and you you wanna catch all those, bugs you might introduce because maybe you didn't watch CJ's video and you thought you could do it yourself and you've introduced some bugs into your code base. Well, you wanna check out century@century.i0forward/syntax.

Sign up and get 2 months for free. You gotta use that coupon code at tasty treat, but you use that coupon code, you get 2 months for free. Solve your bugs with Sentry.

Alright, CJ.

Let's kick it off. Let's let's what is Hono? Why should we care? What do you love about it? Let's hear it. So, yeah, Hono is a web application framework. They call themselves fast, lightweight, built on web standards, and supports any JavaScript runtime. Wes, essentially, if you're in the JavaScript ecosystem and you have or had been building apps with Express, Hono is kind of like the modern alternative to Express. And so, essentially, it allows you to build back end APIs.

They do also have a meta framework called Hono Node. So, technically, you could do more like server rendered things if you want to. And, like, it has first class support for JSX. So if you need, like, a one off route that returns HTML, it can do that too. But, yeah, Hono is basically a way of of building back end apps, with JavaScript and TypeScript.

I have a question. Node x.

Weston, you might know the answer to this as well. That was it's not a CloudFlare project. Right? But it is now

being So CloudFlare hired the the the guy who builds Node. Cloudflare hired him. So they now pay him to to work on HONO full time, I'm assuming.

And they also released, like, HONO x, yeah, which is their I think that they did this because it's their it has, like, almost all the React APIs. It's really cool, tight integration with the back end. I think that Kleifer JS putting this out as their, like, their Next. Js. You know? Because the reason so many people use Vercel is because Next. Js is awesome.

So they're trying to make a full stack framework, not just back end, which is what I typically thought of Node as.

Yeah. And as far as I know, I think, like, right now, it kind of has the idea of, they don't I don't think they support React Vercel components just yet.

And so it's I mean, this is a weird reference, but it's in from what I've seen, it's similar to Deno Fresh, which I I had some experience with, in that, like, everything's server rendered, but then some things can be islands. So they kind of take that approach for it. But, but like Wes said, it's kind of like their entry point into the meta framework sphere. And probably, eventually, once it once it gets out of experimental, you'll see them probably pushing it more for for people to build apps with it.

Hey, San Francisco. We're gonna be in town for GitHub Universe on October 20 8th, and we're doing a syntax meetup. You don't have to be going to the GitHub Universe conference to meet up with us. But if you are in San Francisco, come hang out from 5 to 7 PM, October 28th. We're gonna be at the Bare Bottle Beer Garden in Salesforce Park. Admission is free. We're not gonna charge you, but come hang out, and you need to grab a ticket via Eventbrite. So we put the link in our socials, in the newsletter. We'll put it in the show notes as well. Come check it out. Come hang out. Scott's gonna be there. I'm gonna be there. The whole team's gonna be there. It's gonna be exciting. See you then.

And so, I Wes, yeah, I just wanna talk about why I like Hono and why I think you should try it. And so one of the first things I really like about Hono is how familiar it is. So if you've ever built an Express app, which most JavaScript developers have, it looks exactly like that. So you can see even on their Node page, you create an instance, and then you do app dot git route. Right? So this is, like, these days, a very familiar way of defining back end endpoints. You have your app. You say, what is the method? The path? And then how is it going to respond? And Node works in that exact same way.

Yeah. If you are like, Express is obviously the big one out there. It's Express is absolutely massive still, and I've I wanna, like, move off of Express. And I was like, like, what should I what should I move to? And I think this is the the very clear decision for this type of thing because it's it's it's very express feely, but it's all built on web standards.

So you don't have to do any any, like, weird express specific stuff or, like what was the the express is built on a, like, a common middleware called what's the name of that? Connect. Is it Connect? Connect. Yeah. So, like, the way Connect was a standard way to integrate plug ins and and middlewares and whatnot between all of these different frameworks, Express being the big one.

Now web standards is that, in my opinion. Right? So it's really nice because you can pull in a different plugins or whatever that just use request and response web request, web response, and that's what Node is built on. Absolutely. And I think that's one of the great things about, like, learning web standards as well is because once you know how request and response work, you can be very effective inside of Hono. And that's like, the second major reason I'm I I, suggest Hono JS something you should try is because of all the supported platforms. So if you look in their docs, they support Cloudflare, Deno, BUN, Fastly, Vercel, Netlify, AWS Lambda, Azure.

Literally anywhere you want to run your code, they have an adapter for it. So, like, if we look in the the Node. Js example, you would build out your Hono app, but they expose this thing called a Hono Node server, and then you just pass your app to it into it and it serves it. But any other platform, they're going to expose a very similar adapter and you can just pass it in. One of the interesting ones is service workers. So you could build an app that, like, looks like a back end app, but essentially just runs inside of the web browser to, like, intercept responses for, like, caching and stuff like that. So you can you can it's a way of potentially building a service worker, with a very syntax because you can just kind of, like, build out your endpoints like this. Yeah. Really?

So if I I could build a Node app that lives in a service worker and intercepts all Pnpm.

And if that's the case, I could I could do something with that. You Node? Throw a a new version of it or, cache it. Wow. I didn't I didn't even think of that because that that's a kind of a pain with service workers is that we should explain. The way a service worker works is that you have, like, an HTML file, and that HTML file will Wes, like, dog dot JPEG or style dot CSS.

And that will go to the server and and bring back the thing. But a service worker will allow you to jump in between that request and possibly capture some of the the data, and then it'll say, oh, I've I've actually cached that, or or I want to modify that in somehow locally. You know? You you can go offline with it. There's all kinds of really nice features for it. That's neat.

Yeah. I I would say the the most experience I've had with service workers is seeing it used as the caching layer for, like, create React app. It used to be when you generated a create React app, it had that, like, little service worker file. And the code in there was it would basically cache all of your JavaScript files so that the page would load faster after that. But it's it's an interesting way to think about it because at that point, you're kind of like you're writing code that looks like back end code, but it's technically running inside the browser. So, yeah, it's pretty cool. And and Cloudflare Workers, the API for Cloudflare Workers is, like,

almost the same as service worker. Right? So that's probably it wasn't much of a a stretch to go from their Cloudflare Worker implementation to service worker.

Yeah. I'm I'm not super familiar, but, I mean so I've I've been I've done a few test deployments to Cloudflare.

I, like, I guess they hide it all from you because I didn't even see anything, like, service worker related. It's like you literally just run your mobile app and and but, yeah, I I could see I could see that. If you're not using, like, a Node on Cloudflare,

you you basically just get a, like, you listen for, like, a fetch event or something like that, and then it just dumps a payload of what it is. And then it's up to you to figure out routing and and all of that stuff, which is it's kinda bumbly. This is why you should use Node if you're using Cloudflare.

Yeah. And then beyond that, they've kind of thought everything. So if you look in their docs and then look under helpers, they have helpers for all the stuffs you would wanna do inside of an API. So they have, like one of them is, like, just JWT helpers. So if you're rolling some off and you need to encode JSON Wes Tokens, you don't need to install a separate library. You can just use HONO Node JWT.

They also have a built in helper for, like, setting up a WebSocket endpoint and then all kinds of, like, built in middlewares as well. So, like, if you need basic auth, there's a middleware for that.

If you need to add some caching headers, there's a middleware for that. If you need cores, there's a middleware for that. So all of this stuff is kind of just built in and very well supported by the library itself. So, like, in my ESLint of Hono, every single one of these that I came across haven't had any issues with. And even just, like, looking at the GitHub issues and discussions, they respond to them very quickly. So I think one of the caveats of having to support all of this stuff internally is the fact that, you know, you have to respond to, like, help Wes, and it's like a bigger API surface layer. But Yeah. That's one of the things that was trickier about Express is, like, going and finding all these middlewares to do the things that you wanted because it wasn't built in. All this stuff is is built into Dehono. Man, deny ESLint. I don't see a rate limiter just yet. That's something that I have to often throw in. They have Node.

What is it called? Docs, middleware, scroll all the way down, 3rd party middleware.

Yeah. Hold on. Reloader. Nice. I will say that's because there's so much.

That's probably one of the, issue like, the the biggest issues I've had is just just trying to, like, find it in the docs because there's so many things available. Yeah. There it is. If you need rate limiting in your app, install that middleware, set up your time window and, like, your key generator. Good to go. While we're here, it's also important to mention that they have a Sanity middleware. So Hey. If you wanna add Sentry to your Ono app, literally just npmi@hono/century, pass in your d s n, app Scott use, done. It's tracking all your Sentry errors. And then one more thing is, JSX support. So I mentioned earlier that you can use JSX, but, like, if you think of, like, the days of building something with Express, typically, you'd have to set up, like, a a view engine and then choose your view engine. Like, do you want handlebars? Do you want EJS? Do you want whatever else? Node supports JSX out of the box. So whenever you generate an app, it already has all the compiler options and everything that you need. And so you can just do c.html and then pass in some JSX.

I I love that. Yeah. I love that too. When I was working on a, I was working on a little HTML meta framework I was calling Hype, which I I'd stopped working on, but I used gratuitously that HTML. It was super nice to use in addition with things like, well, HTMLX or yeah. In general.

Exactly. Yeah. I used to use just, like, straight up functions that return strings, like templates. Right? Yeah. Yeah. But the the downside to that is you have to worry about XSS. Right? And then also, you're essentially just creating a an entire templating framework. Right. And it's much easier to simply just use JSX as JSX is a very good templating framework, and it's not the greatest. Like, there's I I still am waiting. We've been talking about JSX 2 point o for many, many years, you know, the ability to type specific children and things like that. But it's kinda what we standardize on in most cases. Yeah. It's funny, Wes. I've I've written so many, plug ins for Remark and whatever. I've basically written my own markdown based templating language down. I I often think, like, that was a bad idea to do that. Yeah. Yeah.

Oh, well. We'll never learn. Yep. And I think that's one of the beautiful things, though, because it's like, Wes, like, JSX allows you to define components, and that's typically what we're trying to do. So, like, you could even see this composition example here. Right? They have basically the body that just passes in a child, and then they have some other component that can render inside of it. And so, like, if you wanted to build this out with your own functions and, like, template strings, it it'd be some work. I will mention, like, if you look into their docs, they have a an even better way of doing this because you can basically define your renderer that kind of, like, renders the shell. And then Mhmm. It can have other routes that will get rendered into that shell, so you can set it up that way too. And then if you ever need, like, raw HTML or you need to insert, like, a script, they have, like, little helpers. Oh, yeah. Can insert that stuff into your JSX.

I I have a question that maybe you can answer. This is something I always hit whenever I spin up a Node app is I your route handlers, if you type it as, like, app Scott get forward slash cards forward slash, like, card number, and and that's like a param, you know, in there. And all of that stuff is all nicely typed as soon as you get into the route handler because you have attached it to the route definition.

But I find myself being like, no. I kinda wanna put this in a separate file and just have a list of all of my routes in 1 file and then link off to it. And then I find that's really hard.

I find, like, you miss a lot of the the complicated typings.

Is there anything for that?

There is. So first, I'll start with, if you look in their docs and you look under best practices, they say, let me do this. Yeah. That's what I thought. I was like, can I just put it in the thing? Yeah.

But, I think, like, this is one of the, the things that a lot of people really appreciated about the video that I made is I showed how you can do this and keep type safety. So if we look in the so for the recent video I made on syntax, I created a starter template. It's called the Deno OpenAPI starter. And if you look in source, go into routes, and then I have a tasks folder. I've shown how we can kind of, like, break it out. I just have this custom type here called app route handler, and then I pass in the type of the route.

This essentially just wraps the route handler type. I show how to do it in the video, but once you got it going, it's pretty simple because then your routes, you just say, what's the type of the route? Use this. This also passes in your bindings and anything you would need for, like, every single request.

But then from there, all of this is fully validated. So, like, this line right here where I say c.req.valid param, this is getting the ID from the URL, but as a validated number. So it used a Node validator to get there, and, you get that type inside of this code here, and this code will will never make it here unless that validator,

was was valid. And so it's kinda circular where your your route definitions import your handler, and your handler imports your route definition type. Is that true?

Well, it's, yeah, it's purely types. It's just pulling in those, like, the create type, the get one, the list type, but it's just the type. Because otherwise, yeah, it would be like a circular dependency.

Yeah. It's basically, like, define your validators in a in a similar way if you wanted to, like, export the type. And if if you have middleware that monkeys with the types, does that still flow through to the final handler?

That all comes down to defining your base type. So I feel like we're getting in the weeds now, but go go watch the video because it'll it'll teach you about that stuff.

But here for you. Yeah. Yeah. So I I set this up here. So I have basically, every single one of my routers, I just reuse this function, and it passes in those types. So, we can look directly in the Node docs. If you look for the app and then look under generics, you can pass in a type that defines variables and then also, like, your environment variables that you would use in Cloudflare Workers. But this is synonymous with if you remember in Express, it was like app Scott get and app dot set, I think. Yeah. Like, you could set the user in a middleware and then access that user in some other middleware.

And so, basically, what you do is you create this type here that says, this is what you're gonna have access to. These are your variables. And then every other handler and middleware can do c Scott get user and get access to it. So, yeah, in this case, the only variable that I have is my logger because I'm using a thing called Pinot Node, but that makes it accessible and all so and then my handlers. So literally any one of my handlers, I can do c.var.logger and then get access to debug info, inspect, that kind of thing. Oh, nice little utility

middleware. I like that. Yeah. I've always liked Pinot. I I I believe that's from the Fastify folks, if I'm not mistaken. Yeah. It is.

I, I've always used it for logging. It's basically structured logging. So Yeah. In your your logs always show up as, like, JSON, and then you can actually have some sort of, like, log aggregator that pulls these in and, like, does, like, visualizations and reporting. Oh, yeah. I've used it with Express before, and there's a a middleware for Deno lets you pull this in, and now you can have logging for all of your all of your requests. Sick. I love that. One thing I'll show you is validation. So I Wes we got into the weeds. We're showing some of that open API code. But if you just want some basic validation for the params in your URL or the body, they have the ability to pass in a validator as a middleware. And so you can define your route, pass in your validators,

and then access those things in a type safe way, inside of your handler. That's nice. I I love that. You you take all the, like, fussing around, like, is it there? Is it the correct type? You know? Like, having to put that in every single route handler is is really annoying. It's nice that Wes you can write your handler, assuming everything is perfect and in place.

Yeah. And I think that's one of the things that, like, it was so easy to get wrong in Express. Like, I saw so many beginners. Like, they weren't validating params. They sometimes not even validating the body, but Node makes it super simple. And especially if you combine it with, Node, because then you can define all of your XOD validate. Like, these days, XOD is, like, almost a mainstay in the the TypeScript ecosystem.

But, yeah, the XOD validator makes it a whole lot easier. Right? Form, this is my stuff, done.

And, yeah, we're we're running lower on time, so I,

we can go as we can go as long as we want. It's like the only place. It's our show. We do whatever we want.

Sweet.

I guess so after this, I guess I'll show you, RPC. So this is one of the other super cool things is, like, build out your routes like you're used to, like you might have used to have done with Express.

But the issue with that is if you wanted to call it from a a client side front end or something like that, then you have to, I don't know, copy paste the types in or write the types yourself if you want some sort of type safety.

Hono has this idea of RPC built in. I'm showing my screens right here, and I we have a a route definition defined. So it defines the URL, it defines the validator, and it defines the handler. So it's all the things you need for a back end request. But if we say type of on that variable, that type can be passed into the hono client, and then you get a fully typed client. So, literally, all we do is say type of. And then now, in my client side code, I say client Scott. It'll show me all of the available endpoints or all of the available URLs and methods. Yeah. And then I can, get access to all of those, and all of the data you pass in is type checked as well. That's that's amazing. So, like, Hono ESLint

essentially is a JavaScript like, client Node JavaScript library that if you pass it, your types, and hook it up to your your URL, you immediately have this thing where you can say, like, like it's almost it's not an ORM, but it kinda feels like that. Right? You could say, like, episodes dot find. And if you have a endpoint hooked up for that, you you could do it. Or if you wanna be able to, like, delete a specific item, it's fully typed. It had it knows what arguments you need to pass it.

There's no need to create API endpoints for all of these things that you want to do, which I I find exhausting. Like, oh, I have to make an pnpm API endpoint to create, read, update, delete every single piece of data that's just it just goes, and you have full access to it. Exactly.

And I think one of the beautiful things is the types just flow through. Like, there's no code generation here. That's another aspect of, like, working with back end APIs and front end. Like, a lot of times, you might have to run a build step that, like, generates the types or generates the client. This, you don't have to do that. If you're in a monorepo, you can literally just import that type. Yeah. Type inference in that way is so nice when it isn't generated.

Yeah. I do think yeah. Generated works, but it's always kind of a pain in the ass sometimes. Even with SvelteKit, they generate some some types when you run Svelte Scott dev. And, like, if you haven't ran Svelte dot dev in a second, you're you're getting some type errors. If you've created the older ones. Or something. It hasn't so you Scott and start the process or whatever.

Restart your TypeScript server, and it's like, I just don't wanna do any of that. You know?

I was just gonna say, I SvelteKit probably does one of the best, for this type of stuff. It's very because you simply just if you return data from a what what's what is it called? It I was gonna say loader. It's not a loader in SvelteKit. What JS it? It's a loader in Remix.

It's a load function

or an action. Function. Yeah. It is a loader. Okay. We'll call it that. But then it just immediately, the types go right from your back end to your front end, and you get the autocomplete go BRRR.

Yes. Exactly.

Autocomplete gober.

And this is, something a lot of times, you'll see people combine this inside of a Next. Js app. So they talk about adding Node inside of a Next. Js application. And, essentially, you add a catch all route handler. So, like, inside of your next Next. Js app / API slash bracket bracket route bracket bracket. So that means any Wes coming into API is gonna hit this handler, and then you just export a Node app from that handler.

And so from there, all all of your Next. Js pages and components can now just use that same type tonal client, but it's living inside of your Next. Js application.

Oh, maybe this is what I want. Because, like, I want I want, like, the Wes. Js experience. I want the app router, but I I want the, like, middleware dev experience of.

But I also don't wanna run, like, a I have a big enough monorepo right now. You know? Wouldn't it be nice to just stick it in there?

That's cool. I don't know how you could do that. I haven't played around with this yet, but, I could imagine it's really nice to work with. Because, like, any client component, you pull in the hono client, maybe you combine it with something like a 10stack query or something like that. Yeah. But then inside of server components, you could actually make requests directly to the Hono app. Now let's just look at the guide on testing. So testing is something that you should do. One of the things about, like, testing express APIs is you had to pull in, like, a separate library, like Supertest, and then it would, like, be able to send requests to it. We don't even have to talk about Wes right now. I'm only showing this file because the Node app exposes a request method that just behaves like a requester. So, basically, when you say app Scott request, that's not making a network request. That's just basically invoking that function directly. So you pass in URL, you pass in params or whatever else. So I could imagine that you combine this with the Node client. So inside of your Next. Js app, maybe it's a a server component. Maybe you don't wanna make an API call there. Maybe you wanna call that endpoint directly.

You could just import the Node app, app dot request, pass in the URL in your data, and then there's no hop. Right? It's not calling the network and then putting it into the server component. It's calling that that JS code directly.

So, yeah, this request method that's exposes is pretty nice. That's weird. That's nice. Wow.

I didn't even know that that you went deep on this. Like, that's anyone anyone who hasn't checked out CJ's YouTube videos, he goes deep, man. It's not just a, like, a hello world, and and don't talk about any of the problems that you're gonna hit. You know? Like, we should be thinking about this. What does the testing situation look like? Yeah. Yeah. Even beyond that, they have a testing helper too. So, like, this requester

literally just it this takes a web standard request. Like, you can literally pass in a capital r request object right there.

But, of course, that's not typed, because it's just a request object. But if you look at their test helper, you pass your app into it, and then it behaves just like the HONO client that I showed earlier. It has all the endpoints. It has all the methods.

And then now that's just requesting it directly. Right? It's not heading over the over the network.

Beautiful. Yeah. So that's pretty much all I had. I I like it. I've been spending a lot of time with it. I've built, like, several apps with it. It's great. I think the it's also like, it's a little bit newer, but the ecosystem is awesome. The community is awesome too. Like, if just looking at their their GitHub repo, the discussions are fairly active. And also looking at, like, a number of open issues, those are pretty active as well in terms of, like, people responding to them. So, yeah, I I'm definitely betting on Hono. I think it's here to stay, and, I'm gonna be using it for a lot of my stuff.

Yeah. And I'm sure the Cloudflare backing doesn't hurt there either. That's a big benefactor.

Definitely. Yeah. No kidding. The the integration with Cloudflare, if you are using it and you wanna be able to use, like, their database product offering, you know, it's just it's it's very, very smooth. Like, if you buy in on all of this, it's it's not even buying in because it it works anywhere. But Yeah.

Cloud I love Cloudflare so much, but sometimes it's really hard to get up and running. And this takes that barrier away and makes it so so simple.

I'm excited to see the the Node x stuff, see how that sort of shakes out because the only reason I don't use hono or the only reason I would move off of it is because, you know what? I really do want, like, a full stack framework. You know? I want the whole back end thing, but I also want to be able to pull Svelte or React or whatever in on the front end as well.

And, also, the HONO X doesn't have a, oh, maybe they do.

The, yeah, the RPC. For some reason, I thought there was no RPC with HONOS, but I guess you use HONO client. Right?

I believe so.

On HONOS.

And that's one more thing I didn't even mention is, like, technically, Hono also has their own, like, client side React library. Like, it's technically Hono JSX instead of, React. I think you can still use React with it. But if you're using Hone Node x, then, technically, you're using, like, their their version of it.

Yeah. They've, like, reimplemented most of the the React API. So most of your useEffect, useState, things like that will will transition over 1 to 1.

Yeah. I guess one last thing I'll mention because I think this JS, like the the hardest part is if you in a bigger hono application of getting good type support JS, like basically, it was covered in the best practices section of their docs where, like, if you define these things separately, then, like, your types aren't flowing through. But you have to also have to imagine, what if I have, like, 20 routes? How am I gonna get a hono client that has all of those types integrated? And I show how to do that in the the hono starter that I created, Wes, essentially, you put all of your Hono routers inside of an array and then just create a type that's a type of everything in that array. And this essentially gives you that fully typed client that you can pass to Hono client, and it has everything. It's every single route that you registered everywhere else, but you can do it in a more scalable way. Right? They all live in their own folder. They all have their own files and handlers, but this one type right here is kind of how they're all, like, brought back together. Oh, I like that. And then you can just you can use, like, dot notation to access the types instead of having to import every single one.

Exactly. Yeah. Cool.

Awesome. Well, that was, like, I'm a big fan of hono, but I learned quite a bit there. I'm I'm really excited about it. I think if you haven't yet try tried it, certainly watch CJ's video and give it a shot yourself.

Sec. And we'll link to that in the, show notes because, again, it is like, Wes said, it's deep. Because I I watched about half of it yesterday, CJ. I'm gonna finish it just because the open API stuff I almost said open AI. Open API stuff, Swagger doc stuff JS a complete mystery as to what the heck that even is. I've never even I've heard of it. I'd never used it. Don't know much about it. So I'm gonna have to check out that stuff in 2. Yeah. Awesome. Sec. Cool. Well, thanks so much for coming on and sharing your knowledge with us today, CJ, and, we will catch you on the next one.