3 ms·
The way I do it in my framework [1]: 1. Wire up a route in your index.server.js file (the main app startup file). That calls to a res.render() function that re
by rglover 2y ago
The way I do it in my framework [1]:
1. Wire up a route in your index.server.js file (the main app startup file). That calls to a res.render() function that receives the component you want to render.
2. When that route is hit, send the HTML/CSS/JS to the client and auto-hydrate in the browser (no need for developer to hand-write that), let the client-side do the rest.
Rinse and repeat for moving between routes. No client-side slop, just one easy to understand source of truth on the server.
There's (sadly) been a chase in the JS world to cram everything into the browser but you really don't need to. The above is insanely productive and stable, yet a lot of people I talk to about it poo-poo it (or at best, seem disinterested).
[1] https://cheatcode.co/joystick https://cheatcode.co/joystick
- Scarbutt 2y agoThe issue with that approach to hydration is that it causes the browser to freeze.
- codethief 2y agoI'd say that depends on the complexity of the page but yeah, it is a real possibility. What tools like Astro (and also the recent Vue 3.5) provide here is an escape hatch in the form of opportunistic/lazy hydration and rendering. Just yesterday I shaved 200ms off of my hydration time by converting a Vue component to an async component that gets hydrated upon interaction.
- rglover 2y agoI've yet to see it with a wide range of sites. If you're getting browser freeze, something is wrong with your actual JS, not the framework. In the case of Joystick, because it's sending SSR'd HTML to the browser automatically, you typically don't even see the hydration take place.