3 ms·
It should all be down the applications need for client side interactions. Even with hotwire/turboframes, phoenix liveview or other websocket / real time server
by no_wizard 4y ago
It should all be down the applications need for client side interactions. Even with hotwire/turboframes, phoenix liveview or other websocket / real time server driven update patterns, it can be suboptimal for many catagories of applications as these rely on (albeit smart) whole replacement of DOM nodes. In heavy applications, or applications that have a lot of represented state, its not the panacea it might seem at first glance.
I always tell people, "mileage may vary, there's no silver bullets in this industry". I think it holds true especially when talking about stuff like this.
- helloguillecl 4y agoOne thing is to have JS for client-side interactivity, and another thing is to generate the entire HTML using javascript by sending both the data and javascript bundles to the client.
- no_wizard 4y agoIncremental rehydration techniques make this much much less of an issue (React 18 supports this now, IIRC, for instance). The tl;dr is that if you employ SSG or SSR you won't endup up with immediate re-hydrating once the client loads up, but only when something triggers the need for re-hydration, like a button click. That to me seems like the sweet spot for highly interactive applications that are very stateful, however like I said previously, your mileage may vary.