hono vs nitro / Javascript runtime

[aheissenberger]

What have been the reasons to use hono and not nitro?

Other frameworks (e.g. Angular / Analog, solid start / vinxi) use nitro which helped them to reduce the effort to implement deployment adapters for each target platform and offers other features as a file system router, unstorage,... - see https://unjs.io

[dai-shi]

It's originally suggested by someone.
I don't investigate how nitro works, but do you think it will help a lot for Waku?
hono has adapters, but they are for edge functions, and we need serverless functions (in terms of Vercel). And, we support Node.js too.
We don't need a framework (which is what I see nitro), like Waku will have a filesystem router. It doesn't feel like nitro deployment adapters work for us like a magic. Correct me if I'm wrong.

In short, we want something minimal.

[dai-shi]

Just a note about the current design policy.
Originally I thought about tight integration with Hono and Vite, but I feel like they should be less coupled. Our hono integration is very thin, and even for Vite, we structure our code so that only some parts depend on Vite.

[jkhaui]

Just a note about the current design policy.

Originally I thought about tight integration with Hono and Vite, but I feel like they should be less coupled. Our hono integration is very thin, and even for Vite, we structure our code so that only some parts depend on Vite.

Hmm, if I'm understanding correctly, may I know the rationale for wanting minimal coupling to Vite?

I think Waku has big potential appeal to users wanting the latest react and RSC features but outside the next + webpack/turbopack ecosystem. These users will likely have had some prior exposure to Vite

However, the main trade-off I see is in this scenario is: coupling is beneficial if it improves overall cohesion of the framework.

What I mean is, by embracing some of Vite's opinionated conventions, all efforts with Waku can be devoted to developing the main featureset. With Vite providing a battle-tested foundation & guardrails, Waku can then develop its own adapter and integrations/plugin layer on top of Vite. And developers can also bring in "vanilla" Vite plugins they're used to working with from previous projects. But the framework is still minimal (IMO).

Astro executes this design really well. End-users usually never need to know they're using Vite, but power users are free to tap into familiar Vite features if they choose

[dai-shi]

I don't have any plan to avoid Vite, but the rationale is RSC isn't tied to Vite. And, our target includes non-Nodejs env, so production build is independent from Vite. It makes sense to me that the structure is to separate to Vite dependent part and independent part.

I guess Astro design should be close and there must be something I should learn.

End-users usually never need to know they're using Vite, but power users are free to tap into familiar Vite features if they choose

I like the idea pretty much.

[aretrace]

Stick with hono 😁. While I'm sure framework authors appreciate the ready made vinxi SDK, I already see a potential monoculture developing in the js (meta)framework ecosystem revolving around unjs/h3 due to vinxi. One of the big reasons some js devs use other (meta)frameworks is because of the dissatisfaction they have with a default (and usually only) http server implementation of some particular (meta)framework. Waku has a opportunity to really stand out here, and I believe hono is an excellent choice when looking for an express-like alternative. Hono has a more focused developer base (h3 is one of many unjs projects), is more popular (admittedly not the best deciding factor), and in my opinion is a better http framework (comparing their performance, api design, and availability of deployment targets).

[dai-shi]

Good to hear that.

[dai-shi]

https://github.com/nksaraf/vinxi
I'm having hard time reading the repo. Maybe, it's built with a different mental model from mine.

https://github.com/nksaraf/vinxi/tree/main/examples/react/rsc/spa
The example helped a bit. It explains, something like what you said, providing parts and users can build using all or some of them.
We plan to do something with #219 and further, which might be seeking similar use cases.

I'll dig it further when I get time.