4 ms·

Honestly I came back to frontend after a few years away and then recently got on next.js project. It seems like this has become the way to build SPA application

Honestly I came back to frontend after a few years away and then recently got on next.js project. It seems like this has become the way to build SPA applications ? It feels like a major step backwards - the huge complexity of having frontend split between server/client for very questionable benefits feels entirely not worth it to me. There has to be simpler ways to prerender some basic entry points and leave the rest to frontend. Or just do SSR with partial updates. Don't know maybe I'm getting too old but I see no world in which next.js is the optimal solution or frankly even an improvement over what was going on in frontend a few years ago - feels like a regression.

brailsafe 2y ago
Nuxt.js felt pretty straightforward to me, with a few minor hiccups. Haven't revisited Next in a while, but it seemed a bit overblown at the time and now. I think people just glob on to whatever their influencer of choice is doing much of the time.
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 ago
  The issue with that approach to hydration is that it causes the browser to freeze.
  - codethief 2y ago
    I'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 ago
    I'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.

brailsafe 2y ago

Nuxt.js felt pretty straightforward to me, with a few minor hiccups. Haven't revisited Next in a while, but it seemed a bit overblown at the time and now. I think people just glob on to whatever their influencer of choice is doing much of the time.

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 ago
The issue with that approach to hydration is that it causes the browser to freeze.
- codethief 2y ago
  I'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 ago
  I'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.