4 ms·

Next.js: The "Versatile" React Framework That Can't Handle Dynamic Routes

17 points by batchfy 1y ago

new_user_final 1y ago
[dead]
batchfy 1y ago
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.
- fixprix 1y ago
  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.
  - nhinck2 1y ago
    I love when these threads pop up. It's fascinating to see people go nuclear over small issues and then take it public like everyone else should care.
- sebmellen 1y ago
  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. https://tanstack.com/router https://tanstack.com/router
- nine_k 1y ago
  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.
- lolinder 1y ago
  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. [0] https://github.com/vercel/next.js/discussions/64660#discussioncomment-13044166 https://github.com/vercel/next.js/discussions/64660#discussi...
  - antisol 1y ago
    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.
    - lolinder 1y ago
      No, I was very thorough: I saw every comment and pulled out the obscene, aggressive, offensive acrostic embedded in months of harassing tagging of the target of that acrostic because that recent pattern of behavior overshadows everything else. There's no excuse for that entry no matter how frustrated they get. Vercel owes them nothing—and the specific employee OP chose as a target owes them even less—and this entitled behavior is a long-standing plague on open source that needs to be called out and soundly condemned. If they need the feature so desperately they can add it themselves (Vercel already said it's something they want to implement!) or switch frameworks.
- jemmyw 1y ago
  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.
8927862980 1y ago
[flagged]
tudorconstantin 1y ago
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.
- antisol 1y ago
  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.
- genatron 1y ago
  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.

17 points by batchfy 1y ago

[dead]

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.

fixprix 1y ago
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.
- nhinck2 1y ago
  I love when these threads pop up. It's fascinating to see people go nuclear over small issues and then take it public like everyone else should care.
sebmellen 1y ago
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. https://tanstack.com/router https://tanstack.com/router
nine_k 1y ago
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.
lolinder 1y ago
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. [0] https://github.com/vercel/next.js/discussions/64660#discussioncomment-13044166 https://github.com/vercel/next.js/discussions/64660#discussi...
- antisol 1y ago
  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.
  - lolinder 1y ago
    No, I was very thorough: I saw every comment and pulled out the obscene, aggressive, offensive acrostic embedded in months of harassing tagging of the target of that acrostic because that recent pattern of behavior overshadows everything else. There's no excuse for that entry no matter how frustrated they get. Vercel owes them nothing—and the specific employee OP chose as a target owes them even less—and this entitled behavior is a long-standing plague on open source that needs to be called out and soundly condemned. If they need the feature so desperately they can add it themselves (Vercel already said it's something they want to implement!) or switch frameworks.
jemmyw 1y ago
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.

8927862980 1y ago

[flagged]

tudorconstantin 1y ago

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.

antisol 1y ago
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.
genatron 1y ago
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.