[HN Gopher] HonoJS: Small, simple, and ultrafast web framework f...
___________________________________________________________________
HonoJS: Small, simple, and ultrafast web framework for the Edges
Author : nateb2022
Score : 269 points
Date : 2024-04-16 00:41 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| iansinnott wrote:
| Have used this a bit on personal projects. Being runtime agnostic
| was the selling point for me. Wanted to try Bun as the runtime
| but not use APIs that are Bun specific, in case I ran into issues
| and had to move to Node.
| mansarip wrote:
| Recently, I've been looking for a suitable stack for another pet
| project. Personally my go-to stack is Remix.
|
| But I want to use a server other than the default provided by
| Remix, i.e minimal Express. So, I found Hono. It looks
| interesting because it can run on many runtimes, and this time I
| want to try using Bun.
|
| After researching Hono, it turns out it can render JSX directly
| from the server, which piqued my interest. Then I tried to make
| the JSX interactive, and finally, I used htmx. Lol.
|
| And just yesterday, after spending hours I found a way to use
| PDFKit with Hono (Bun runtime), so I created a gist for
| reference:
|
| https://gist.github.com/mansarip/eb11b66e7dc65cee988155275a1...
|
| Anyway I'm still cautious about putting this Hono + htmx stack
| into production use.
| throwitaway1123 wrote:
| > After researching Hono, it turns out it can render JSX
| directly from the server, which piqued my interest. Then I
| tried to make the JSX interactive, and finally, I used htmx.
| Lol.
|
| HTMX is fine if you want to avoid writing client side JS, but
| Hono did add support for client components in version 4 [1].
| There's even an esbuild middleware that can transpile TS/TSX
| files on the fly (the Deno framework Fresh uses a similar
| technique) [2].
|
| [1] https://hono.dev/guides/jsx-dom
|
| [2]
| https://github.com/honojs/middleware/tree/main/packages/esbu...
| dhucerbin wrote:
| May I interest you in hwy.dev?
| willsmith72 wrote:
| hono and remix are a dream combo
| jacobn wrote:
| I've been mulling over this weird idea that we should all be
| using an Edge (Web) Framework that manages the layouts + static
| site content, then pulls in either JSON or pre-rendered HTML
| templates from the more dynamic db-driven backends (which can
| then be in any language, and mapped to any path, and can be a
| majestic monolith or many microservices, whichever).
|
| It would free things up so much - the backend team can focus on
| JSON/HTML templates, the designers can work directly with the
| website without necessarily going through dev (for better or
| worse ;), marketing can add all their little trackers, easy to
| outsource parts, and you could build up an entire cross-language
| ecosystem of plugins that manage anything from user accounts,
| billing, wikis, blogs, knowledge base, admin CRUD systems, ...
| yet it's all on the same site from the end user's perspective.
|
| I think there are multiple enterprises that have (also
| re-)invented this architecture, but I haven't seen any serious
| open source offering that focuses on this type of use.
| blackoil wrote:
| A backend + NextJS is somewhat what you are suggesting. Backend
| serves json/graphQL. Frontend server is responsible for
| rendering, caching, templates etc. Prerendered HTML in backend
| will overlap the roles, so not sure if that is used.
| angra_mainyu wrote:
| Isn't this basically astro?
| zarzavat wrote:
| Conway's law comes to mind: the architecture of a system
| reflects the structure of the organization that created it.
| bensmithett wrote:
| I also mulled over this weird idea a while back!
|
| https://github.com/bensmithett/coexist
| syhol wrote:
| Sounds like the Backends For Frontends pattern. Sam Newman has
| a nice write-up on this.
| axelthegerman wrote:
| Maybe I'm missing something but what is the role of the edge
| web framework?
|
| If the actual backend renders HTML and JSON and we have a CDN
| for static assets I'm not sure what's missing.
|
| Sure bringing stuff onto the edge is great but if the edge
| needs to always forward requests upstream there is limited gain
| here.
| datascienced wrote:
| Edge can win if data (as in realtime app data not just static
| stuff) is replicated there at least or possibly even better
| can allow writes using CRDTs so the edge is also a
| distributed DB node.
| rofrol wrote:
| for moving data to the edge
|
| sqlite zig postgresql https://turso.tech/blog/zig-helped-
| us-move-data-to-the-edge-...
| crabmusket wrote:
| This sounds almost like a "backend for frontend" pattern.
| metalrain wrote:
| Marketing scripts often are invasive, wanting to run before all
| other scripts or overriding event/clickhandlers.
|
| For me it kind of feels you need some runtime and DSL to enable
| all requirements in web. And Google Tag Manager isn't it.
|
| I'm not saying we should go back to XML and XSLT but some
| separation of concerns would help: data, display, events,
| animation.
| rozenmd wrote:
| I use this both on Cloudflare Workers and classic Node servers,
| it's fast and reliable.
| rrr_oh_man wrote:
| _> Batteries Included - Hono has built-in middleware, custom
| middleware, and third-party middleware. Batteries included_
|
| What does this mean?
| tobyhinloopen wrote:
| If it includes third party middleware, is it still third party?
| aerhardt wrote:
| It means instead of the philosophy prevalent in the JS world of
| bringing everything in as a dependency by yourself, the library
| attempts to provide sensible default solutions for you.
|
| I don't know what that might cover, but it might be things as
| basic as parsers for headers and cookies. Which I applaud,
| because me personally, that's shit I've never wanted to think
| about.
| pavlov wrote:
| It's a slogan popularized by Python.
|
| Python with its seven circles of infinite package hell also
| demonstrates the limits of this approach. It's not very useful
| that the language gives you two AA batteries when your
| application needs a megawatt of power (metaphorically).
| datascienced wrote:
| Batteries included really means large sections of the factory
| included!
| pavlov wrote:
| Always the wrong sections in my experience...
| austin-cheney wrote:
| When it comes to frameworks (any framework) any jargon not
| explicitly pointing to numbers always eventually reduces down
| to some interpretation of _easy_.
| axhl wrote:
| Please could a fellow HNer who has experience using this explain
| in simple terms what Hono on a Cloudflare Worker enables that one
| cannot already do with a vanilla worker?
|
| The docs[0] are not instructive on this point.
|
| [0] https://hono.dev
| yawnxyz wrote:
| it's just really nice abstractions that makes everything nicer.
| But it doesn't offer anything new that you couldn't build
| yourself
| pier25 wrote:
| It's good but it's not much of a framework.
|
| To me a backend framework is more like Rails or ASP.NET. Hono is
| more like an http router.
| dreadnip wrote:
| It's similar to the PHP micro-frameworks back in the day, like
| Silex and Lumen. Those often didn't contain more than a router,
| middleware, request/response objects, some type utils and a
| validator.
| diordiderot wrote:
| I thought those were 'batteries included' framework. I can't
| think of any generally recognized boundaries though
| cies wrote:
| This is also called a framework:
|
| https://github.com/cloudflare/pingora
|
| Pingora is actually fast and small (it does not require a JS
| engine). Way faster and smaller than Hono.
|
| If you want something to be really fast: do not use RegExes.
| vaylian wrote:
| > It works on any JavaScript runtime: Cloudflare Workers, Fastly
| Compute, Deno, Bun, Vercel, AWS Lambda, Lambda@Edge, and Node.js.
|
| Does it work in the browser as well?
| vijaybritto wrote:
| Yes I think so. You can use it in a service worker too
| rafter wrote:
| Yes it works in the browser also. I've been using it for
| routing and templating etc client side (main thread, and
| service worker), as well as in a cloudflare worker.
| vmfunction wrote:
| this is kinda lib we need! Not something specifically coded
| for a runtime, rather adhered to the Web Standard.
| bnjemian wrote:
| Been using Hono for a few months and have really enjoyed it. For
| me, it's been the perfect minimal HTTP/router functionality
| needed to structure an API that lives within a single edge
| function that's deployed to Supabase and interacts with the
| Postgres DB therein. Great project - simple, intuitive, fast,
| lightweight.
| 4star3star wrote:
| Hi, new to Hono, Supabase, and never used Deno - do you have to
| use Deno with Supabase or can you substitute Hono?
| bnjemian wrote:
| In the documentation and Supabase CLI, edge functions on
| Supabase are demonstrated and scaffolded, respectively, with
| a Deno runtime. I don't think it's required though. And if
| you've used Node.js, Deno will feel very familiar.
| _spl wrote:
| I've been using Hono + Bun + SQLite for all my personal projects,
| and I really like it. Essentially, I've replaced Express and Node
| with it. What I appreciate the most is how quickly I can set up a
| project with Bun, have native SQLite connector, and how minimal
| the Hono base app is. Additionally, I can use JSX without any
| setup hassle.
| machiaweliczny wrote:
| Do you have some example?
| Liquix wrote:
| not that guy, but here is a small video streaming example
| using Bun/Hono/SQLite/Drizzle/SolidJS:
| https://codeberg.org/vlfldr/ucourse
| blackhaj7 wrote:
| Where do you deploy these projects?
| sandGorgon wrote:
| we decided to base our GenAI framework - Edgechains on Hono.
| Primarily because of winterjs compatibility. We build a WASM
| compiler to compile our prompts and chains into webassembly.
| Honojs was a critical part of it.
|
| https://github.com/arakoodev/EdgeChains/
| ricopags wrote:
| Have you looked at AICI by Microsoft yet?
|
| https://github.com/microsoft/aici/
| sandGorgon wrote:
| yup. there are two differences - we model prompts AND chains
| (the looping logic) as a config management problem. So we
| model it in jsonnet and then compile it to wasm as a
| deployment step. The rest of everything we do is javascript
| and api-centric. In that way, we are solving a DX (or a
| developer UX problem) if you will.
|
| AICI takes a more abstract approach here - first everything
| not related to prompt or token compilation is out of scope.
| So your api is not wasm-ed. Second, the job of creating the
| wasm prompts is your responsibility - use what you will.
| While we fundamentally try to answer the question "how can
| prompts and chains be expressed in a WASM friendly way
| without locking urself to the language and having it as a
| config"
| SpaghettiX wrote:
| Has anyone also used an interesting alternative, Elysia, and
| understand the differences? Both are quite modern, ergonomic
| frameworks.
| renke1 wrote:
| Looks interesting. Does anyone have a good example that uses
| Client Components?
| jpahd wrote:
| Looks like a js version of mojolicious :D
| samsquire wrote:
| I'm curious what makes it so fast?
|
| The README.md says RegExpRouter uses no loops and just regular
| expressions, presumably it maps a route to a hashmap matched
| entry?
|
| Related but slightly different:
|
| I am curious because NFAs, deterministic automata are interesting
| to me. I remember one person on HN talked to me about using
| regular expressions to match event sequences. (That is: don't
| match against strings but match against tokens)
|
| I am not a Rust developer, but the pattern of using Rust sum
| types and pattern matching or OCaml dispatch based on types are
| similar to me intuitively.
|
| What are your thoughts on this style of programming?
|
| I feel so much of modern business programming is dispatch logic!
|
| If you think of Redux and state machines and event sequences in
| GUIs for behaviour, I feel there is a lot of untapped potential
| ideaspace here.
| wrsh07 wrote:
| The regexprouter compiles all of the routes into a single
| matcher, so you're not doing a linear search of all of your
| routes (lots of routers are essentially doing an if else on all
| of the routes).
|
| They also have a similar trie router, but my understanding is
| that it's not as fast.
| amsterdorn wrote:
| Hono is great! I used it to build a dev blog w/ Cloudflare
| workers, source is here if anyone's curious:
| https://github.com/brycedorn/blog
| soulchild77 wrote:
| I created a pet project (REST API) with Hono and I'm seriously
| considering using it for future projects instead of what has been
| my go-to stack for years (Express, lately with Zodios).
|
| Hono's middlewares, especially zod-openapi[1] and @scalar/hono-
| api-reference[2], make it really easy to define your REST
| endpoints once and get full typesafe routes with request/response
| validation, an automatic OpenAPI spec, a beautiful OpenAPI
| browser and you can even reuse the typings in your frontend with
| Hono's RPC[3] middleware, essentially giving you end-to-end type-
| safety without any code-generation.
|
| Its maintainer yusukebe is a really nice guy who is always being
| helpful and very active. I want Hono to become the modern
| successor of Express. :)
|
| [1] https://hono.dev/snippets/zod-openapi
|
| [2] https://www.npmjs.com/package/@scalar/hono-api-reference
|
| [3] https://hono.dev/guides/rpc
| franciscop wrote:
| I'm very curious, I'm learning from both HonoJS and ElysiaJS
| about how to build a great next-generation library, and the
| thing that strikes me from Hono is that it seems it has
| integration for a lot of things, BUT you have to write a lot of
| manual code for those instead of "extending the base Hono" so
| to speak. For the `zod-openapi` example you gave, I'm looking
| at the docs and it seems there's no import in common from hono
| to hono/zod-openapi project: import { z }
| from '@hono/zod-openapi' import { createRoute } from
| '@hono/zod-openapi' import { OpenAPIHono } from
| '@hono/zod-openapi'
|
| I would have expected/hoped things to be more integrated, e.g.
| you still do `import { Hono } from 'hono'` and then somehow you
| connect to this OpenAPI middleware. Any thoughts on this? Do
| you feel like moving from "base Hono" to use hono/zod-openapi
| you have to change how you do things? Another place I've seen
| this pattern is with the different edges, you have different
| import/exports, which I understand to certain degree but I
| still think a bit more could be done at the base library.
| soulchild77 wrote:
| That's actually something I find a bit awkward, too.
| Especially, there was no way to re-use the global Hono error
| handler for all OpenAPI routes. I created an issue[1] with my
| suggested workaround and was told that that's the way to go.
| Maybe things are that way because `zod-openapi` was
| introduced later on. But I believe in the end it doesn't
| really matter that much as the code is clean and readable. :)
|
| [1] https://github.com/honojs/middleware/issues/323#issuecomm
| ent...
| groothe1drr wrote:
| Was looking to do this the same with Hono. Need a basic REST
| API. Possible for you to share your code?
| lioeters wrote:
| > request/response validation
|
| > beautiful OpenAPI browser
|
| > end-to-end type-safety without any code-generation
|
| That's a great sales pitch - I'd looked at Hono before but now
| I've opened all the links you mentioned and will try it out.
| sqwxl wrote:
| We are using a similar stack. I assume your client is located
| in the same repo as your server? That's a no-go for us, so
| we're planning on using the OpenAPI spec to generate a type-
| safe frontend client. I kind of wish it was as easy as using
| the RPC middleware, though.
| strogonoff wrote:
| At first glance, Hono seems like the most standards-compatible
| framework.
|
| > It works on any JavaScript runtime: Cloudflare Workers, Fastly
| Compute, Deno, Bun, Vercel, AWS Lambda, Lambda@Edge, and Node.js.
|
| Not sure it counts as "any JS runtime" if it does not work in
| browser (e.g., worker context), but judging by the rest of the
| docs it might work there, too.
| rafter wrote:
| Yeah, it works in the browser also.
| syrusakbary wrote:
| It also even works in Wasmer Edge (template here:
| https://wasmer.io/templates/hono-starter )... I'm incredibly
| impressed with how much effort they have been putting on the
| framework, I bet they will win big time!
| Ajnasz wrote:
| How often developers encounter performance issues coming from the
| slow framework, so they need to switch to a fast one? Which one
| is the slow?
| JodieBenitez wrote:
| In my case, the number of times the bare
| request->router->response cycle has been the bottleneck is
| exactly 0.
| orph wrote:
| Hono still doesn't support request cancellation well.
|
| So if you're streaming tokens from an LLM and you cancel the
| request from the client you'll be wasting money.
| nobleach wrote:
| I've built POC apps with both this and Elysia recently. Elysia is
| really cool, it has a bit of its own ecosystem. Eden Treaty for
| example, is the way it handles backend to frontend type-safety.
| Hono on the other hand, seems like such a nice ExpressJS
| replacement. I wouldn't hesitate to ship either one.
| 4star3star wrote:
| Having proper routing for cloudflare workers will be nice, and it
| looks like Hono covers all the bases.
| orliesaurus wrote:
| OT: I met the author of Hono at a Cloudflare meetup, he was
| really cool and we chatted about how things are so different in
| Japan, his country of origin. Honestly that's why in-person is so
| much better for.
| dandigangi wrote:
| Did something change w/ Hono or it just someone reposting about
| it?
| spxneo wrote:
| Supabase already offers a full REST API when i upload my db. How
| does this differ?
| k__ wrote:
| How does Hono compare to Elysia?
|
| I often heared both mentioned together with Bun.
| 0xedd wrote:
| Enough with all the web frameworks.
| __jonas wrote:
| This is interesting:
|
| https://hono.dev/concepts/routers
|
| I was just thinking about implementing a trie based router for
| fun in a different language, I would have never guessed that this
| big RegEx method is the winner in terms of performance here.
___________________________________________________________________
(page generated 2024-04-16 23:02 UTC)