Client-side Rendering (CSR)

[exastencil]

Since the Component API is designed to be isomorphic, we can compile components, ship them to the browser and replicate the work the server does there. This allows state changes and navigation not to need a round trip.

This is one of the core features needed to make Porous feasible.

In fact some interaction cannot be done without some form of reactive rendering without some sophisticated calls to the server and patching the document with the response (a la Turbo, Live View, htmx, etc).

There's a narrow window between CSS interactivity (animations, hover states, resizing, etc) and full page re-renders where arguably most applications live. Most of these cases can be filled with custom Web Components or a similar solution, but I feel the simplest way is to have declarative markup and render it reactively, so there is less ceremony on where the functionality lies: in the page, in a component or in a component in a component – it shouldn't really matter.

The challenge here is the heaviness that any solution brings. Good solutions (in my opinion) are things like Bud, which has a Go router with some JavaScript frontend framework for views. However, this requires constant language context switching (potentially between differently-typed languages), two language runtimes in development and data plumbing between the router and views.

So in our case we either turn the Ruby into JavaScript to run in the browser (the Opal route) or ship a Ruby runtime (as WebAssembly) and run the Ruby itself in the browser. Transpilation to JavaScript produces more assets to ship and interpret, but loading a Ruby runtime adds a lot of initial overhead on each page load. Both introduce complexities for reloading code in development, but the runtime approach will probably deal with module reloading better.