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.
Or these Koa deps:
- https://github.com/isaacs/inherits/blob/main/inherits.js
- https://github.com/component/toidentifier/blob/master/index....
When you're building a web server library, you need to care about supply chain attacks because you're the one exposing people to them.
Anyways, that's beside the point. Hono is what Koa should have been if Koa wasn't frozen 10 years ago: a simple `res = await handle(req)` abstraction that works everywhere including edge workers.
So the question is whether the target audience here is “people who want to build full-stack web apps” or “people who are already using the BHVR stack”.
If you build MERN apps, this is a template that replaces Express with Hono, Node with bun, and Webpack with Vite.
All of which are significantly faster than their counterparts. Hono can be deployed anywhere and has a much smaller bundle size than Express.
The exclusive gatekeeping messaging doesn't seem very useful. There's probably a much bigger audience for "Hey, instead of starting yet another Node project, why not try this?" rather than preaching to the already converted early adopters.
https://npmtrends.com/react-vs-vite-vs-webpack
Imagine someone posting a project that uses React and then someone demanding they explain what React is...
That's fine but OP's template is clearly for devs with frontend skills. No?
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.
- 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
> 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?
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.
https://medium.com/@chaudharyaniket16/from-14-minutes-to-45-...
To list some projects and companies that aren’t on NPM: Prettier, Next.js/Vercel, Cloudflare, Hono, Zod, Expo, Tamagui, Tailwind, the list goes on. I actually had trouble finding any major JS projects that are on NPM. These are serious, widely used packages, and they chose non-standard tooling for a reason.
The post describes moving from an old Yarn version that still suffered from the long, long fixed problem npm had with tree shaking. In fact, their inability to port to the newest Yarn version just highlights my point. Modern npm has solved all of these issues without the compatability problem.
>"Yarn v2 introduced several new features, including a different approach to managing the node_modules folder by eliminating it altogether through its Plug’n’Play mode."
And this is just complete insanity.
That aside, I can see that there's no real argument against pnpm at this point. It wouldn't be the end of the world. I just don't buy saving 20 seconds in CI as a legitimate reason for it.
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?
Bun is faster & has better package management, but the build is only suitable for very basic use cases. Once you get into more exotic build scenarios, the lack of plugins for bun gets obvious, so we've switched from a custom bun build script back to vite.
Side note (in true HN tradition):
I'm a bit hesitant to base our front-end on react. It has currently become the de-facto ui solation, which makes me wonder if the new kid on the block (solidjs IMHO) would not be more suitable.
Unfortunately the ecosystem for solidjs isn't at that level where I'm confident enough yet to make the big bet & switch to it in full. Maybe we'll use it in a few side/tool projects, too get a general feel and see how this evolves...
I'm also curious why you'd need vite with bun, maybe there are some features in vite that bun is missing?
If “bun index.html” works for you right now, then great! Otherwise you may need to go to vite for a while yet.
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!
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?