Hybrid Routing

As mentioned in https://vite-plugin-ssr.com/SR-vs-CR Client Routing provides the best performance while Server Routing provides the simplest architecture.

An alternative is to:

1. Dynamically load the HTML of the next page. (No full page-reload: we use window.fetch() to load the HTML.)
2. Dissect that HTML in the browser-side
3. Inject the new HTML parts into the DOM

This is common practice outside the JS world, e.g. Ruby on Rails: https://github.com/hotwired/turbo.

The big benefit here is that we keep the simple architecture of Server Routing, while having fast page transitions similar to Client Routing.

Note that Client Routing is still needed for:

• Highest performance (e.g. for things like https://vite-plugin-ssr.com/onBeforeRender-isomorphic)
• Component states that need to be preserved upon page changes
• React Server Components

Server Routing is also still needed for zero browser-side JavaScript.

We could call this Hydrid Routing.

[brillout]

@ryansolid Thanks for the reply.

@redbar0n Thanks for the resources.

I think it’s too early to tell whether it makes sense: the ecosystem is evolving a lot (e.g. offscreen rendering and server components which both involve the routing process). It’s not clear where things will end up. Let’s wait and see how the dust settles.

For now, supporting Server Routing as well as Client Routing works out for the vast majority of users, if not all.

Closing in the meantime. We can re-open this if a need arises for it.

[redbar0n]

@brillout you should watch these sections from Ryan and Nikhil’s recent stream on Partial Hydration? + Hybrid Nested Routing (using the Islands Architecture). In a lot of ways it surpasses the Hotwire.dev Turbo + Stimulus approach.

• Pro:
  • Less kB over-the-wire (since Solid is smaller than Stimulus)
  • Preserves familiar JSX component tree (known from React and Solid).
• Con:
  • Islands architecture might introduce some sneaky cases with inter-component communication, and enforce some more discipline on developers.