Looks like 1000 things before, a clone of a pure node based api wrapper. Seems like a pretty basic implementation, doesn't seem to allow enforced hierarchical routing, routes are burried in a func. Not sure why anyone would pick this over express, if nothing more than by comparing documentation and proven use cases. What does it have to offer over the other clones, hard objective numbers... the words in bold in the article are marketing terms... unless you can prove it has better "efficiency, scalability, and modernity" than all others... good luck 🤣.
I used hono like a year ago and I think if all you want is to target a Node.js server you are indeed better off with express (or even better something like Fastify).
Hono shines when you want to decouple from the runtime. For instance, if you want to run today on Cloudflare Worker, tomorrow on AWS Lambda and next week on some other platform that may not have a full Node.js runtime then hono is useful. It brings those platforms into a common API. You build once and the adapters guarantee that it can be shipped to those.
That's also why it is being used by many frameworks as the working horse underneath. It is an abstraction over the potential deployment targets.
Maybe you guys are correct... but I didn't get that from the article. Again, I know nothing of hono outside this article, so when I read this kind of stuff sort of advert-introducing (new word) me to it, I sort of assume I'm the target audience, someone that doesn't already know the tool.
So its cloud centric while express and the like are server centric. That makes sense, next question is how does it work under the hood and in place with the huge range of proprietary cloud systems, what integration looks like, etc... I don't see the need to show route code that looks like many others that aren't great, need to see integration cleanup with docker and K8s as a result of switching for example, as well as cloudfare and bun and such. Performance comparisons would close the deal.
I find myself in a position were I can write any code fast, but getting it deployed affordably, reliably, extendably, and CI/CD-ably is another story, almost a nightmare of proprietary and environment dependent ugly configs that don't play well together. If some effectively wrapped each vendors proprietary nonsense, found the common ground, and created a common system to deploy anything to anywhere, hell yeah I would bite... if that's what this is, I thought it was just an API.
Thanks for sharing your experience! Totally agree—Hono’s real strength is its flexibility across runtimes and platforms. For Node.js-specific projects, Express or Fastify can definitely be great picks, but Hono’s abstraction makes it shine in edge-native and multi-platform setups. Appreciate your insights! ✔️
Hey, thanks so much for taking the time to share your thoughts! I totally get where you’re coming from, and I really appreciate your feedback. Let me address a couple of the points you raised:
About routing: Hono.js is designed to be super lightweight and minimalist. It might not enforce "hierarchical routing" out of the box, but it’s got simplicity and flexibility that many developers really value.
Comparison with Express: 100% agree that Express is a rock-solid tool with amazing documentation and proven reliability. But Hono.js is built with modern environments like Cloudflare Workers in mind, where speed and a small footprint really make a difference.
On "efficiency and scalability": I get that these words might sound like marketing buzzwords, but they genuinely reflect what Hono.js aims to achieve—especially in edge-native platforms like Deno or Bun. I promise I’ll include benchmarks and real-world examples in future posts to back this up!
Thanks again for bringing this up—it’s feedback like yours that sparks great discussions and helps improve things! Looking forward to hearing more from you. 🙌
That’s awesome to hear! Out of curiosity, what kind of project were you working on where Hono’s SSR and JSX support made a big difference? Would love to know more about your experience!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Looks like 1000 things before, a clone of a pure node based api wrapper. Seems like a pretty basic implementation, doesn't seem to allow enforced hierarchical routing, routes are burried in a func. Not sure why anyone would pick this over express, if nothing more than by comparing documentation and proven use cases. What does it have to offer over the other clones, hard objective numbers... the words in bold in the article are marketing terms... unless you can prove it has better "efficiency, scalability, and modernity" than all others... good luck 🤣.
I used hono like a year ago and I think if all you want is to target a Node.js server you are indeed better off with express (or even better something like Fastify).
Hono shines when you want to decouple from the runtime. For instance, if you want to run today on Cloudflare Worker, tomorrow on AWS Lambda and next week on some other platform that may not have a full Node.js runtime then hono is useful. It brings those platforms into a common API. You build once and the adapters guarantee that it can be shipped to those.
That's also why it is being used by many frameworks as the working horse underneath. It is an abstraction over the potential deployment targets.
Maybe you guys are correct... but I didn't get that from the article. Again, I know nothing of hono outside this article, so when I read this kind of stuff sort of advert-introducing (new word) me to it, I sort of assume I'm the target audience, someone that doesn't already know the tool.
So its cloud centric while express and the like are server centric. That makes sense, next question is how does it work under the hood and in place with the huge range of proprietary cloud systems, what integration looks like, etc... I don't see the need to show route code that looks like many others that aren't great, need to see integration cleanup with docker and K8s as a result of switching for example, as well as cloudfare and bun and such. Performance comparisons would close the deal.
I find myself in a position were I can write any code fast, but getting it deployed affordably, reliably, extendably, and CI/CD-ably is another story, almost a nightmare of proprietary and environment dependent ugly configs that don't play well together. If some effectively wrapped each vendors proprietary nonsense, found the common ground, and created a common system to deploy anything to anywhere, hell yeah I would bite... if that's what this is, I thought it was just an API.
True (the article did not go into those details) - that's why I wrote the comment.
Thanks for sharing your experience! Totally agree—Hono’s real strength is its flexibility across runtimes and platforms. For Node.js-specific projects, Express or Fastify can definitely be great picks, but Hono’s abstraction makes it shine in edge-native and multi-platform setups. Appreciate your insights! ✔️
Hey, thanks so much for taking the time to share your thoughts! I totally get where you’re coming from, and I really appreciate your feedback. Let me address a couple of the points you raised:
About routing: Hono.js is designed to be super lightweight and minimalist. It might not enforce "hierarchical routing" out of the box, but it’s got simplicity and flexibility that many developers really value.
Comparison with Express: 100% agree that Express is a rock-solid tool with amazing documentation and proven reliability. But Hono.js is built with modern environments like Cloudflare Workers in mind, where speed and a small footprint really make a difference.
On "efficiency and scalability": I get that these words might sound like marketing buzzwords, but they genuinely reflect what Hono.js aims to achieve—especially in edge-native platforms like Deno or Bun. I promise I’ll include benchmarks and real-world examples in future posts to back this up!
Thanks again for bringing this up—it’s feedback like yours that sparks great discussions and helps improve things! Looking forward to hearing more from you. 🙌
I used it because it is only framework that worked with ssr jsx out of the box.
That’s awesome to hear! Out of curiosity, what kind of project were you working on where Hono’s SSR and JSX support made a big difference? Would love to know more about your experience!