Right now it’s summarized as “typesafe fullstack monorepo”… But that’s so dense, it’s practically just three buzzwords together. A more realistic description of the pros and cons would be welcome.
I’ve never heard of Hono, and I’d personally need a lot more convincing to pick an unknown framework for a new app.
Hono is basically next gen Koa: zero dependencies and made to work in additional contexts like in CloudFlare Workers.
- Express deps: https://npmgraph.js.org/?q=express (lol)
- Hono deps: https://npmgraph.js.org/?q=hono
Node web servers are all so similar (you write ~identical code no matter which one you use) that tie-breaking on a dep diff this big is reasonable.
Works on Cloudflare, Fastly, Deno, Bun, AWS, or Node.js. The same code runs on all platforms.
How does compare to ultrajs? Or just use hono client side jsx, its pretty much like react already.
I've used a very similar setup for a couple of new projects which were about to default to Next.js but didn't really specifically need what Next.js does (e.g. its SSR abstractions, these were internal, client-only apps sitting behind an auth redirect) from wasting their time fighting it.
Hono also supports JSX on the backend out of the box of you want to use components as a superior alternative to string templating libraries to serve up some HTML, a middle ground of sorts if Astro (:heart:) is too much for what your app needs to do.
I haven't needed to take advantage of this yet, but if you don't need full-fat React, it can also SSR and run on the client, sort of "vanilla JSX" if you will (sorry).
I think Astro is perfect fit for majority of projects.
Ridiculously simple in use without all the next toil and issues
You still won’t get auto-generated hooks or WebSocket subscriptions, but for plain REST/JSON the old “hand-rolled fetch” drawback is gone, leaving only edge cases like hooks, real-time, and IDE scalability as the remaining trade-offs.
> Route Error Boundaries keep the happy path happy. Each route module can export an error boundary next to the default route component.
> If an error is thrown, client or server side, users see the boundary instead of the default component. Routes w/o trouble render normally, so users have more options than slamming refresh. If a route has no boundary, errors bubble up. Just put one at the top and chill out about errors in code review, yeah?
- NestJS - React Router - React
Whatever bundler/pack-man you want to use, go ahead. I'm curious which one would objectively be better, because I'd go for vite due to familiarity
Also, does this have SSR?
If the speed of your package manager is causing issues for developer velocity you have much bigger issues to contend with. And I categorically reject the statement that either of those are meaningully faster in any way. Maybe you can point to some specific obscure benchmarks that have slightly smaller numbers. But all of that goes out the window the second a dev is stuck with one of those "rough edges" even once. Not even to mention the lockin you've achieved on the tooling front now that your entire stack is nonstandard and reliant on a single highly specific list of dependencies to work, which may or may not even be kept in line with their node/npm counterparts.
in which case it would be nice to see it extended slightly: tailwind client side and eg drizzle ORM - basically the minimum you need to really ship a client/server app
Fastify is great, I just like Hono more ¯\_(ツ)_/¯
If not, great opportunity for bvrrr.
Besides the performance, it has a major advantage of being a native API of the bun runtime, so you can trivially manage bundling tasks at runtime with extreme flexibility, including typescript path resolution rules, saving a major amount of headache compared to just about every other js bundler.
Why do you need both Bun and Vite?
Vite is specifically used for bundling the frontend and chosen due to the vast ecosystem of plugins that people use for it. Tailwindcss is a great example, others here: https://vite.dev/plugins/
Bun does quite a bit more. In this context it’s used as a runtime and a package manager, and automatically handles the workspaces aspect for shared types. While you might be able to achieve all of bhvr with just Bun I chose to stick with Vite due to the number plugins, tutorials, setups, etc. that all use it. Just keeps things simple and easy!
Do you have a plans to add the ORM?
With typescript, there's an error squiggle in your editor under the bug before you even run your app.
1. How does this compare to the MUNGG stack?
2. When can we expect compatibility with Curlew templates?
3. I get cryptic build errors when I add Seieki.js as a dependency. Has anybody else experienced this?
