Am I the only one thinking that going back full circle to server side rendering, but to a way more convoluted way of having it, is actually a regression rather than evolution technologically?
We had SSR since the times of Perl, PHP, Python, Ruby and even express. But in a way more straight forward way of doing it: here’s some HTML, with some db queries that takes data, puts it in said HTML and sends it to the browser. Today we have react components that can be executed both on the server and on the client, we need at least 2 servers - one for the frontend and one for the backend, we have to hydrate the components when we render them server side, but not when rendering them in the browser, etc. I feel like we’re inventing stuff just because we can and there’s a huge cohort of engineers who complicate their development experience just because.
You are not the only one thinking this. A couple of years ago I was working with some people who were using next.js.
For some feature they wanted, they explained to me how nextjs has this great "feature", which was "really exciting" and allowed all kinds of fancy stuff that I've been doing since about 2003. They were going to turn on next's server-side rendering.
My immediate reaction was to point out "congratulations, you've just reinvented PHP, only with a much much worse language and two extra servers".
A lot of these "solutions" use three servers, not the two you mention: you use one server you don't have any control over, e.g google static hosting, to host the "compiled" static stuff - then you have that point at a server running node and another copy of all your terrible javascript, and then finally a third server running some more sensible stack, which could easily and more cleanly do the job of the other two using tech that isn't trash.
It's called "progress", and people like you and me just need to get with the times, it seems.
It has been full circle indeed. React is great for front-end development but with the need for having some pre-rendering (e.g. SEO) it's understandable why server-side re-entered the picture. However, with Next it has been slower build times and various twists and turns (a lot of the same things PHP was always bashed for). That's why for SPA apps we now default to Vite + react-router for a 10x speed up in build times on the same hardware.
It’s primarily the react crowd specifically who have been off doing their own thing for many years at this point and never seem to look outside their ecosystem and are stuck in this bizarre infinite loop of just reinventing the wheel constantly, never really improving anything just chasing one new buzzword after another. It’s really unlike any other dev or engineering ecosystem I’ve ever seen in over 25 years.
Next.js claims to be a versatile React framework, yet it doesn’t support something as fundamental as dynamic routing in a single-page app. The issue was raised by one of their own developers—two years ago—and it's still unresolved. I genuinely don’t understand the hype. Everyone seems to be using Next.js, and the internet is flooded with tutorials like it’s the holy grail of React frameworks.
This was your contribution to that thread last month [0]. Now a month after that insightful contribution you're on HN posting editorialized titles trying to get sympathy? Given your behavior in that thread I'm just impressed at how well the Vercel folks handled your aggression.
Maybe it's time to take your own advice and try a different framework instead of wasting time trashing on one you don't like.
It seems someone hasn't been very thorough in their investigation.
Actually, this user has been posting in this thread for months - the earliest post I saw was in January. The user posted several times asking for updates as to whether this feature was planned or not, fairly politely it seems to me, and was totally ignored as far as I can see.
After repeatedly asking for updates and having no response whatsoever, it seems they became disillusioned. Which I think isn't unreasonable - it's my opinion that it's pretty rude for a maintainer to ignore reasonable questions put to them, and that it's quite reasonable to be offended when you are ignored in this way. You talk about "aggression", I say ignoring people is an act of aggression, and it seems to me that this user has simply responded in kind.
We could get into a discussion on whether a maintainer has any responsibility to respond to users asking questions, and then use that as a basis for deciding whether specific posts by this user were justified or not, but my point is that the picture you paint with your post is inaccurate and incomplete. At best.
Why not use something else then? I wrote my own router, when I outgrew that I wrote an extension to react router to do the extra thing I needed. Complaining about stuff never gets you far with software written by others.
Vercel must be good at marketing. They are also good at offering Next.js hosting. They sustain that notion of Next.js being a natural choice.
Next.js offers some nice things as SSR and bundle slicing so that the initial load is (theoretically) way faster. There are other tools which do that, too. I personally find TanStack a more compelling "batteries included" proposition, despite its terrifying function signatures sometimes.
I recently had to migrate a large project off of Next.js because of this issue. Have you tried TanStack Router? It is so many infinitely times better than Next.js for SPAs (and honestly most React use cases) that I can’t believe it’s not better known.
Did you miss the comment where they said, "We’re still planning to address this within the next few months."?
Just because your niche issue isn't resolved, it is kind of a jerk move to blast them on HN especially when they've recently replied saying the issue is on their radar.
In less popular open source projects this is what drives devs to abandon them.
Readit News
For some feature they wanted, they explained to me how nextjs has this great "feature", which was "really exciting" and allowed all kinds of fancy stuff that I've been doing since about 2003. They were going to turn on next's server-side rendering.
My immediate reaction was to point out "congratulations, you've just reinvented PHP, only with a much much worse language and two extra servers".
A lot of these "solutions" use three servers, not the two you mention: you use one server you don't have any control over, e.g google static hosting, to host the "compiled" static stuff - then you have that point at a server running node and another copy of all your terrible javascript, and then finally a third server running some more sensible stack, which could easily and more cleanly do the job of the other two using tech that isn't trash.
It's called "progress", and people like you and me just need to get with the times, it seems.
Dead Comment
Dead Comment
Maybe it's time to take your own advice and try a different framework instead of wasting time trashing on one you don't like.
[0] https://github.com/vercel/next.js/discussions/64660#discussi...
Actually, this user has been posting in this thread for months - the earliest post I saw was in January. The user posted several times asking for updates as to whether this feature was planned or not, fairly politely it seems to me, and was totally ignored as far as I can see.
After repeatedly asking for updates and having no response whatsoever, it seems they became disillusioned. Which I think isn't unreasonable - it's my opinion that it's pretty rude for a maintainer to ignore reasonable questions put to them, and that it's quite reasonable to be offended when you are ignored in this way. You talk about "aggression", I say ignoring people is an act of aggression, and it seems to me that this user has simply responded in kind.
We could get into a discussion on whether a maintainer has any responsibility to respond to users asking questions, and then use that as a basis for deciding whether specific posts by this user were justified or not, but my point is that the picture you paint with your post is inaccurate and incomplete. At best.
Next.js offers some nice things as SSR and bundle slicing so that the initial load is (theoretically) way faster. There are other tools which do that, too. I personally find TanStack a more compelling "batteries included" proposition, despite its terrifying function signatures sometimes.
https://tanstack.com/router
Just because your niche issue isn't resolved, it is kind of a jerk move to blast them on HN especially when they've recently replied saying the issue is on their radar.
In less popular open source projects this is what drives devs to abandon them.
It's fascinating to see people go nuclear over small issues and then take it public like everyone else should care.