There is no need to manually set up your own Node.js SSR framework for React. Next.js exists, and is quite mature at this point. Next.js is quite fun. Highly recommend it.
The novel thing, for this, in my mind, is the edge hosting.
But just like all other frameworks, the cost isn't just getting it started, it's learning the framework, learning the ecosystem, and slowly building up your knowledge of the edge cases when you start moving past it's limits.
Next.js puts you squarely back in monolith server-side territory in that regard, it's just a different flavor. Of course it has it's upsides if you're doing a purely React application. But you've now got all the complexity of a server-side monolith and a frontend framework, with the added bonus complexity of components that have to switch between client and server-side contexts, then state management and hydration across that boundary as well.
Now people are going to say "Ha, idiot, you just simply..." but that's just part of the learning, so you're in no better place with Next.js/SSR in general unless you want to build an interactive application. This isn't against Next.js by the way, I did enjoy it when I needed it, it's just that there's no avoiding some of the inherent domain problems regardless of which framework you pick.
I wonder if this is why a keep reverting to PHP , most stuff I can build without frameworks or just the odd library because I know how.
Everytime I give myself some free project experiments (have a local PI for tinkering) I always feel it’s unnecessarily complicated or feeling that hill I have to climb, at which point I can dream the solution in PHP frontend JS/HTML.
I've passed over that learning hump, put some projects into production with React, NextJS, and Vue, and I still think PHP + native JS/HTML is the more pragmatic tooling choice. It's more simple, robust and easy to debug. I've been experiencing some other backend frameworks too, specifically Node and Ruby stacks, and the PHP ecosystem and language is ahead by a country mile.
I think if you want to pick a pragmatic toolkit to work with long term and kick the churn to the curb, PHP is a great choice for web applications and will continue to be for a long time thanks to it's diaspora.
PHP (or, in my case these days, Deno serving templates, typically nunjucks) that have https://htmx.org/ in them for interactivity gets you productive, quickly, for a lot of the tasks I need to do.
That said, React makes building even more interactive, complicated things simple, and is easy to hire for, so thats what we use at work.
I do think the world is still ripe for a PHP-like language. The template-style webserver-aware way of doing things, with modern features. Maybe one day.
Definitely my biggest concern working with nextjs so far is that the line between when something is will execute server side and when it will execute client side is a bit blurry until you test them. It's manageable but requires some trial and error IME.
That was problematic for me when I was testing it out. Can’t access the window object without excessive workarounds that I couldn’t make work with my project. I ended up reusing existing react components and move it to all browser rendered react and even that experience has me leaning toward moving it to Vue or dropping the framework altogether and grinding everything out in css again. That said, I did enjoy using styled components. I found that pattern pleasant to reason around.
Yep, I've been using Next.js for several years and it's mostly great. One thing that I found is that Next.js still suffers from configuration fatigue, this was especially true before the team moved from Webpack to SWC. I'm glad to see that the team is moving more in the direction of "configured by default", but you still inevitably need to fiddle with the dials if you want to use things outside of the documented tool integrations.
The novel thing, for this, in my mind, is the edge hosting.