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.
ππΏπΌπ»π-π²π»π± π±π²ππ²πΉπΌπ½π²πΏ sharing what I learn. I introduce new tools and ideas hereβyour support means the world! π
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! βοΈ
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.
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! βοΈ