[HN Gopher] Show HN: Bhvr, a Bun and Hono and Vite and React Sta...
___________________________________________________________________
Show HN: Bhvr, a Bun and Hono and Vite and React Starter
Hey all! I've been using this stack personally for a while now and
decided to automate it a bit by turning it into a template I can
reuse. Hope others might find it helpful!
Author : stevedsimkins
Score : 122 points
Date : 2025-04-27 11:02 UTC (1 days ago)
(HTM) web link (bhvr.dev)
(TXT) w3m dump (bhvr.dev)
| theli0nheart wrote:
| Love the name!
| stevedsimkins wrote:
| Thank you!!
| pavlov wrote:
| I think you might want to elaborate on why this stack is good.
|
| 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.
| stevedsimkins wrote:
| I appreciate the feedback! This stack does kinda assume you
| already know what Hono is but I can definitely flesh it out a
| bit more, and perhaps show some code to demonstrate it.
| VyseofArcadia wrote:
| I mean, I also don't know Bun and Vite. I've at least seen
| React. You should probably just explain the whole stack.
| Etheryte wrote:
| This is like saying a Java library readme should start with
| what the JVM is. It's fine to not know these things, but
| the majority of this comes with the territory. Right now it
| sounds like you're simply not the target audience. The
| Github readme includes a link to all of the major bits, so
| I don't really see the problem.
| pavlov wrote:
| If you were trying to convince me to build a web app in
| Java, you wouldn't need to explain what the JVM is, but
| you'd need to make a strong argument for why Java is
| better than the alternatives available in 2025.
|
| 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".
| crab_galaxy wrote:
| The benefits are very clear to me.
|
| 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.
| pavlov wrote:
| These two paragraphs would already be a much more helpful
| project description than "typesafe fullstack monorepo".
| pier25 wrote:
| If you've never heard of Bun or Vite you're clearly not the
| audience for this.
| pavlov wrote:
| Why not? There are a lot of people who use the 2010s de
| facto standard JS server stack -- Node, Express, Webpack
| etc. -- but don't necessarily have the time or
| inclination to keep up to date with every new project in
| this space. It's a lot to follow.
|
| 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.
| pier25 wrote:
| Vite is a project with 25M weekly NPM downloads and used
| by some 9M github repos. It's not an obscure project by
| any stretch of the imagination. Heck it's almost as
| popular as React.
|
| 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...
| dev_l1x_be wrote:
| You are selecting the frontend crew and making claims
| based on that. Many of us are not frontend devs just want
| to wrap an API. At least I do.
| pier25 wrote:
| > _Many of us are not frontend devs_
|
| That's fine but OP's template is clearly for devs with
| frontend skills. No?
| zaphirplane wrote:
| Heard not an expert in, parent is right
| johnhamlin wrote:
| I had the same reaction to Hono, but now see it has 23k+
| stars on GitHub. Learn about a new JS framework everyday!
| mathgeek wrote:
| As to whether or not this is a good thing is left as an
| exercise to the reader. ;)
| Philpax wrote:
| Agreed - I have no idea what this stack is good for, or how it
| competes against other full-stack efforts. Would love to know
| more!
| easygenes wrote:
| bhvr is the opposite end of the spectrum from the Big Three:
| Next/Rails/Django hand you batteries, bhvr hands you a rocket
| fuel can. One Bun binary replaces npm + Node + Jest, Hono
| routes run everywhere from Cloudflare Workers to bare-metal
| Bun, and a shared types/ folder gives you end-to-end TS
| safety--zero extra runtime, zero config. You lose turnkey
| SSR, auth, and ORM magic, but if you care more about
| installing, hot-reloading, and deploying in under 60 seconds
| than about convention-heavy kitchensinks, bhvr is the leanest
| full-stack starter in 2025.
| popalchemist wrote:
| Why not throw in support for BetterAuth and Drizzle/Prisma
| behind a feature flag, then you'd have a comparable
| offering, and not weigh down anyone who doesn't want them?
| gknoy wrote:
| Thank you for painting it that way. As someone who has
| normally done back end stuff in Django, having the ORM
| magic is so deeply ingrained for me. I was about to ask
| what one should use for an ORM, but looking at the Hono
| examples is pretty helpful. It looks Prisma is one good
| example of what I was looking for :D
| hombre_fatal wrote:
| Koa was next gen Express when TJ Hollowaychuk made it. Used
| first class promises to have real middleware like "response =
| await next()"
|
| 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.
| josephg wrote:
| In what way is Hono better than Koa? Any package can have
| zero dependencies if you just inline / bundle them in your
| package.
| Wazako wrote:
| It was designed by cloduflare for serverless use. There's
| no dependency on node, as cloudflare is based on web
| standards, so it was designed around warper for browser-
| native js modules (Request, crypto, ... hence the low
| dependency), which is why it integrates well with bun and
| deno.
| hombre_fatal wrote:
| Trivial dependencies _should_ be inlined. Consider leftPad
| or isEven.
|
| Or these Koa deps:
|
| - https://github.com/isaacs/inherits/blob/main/inherits.js
|
| - https://github.com/component/toidentifier/blob/master/ind
| ex....
|
| 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.
| liveafterlove wrote:
| Hono is pretty good js a runtime agnostic router. On their
| site:
|
| Works on Cloudflare, Fastly, Deno, Bun, AWS, or Node.js. The
| same code runs on all platforms.
|
| https://hono.dev
|
| How does compare to ultrajs? Or just use hono client side jsx,
| its pretty much like react already.
| DrStartup wrote:
| Not a dev, but I know what these are. Maybe the post was meant
| for people that know. Bun / deno new nodejs. Hono new koa new
| express. Vite new webpack. React still React but most popular.
| flashblaze wrote:
| Using Hono RPC would immensely help this. I'm using a similar
| kind of setup for my upcoming micro SaaS and the API integration
| has been a breeze
|
| https://hono.dev/docs/guides/rpc
| stevedsimkins wrote:
| Thanks for the rec! Definitely gonna check this out
| easygenes wrote:
| For about a year Hono has had mature RPC. So bhvr has a type-
| safe RPC story without tRPC: export your AppType, import it
| in the browser, and hono/client gives you fully-inferred
| calls plus Zod-backed validation -- in a ~3 kB helper instead
| of tRPC's heavier client and adapters.
|
| 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.
| krashidov wrote:
| Hmm do you know how it compares to https://trpc.io/ ?
| flashblaze wrote:
| I haven't worked with trpc, but looking at the docs
| everything looks to be pretty tightly coupled together In
| Hono RPC, you just have to replace the fetch api call with
| the RPC client and you're good to go
| erikpukinskis wrote:
| Cool!
|
| Why do you need both Bun and Vite?
| Etheryte wrote:
| Bun is a runtime, Vite is a build tool. You can mentally swap
| them out for Node and Webpack to answer your question.
| davidmurdoch wrote:
| Isn't Bun also a build tool?
| _heimdall wrote:
| Yeah bun has a build command and handles at least most of
| what vite does (bundling, code splitting, asset imports,
| etc).
|
| I'm also curious why you'd need vite with bun, maybe there
| are some features in vite that bun is missing?
| sroussey wrote:
| Bun is working to be a Vite replacement for many use
| cases, but that aspect is under heavy development right
| now.
|
| If "bun index.html" works for you right now, then great!
| Otherwise you may need to go to vite for a while yet.
| ToJans wrote:
| We're currently in a rewrite with the exact stack this
| starter pack has.
|
| 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...
| stevedsimkins wrote:
| Thanks!!
|
| 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!
| timeon wrote:
| JS/TS stack still seems bit complicated.
| rohan_ wrote:
| Nice- why hono over Fastify?
| pezo1919 wrote:
| Interested in that too.
| stevedsimkins wrote:
| Thanks!
|
| Fastify is great, I just like Hono more -\\_(tsu)_/-
| liveafterlove wrote:
| Runtime agnostic, why get stuck with one js runtime?
| TedMeftah wrote:
| Just a heads up, the repo description says "vice" instead of
| "vite"
| stevedsimkins wrote:
| Ty!!
| ramesh31 wrote:
| I think it's wonderful that there's a choice to use whatever
| package manager you like for your own personal work. But there is
| a special place for anyone who uses anything other than npm with
| a stable Node LTS for a professional project that will need to be
| maintained.
| alexgrover wrote:
| There are so many examples of large companies and open source
| projects that have moved off of npm that I just don't think
| this is true anymore. PNPM and bun are fast enough that the
| increase in development velocity is worth the occasional rough
| edge IMO.
| ramesh31 wrote:
| >PNPM and bun are fast enough that the increase in
| development velocity is worth the occasional rough edge IMO.
|
| 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.
| alexgrover wrote:
| Have you tried using them? Installing packages is way, way
| faster. Here's an example of how this is meaningful to an
| organization, and I've personally experienced the same
| exact thing at my last 2 jobs.
|
| 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.
| ramesh31 wrote:
| >"https://medium.com/@chaudharyaniket16/from-14-minutes-
| to-45-..."
|
| 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.
| chrisldgk wrote:
| Have you ever worked in a monorepo? With at least 5 apps
| and at least 5 packages, each with direct dependencies,
| devDependencies and testing libraries? The amount of
| packages you'll need to download for a full dev environment
| can get really big really quickly, even if your end-user
| bundle doesn't have many dependencies at all. I've worked
| on projects where an npm install took five minutes and a
| bun install took 10 seconds. In the real world this makes a
| big difference.
| chrisweekly wrote:
| That's... absurd. PNPM is superior to NPM, with no downsides.
| It's a fundamentally better tool.
| silverwind wrote:
| Well one downside is that it does not ship with node.
| pier25 wrote:
| Hono is great. It's a shame it all depends on a single maintainer
| and there's zero official funding afaik.
| koakuma-chan wrote:
| I never use templates because it's much faster to create a new
| project from scratch than use a template and remove all the
| unnecessary things.
| crsr wrote:
| Nice! I built something similar yesterday. But decided to use
| elysia instead. They have a tRPC like client with full TS support
| called eden.
|
| - eden: https://elysiajs.com/eden/overview.html
| ilrwbwrkhv wrote:
| Not very good. The type safety thing doesn't work well when you
| are using it across different folders.
| tough wrote:
| what do you mean by across different folders here? I was
| thinking about using elysiajs so this seems important
| tough wrote:
| would this hack help?
| https://stackoverflow.com/questions/79494287/is-it-
| possible-...
| ilrwbwrkhv wrote:
| I would reconsider using Elysia. I was also very excited by
| it and I thought it would be great but it has got errors
| and issues with different library versions and things like
| that. Also the whole Eden thing doesn't work for me for
| whatever reason. I have a monorepo. Typescript keeps
| complaining. Also if everything is defined in a single
| file, then it works well. If it's in different files, it
| breaks the whole type side of things.
| root_axis wrote:
| Huh? It works fine across different modules. It helps to read
| the documentation thoroughly. I don't mean that to sound
| snarky, but it's likely you missed something if you're not
| able to modularize your route types.
| tough wrote:
| would love to see it if open source!
| threatofrain wrote:
| Elysia is sooo underrated. IMO they could improve their
| marketing by emphasizing they're compatible with other
| environments and not just Bun.
| sharps_xp wrote:
| The main draw for me with elysia was that it maintains bun's
| perf benefits unlike express. When I got into the weeds of the
| documentation, their abstractions could use a lot of polish.
| The lifecycle of a request is not that clear imo and all the
| hooks you put into it look like hacks rather than integrations.
| slt2021 wrote:
| great work and very neat repo, love it!
|
| Do you have a plans to add the ORM?
| tough wrote:
| which one? Kysely? Drizzle?
| slt2021 wrote:
| I dont know enough about ORMs in JS world, but it feels like
| this template is missing the persistence/storage framework
| stevedsimkins wrote:
| Thank you!! No plans as of yet just to keep it open ended but
| we'll see.
| dev_l1x_be wrote:
| Is there a stack for loading html safely from the backend that
| has proper error handling? I would love to use HTMX but not sure
| how to do (for starting) error handling in it. I need to render
| some backend generated charts mostly, maybe adjust the time
| (datepicker). Is there something for this or just use vanilla?
| nnx wrote:
| Would it make sense to ReactRouter SSR though Hono?
|
| If not, great opportunity for bvrrr.
| stevedsimkins wrote:
| I prefer to do static hosting for my client, so bit of bias
| there. Not on the SSR hype train.
| bpiroman wrote:
| I really don't understand why typescript exists...
| pfg_ wrote:
| Without typescript, if you make a mistake in a type, it will
| throw an error at runtime when you try to use it. Then, you
| have to backtrack to find where it was created to find the bug.
|
| With typescript, there's an error squiggle in your editor under
| the bug before you even run your app.
| root_axis wrote:
| Why bother with Vite if you're using Bun? Also, Hono is nice but
| I personally I prefer Elysia in that ecosystem. Anyway, thanks
| for sharing!
| gorjusborg wrote:
| Why do you think a bundler offers no value when using Bun?
| root_axis wrote:
| https://bun.sh/docs/bundler
|
| 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.
| threatofrain wrote:
| Has anyone added Tanstack Router to this stack?
| isaachinman wrote:
| No idea, but shout out to Tanstack Router. It's fantastic.
| theusus wrote:
| Thanks, I really hate Remix and especially NextJS. But what about
| LTS? What is there are no updates after 6 months?
|
| Also, does this have SSR?
| swyx wrote:
| what's with the remix hate?
| ramon156 wrote:
| We're actually refactoring from Express+React to Remix (well,
| React Router) and this made me chuckle
| revskill wrote:
| Lol the docs is using svelte.
| stevedsimkins wrote:
| ?
|
| https://github.com/stevedylandev/bhvr-site
| revskill wrote:
| Lol sorry i missee steve for svelte
| jim-jim-jim wrote:
| Thanks for this, a few Qs though
|
| 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?
| insin wrote:
| Hono also has an official Vite devserver plugin if want an easy
| way to run a single integrated dev server locally for an API
| which also serves up your UI and has the hot reloading goodness
| you want.
|
| 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).
| molszanski wrote:
| Astro :heart: indeed.
|
| I think Astro is perfect fit for majority of projects.
|
| Ridiculously simple in use without all the next toil and issues
| DrStartup wrote:
| This is awesome! Why bun over deno? Curious your decision making
| process there. Making a similar but opposite decision there.
| xrd wrote:
| I really want this, but BHVS, where react is replaced with
| svelte.
| vlucas wrote:
| Alternatives are good, but there is almost no information on this
| site. I went to the site hoping to see things like what a route
| looks like, the syntax, how I might create a page or layout, how
| to make server only things vs. client only things, etc. None of
| that is on the page or GitHub README though. Not even one code
| example. Show people how this works!
| ramon156 wrote:
| I'd love a stack that was
|
| - 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
| johndevor wrote:
| Needs an example project IMHO.
___________________________________________________________________
(page generated 2025-04-28 23:02 UTC)