Expose as middleware

[dai-shi]

Currently, it has its own server based on nodejs.
It would be more flexible to expose the functionality as connect/express middleware, so that it can be used in an existing express server.

Learn from https://github.com/brillout/vite-plugin-ssr by @brillout.

[brillout]

FYI vite-plugin-ssr's V1 design has been released last week.

Depending on what the goal of Wakuwork is, implementing Wakuwork as a Vike extension could make sense.

[dai-shi]

It might make sense with simple Wakuwork usage, but with router, it may conflict with Vike's router. I'll keep this in mind and will see how it fits.

[dai-shi]

implementing Wakuwork as a Vike extension could make sense.

I don't completely give up that road. Especially because I'm having a hard time around supporting styles, it may make sense to off load the task. I wonder if Vike supports customizing/replacing the router.

[brillout]

I wonder if Vike supports customizing/replacing the router.

What's your rationale for replacing Vike's router? I understand that routing is often something people want to customize but I'm thinking that, once Vike provides a really good router, then people won't want to customize it anymore. Thus my question: what's your motivation for replacing the router?

To be clear, I'm not against making the router replaceable and there is actuallly already a hook for that: https://vite-plugin-ssr.com/onBeforeRoute. I'd just like us to go down that path only after we talk this through.

[dai-shi]

Waku's core doesn't comes with a router. It can be used without routers. On top of it, we could implement a router or different routers.
So, that's why I originally thought Vike's design doesn't fit with Waku's design. Waku is lower level, so to speak. (But, we may change our design depending on feedback. For now, I have a use case of mine to use Waku without routers, so that's how I designed it.)

To be clear, I'm not against making the router replaceable

That's interesting. There seems to be a hope.

[brillout]

I don't know where you come from, so it's difficult for me to understand what you want.

Why did you create Waku in the first place? From the perspective of the user, what makes Waku different than Next.js? I was assuming that Waku's goal is to have a deep integration of sate mangement into the framework, which is something that Vike (tentatively) enables.

[dai-shi]

Well, my motivation of developing this is to build a minimal setup for React Server Components.
RSCs require a bundler at least. But, they don't require a router, nor SSR, nor even a server.
Given the minimal setup, we explore others. I'm adding a reference router, and an opinionated SSR, and an express-based server. Then, I will explore integrations with client-side state management such as Jotai.

[brillout]

IMO the following separation of concerns is best:

1. An agnostic-frontend-framework (for example Vike)
   • With agnostic I mean that can be integrated with any UI Framework (React/Vue/...)
   • I believe this agnostic-frontend-framework needs to include the routing, otherwise you end up with a tool that is too low-level and that leaves too much work to the meta-framework. (CC @nksaraf.)
2. An integration between the agnostic-frontend-framework and RSC. (Like https://github.com/brillout/vike-react but for RSC.)

Honestly, anything else seems like building a frankenstein to me (the exception being to vertically integrate everything like Next.js does but that's not particularly collaborative). I'm happy to be shown wrong though 😉.

Also, if possible, a Vite RSC plugin that can work with Waku/Vike/Rakkas would be quite neat, which nksaraf was(/is?) working on.

[dai-shi]

I'd admit the SoC of Waku isn't very sophisticated at the moment. But, RSC is still young anyway and it may not fit with existing concepts. I will try my road in the meantime, but I feel like eventually the scope of Waku might need to be narrowed down and it would look for integrating with other frameworks or something else.

a Vite RSC plugin that can work with ...

Yes, that would be neat, because I'm not yet very familiar with Vite and it's not at the center of my interest.

[dai-shi]

Thanks for your insights! They are helpful.

[brillout]

Sounds good.

RSC is still young anyway and it may not fit with existing concepts

Yes some adaption will most likely be needed on Vike's side (maybe on Vite's side as well). I'll have more time to dig into this once I release Vike V1.

Thanks for your insights! They are helpful.

👍 If we can collaborate that'd be great. Let's not recreate another Next.js that is equally monopolistic.

[nksaraf]

Would like to throw my hat in the ring here with a new abstraction layer I created on top of vite and nitro. It's kind of parallel to vike intending to solve similar problems but using nitro as the server and adapter layer, vite's dev server and a router abstraction to bring things together

It's kind of a build your own framework layer no routing opinions but you tell it your routes and it know what to do with the css . In many ways it's all runtime configured. https://github.com/nksaraf/vinxi .

I built two RSC examples. One uses SSR one doesn't. It uses react-server-dom-vite plugin.

Examples:
RSC directory: https://github.com/nksaraf/vinxi/tree/main/examples/react/rsc
SSR: https://github.com/nksaraf/vinxi/tree/main/examples/react/rsc/ssr/app.js
SPA: https://github.com/nksaraf/vinxi/tree/main/examples/react/rsc/spa/app.js

Also have a bunch of SSR examples with wouter, tanstack router, react-router, etc: https://github.com/nksaraf/vinxi/tree/main/examples/react/ssr

Its bring your own router and routing config.. we just give you a way to hook into the bundler to get the CSS and manifest for your route files. I have to document things better but have really enjoyed developing against it. It allows me to build a SolidStart clone and NextJS clone all in user land.

[dai-shi]

It's kind of a build your own framework layer no routing opinions but you tell it your routes and it know what to do with the css

Super nice. Hmm, I feel like I might eventually need to reconsider my router abstraction. I'm sure it's not the best, and building on top of something might be better.

[brillout]

router abstraction

This may work indeed.

Also have a bunch of SSR examples with wouter, tanstack router, react-router, etc

Although, while that's great, I'm asking myself whether supporting all these will restrict Vinxi too much. I guess we'll see.

Anyways, neat project. Very much looking forward to seeing how Vinxi will unfold.

[nksaraf]

Vinxi is essentially a bundler and server runtime integration . Routers and client side apps are part of the puzzle. The idea is not have any inbuilt conventions for routing.. just a runtime to support the appropriate techniques. We already have version of nextjs app router and solid starts router in the same examples dir

[nksaraf]

I think the router runtime is a beast of its own and staying out of that zone has been very nice for the abstraction. It gives the router bundler powers and lets it do its job

[dai-shi]

The idea is not have any inbuilt conventions for routing.. just a runtime to support the appropriate techniques.

Not sure if you are aware of, but Waku is taking the same approach. And, that would be a major blocker if I were to build it on Vike.