Hono v4.0

Nowhere there&#x27;s any explanation of what this is. Web standard? Fast? Workers?<p>Ok, but what is it doing? How can it help me? The snippets subpage is empty. The examples have code directories with almost empty readmes.

I&#x27;m using Hono and Deno for <a href="https:&#x2F;&#x2F;flashcasts.com" rel="nofollow">https:&#x2F;&#x2F;flashcasts.com</a><p>Hono + Postgres.js is getting pretty close to my ideal web stack.<p>IMO, SSR websites is the best way to get projects out quickly: predictable &quot;builds&quot;, minimal surface area, boring tech, etc.<p>It helps that Hono has a very clean API :)

I only ever used hono as a simple convenience router for my cloudflare functions. This feels ambitious. I’m a bit skeptical if this is the right direction frankly, I hope it doesn’t make the framework too bloated.

Hono looks very cool but in my experience you can quickly run out space in your lambda (package size) when you bundle your whole application together verses having each endpoint be it’s own package.<p>Am I wrong or have others experienced this as well? Just having 1 package (to deploy vs 1 per endpoint) would be super nice in a number of ways and you could take advantage of things like provisioned concurrency (something much more difficult to plan for when you have a lambda per endpoint).<p>Maybe I’ll just branch my main project and see what happens as I move my code into a monolith with Hono but I’d love some feedback if others have experienced this and&#x2F;or how they worked around it.<p>I guess you could still have multiple Hono-based packages that handle segments of your backend (verses all in one), is this how people are managing it?

I&#x27;ve used deno + hono and a basic file-based router for a few projects now. The biggest win IMO is avoiding a build step, I hope HonoX and the hono project in general don&#x27;t start walking down the same path as others, using Vite for a required build and bundle step.<p>Astro already solves many of the problems HonoX will run into, if a build step with Vite is acceptable for you. What I personally really want is an easy way to deploy exactly what I have locally and keep my dependencies small enough that shipping it unbundled isn&#x27;t a problem for your project.

This is awesome! The server-side, the page gen, the router, jsx on the backside, outstanding work!<p>In webdev, I’ve been a huge fan of vite since it came out. Not having to wrangle configurations and bundlers and everything was very welcome. I wrapped it all up into a useful internal tool to play nice with our packages and splice together express+vite frontend. Then koa+vite. After playing with bun, I’m very keen on stack setups with convention over configuration (with config options) to just do the typescript thing, do esm, do it well.<p>I’m going to give this a go this weekend and see if this can replace our setup. Bun+Vite(React-TS)+Koa.

Never heard of this, took some digging to figure out what it is. Best blurb I found was in the docs, not the homepage:<p>Hono - [炎] means flame in Japanese - is a small, simple, and ultrafast web framework for the Edges. It works on any JavaScript runtime: Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, Netlify, AWS Lambda, Lambda@Edge, and Node.js.

Hono, Bun and SQLite are soo boring - I love it.

I am using it to build <a href="https:&#x2F;&#x2F;easyanalytics.win" rel="nofollow">https:&#x2F;&#x2F;easyanalytics.win</a> . Honojs is a nice framework for routing. I chose it because i was working on cloudflare functions and i did not wanted to tie my application to cf way of doing things. By using honojs i can use it in both serverless as well as server-full settings without any changes. However i am not liking the current direction this project is taking its becoming too bloated.

I rewrote OnlineOrNot&#x27;s API to use Hono + Zod (almost a drop-in replacement for Express), and got an OpenAPI schema out of it for very little additional work.<p>I highly recommend it, and wrote more about it here: <a href="https:&#x2F;&#x2F;onlineornot.com&#x2F;built-my-http-docs-from-scratch#converting-openapi-schemas-to-markdown" rel="nofollow">https:&#x2F;&#x2F;onlineornot.com&#x2F;built-my-http-docs-from-scratch#conv...</a>

Would this be a sort of holy grail product, where we could write once for &#x27;edge&#x2F;function&#x2F;lambda&#x27; systems? I am helping develop a new project that will be hosted on Azure, but would really like to make it as cloud portable as possible, including a cloud-free version. It is a significant product for a government agency, and it will be open source. I really want to get this piece right. Thanks!<p>[edit] I notice Azure support is under development. But the time frame could be ok if it has good tests &amp; the project is well supported.

I know AWS&#x27;s LLRT was just announced, but it would be great if this would support it. (For reference: <a href="https:&#x2F;&#x2F;github.com&#x2F;awslabs&#x2F;llrt">https:&#x2F;&#x2F;github.com&#x2F;awslabs&#x2F;llrt</a>)

I use hono a lot and im going to avoid these new features for certain. Hono already had a problem with documentation and feature completeness for anything beyond their simple REST api, such as their middlewares like graphql and RPC. The jump in complexity from a meh graphql plugin to a full stack SSR framework is so massive and I don&#x27;t think the current dev team can do it justice.<p>I highly recommend anyone looking into this to instead stick with larger, better community supported projects like Astro.

how does this compare to primatejs?