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.
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.
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.
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.
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.
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.
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”.
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.
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.
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.
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
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?
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).
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.
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.
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.
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
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.
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!
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?
You might want to have a look at Remix [0]. I haven't used it extensively myself, but it does claim to handle errors well.
> 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?
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.
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.
>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.
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.
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.
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.
the main benefit of hono seems to be you can deploy to cloudflare either as a pages app or workers. so this is kind of like a 'sveltekit for react'.
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
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.
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...
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!
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.
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.
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.
In what way is Hono better than Koa? Any package can have zero dependencies if you just inline / bundle them in your package.
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/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.
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.
[dead]
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.
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.
I had the same reaction to Hono, but now see it has 23k+ stars on GitHub. Learn about a new JS framework everyday!
As to whether or not this is a good thing is left as an exercise to the reader. ;)
I mean, I also don't know Bun and Vite. I've at least seen React. You should probably just explain the whole stack.
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.
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”.
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.
These two paragraphs would already be a much more helpful project description than “typesafe fullstack monorepo”.
If you've never heard of Bun or Vite you're clearly not the audience for this.
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.
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...
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.
> Many of us are not frontend devs
That's fine but OP's template is clearly for devs with frontend skills. No?
Heard not an expert in, parent is right
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.
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!
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.
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
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?
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).
Astro :heart: indeed.
I think Astro is perfect fit for majority of projects.
Ridiculously simple in use without all the next toil and issues
Hono is great. It's a shame it all depends on a single maintainer and there's zero official funding afaik.
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
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.
Elysia is sooo underrated. IMO they could improve their marketing by emphasizing they're compatible with other environments and not just Bun.
would love to see it if open source!
Not very good. The type safety thing doesn't work well when you are using it across different folders.
what do you mean by across different folders here? I was thinking about using elysiajs so this seems important
would this hack help? https://stackoverflow.com/questions/79494287/is-it-possible-...
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.
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.
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
Hmm do you know how it compares to https://trpc.io/ ?
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
Thanks for the rec! Definitely gonna check this out
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.
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.
[flagged]
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!
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?
You might want to have a look at Remix [0]. I haven't used it extensively myself, but it does claim to handle errors well.
> 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?
[0] https://remix.run
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
I really want this, but BHVS, where react is replaced with svelte.
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?
what’s with the remix hate?
We're actually refactoring from Express+React to Remix (well, React Router) and this made me chuckle
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.
That's... absurd. PNPM is superior to NPM, with no downsides. It's a fundamentally better tool.
Well one downside is that it does not ship with node.
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.
>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.
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.
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.
>"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.
the main benefit of hono seems to be you can deploy to cloudflare either as a pages app or workers. so this is kind of like a 'sveltekit for react'.
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
Just a heads up, the repo description says "vice" instead of "vite"
Ty!!
Nice- why hono over Fastify?
Runtime agnostic, why get stuck with one js runtime?
Interested in that too.
Thanks!
Fastify is great, I just like Hono more ¯\_(ツ)_/¯
Would it make sense to ReactRouter SSR though Hono?
If not, great opportunity for bvrrr.
I prefer to do static hosting for my client, so bit of bias there. Not on the SSR hype train.
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!
Why do you think a bundler offers no value when using Bun?
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.
This is awesome! Why bun over deno? Curious your decision making process there. Making a similar but opposite decision there.
Has anyone added Tanstack Router to this stack?
No idea, but shout out to Tanstack Router. It's fantastic.
Love the name!
Thank you!!
Cool!
Why do you need both Bun and Vite?
Bun is a runtime, Vite is a build tool. You can mentally swap them out for Node and Webpack to answer your question.
Isn't Bun also a build tool?
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...
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?
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.
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!
JS/TS stack still seems bit complicated.
I just switched to hono.js. I like it.
Needs an example project IMHO.
great work and very neat repo, love it!
Do you have a plans to add the ORM?
Thank you!! No plans as of yet just to keep it open ended but we’ll see.
which one? Kysely? Drizzle?
I dont know enough about ORMs in JS world, but it feels like this template is missing the persistence/storage framework
Lol the docs is using svelte.
?
https://github.com/stevedylandev/bhvr-site
Lol sorry i missee steve for svelte
I really don't understand why typescript exists...
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.
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?