4 ms·

I was using next.js when they switched from the pages router to app router. I ended up just abandoning the project, the app router experience was that bad, and

I was using next.js when they switched from the pages router to app router. I ended up just abandoning the project, the app router experience was that bad, and haven't really been keen on picking up next.js since then. It's always seemed clear that Vercel has been, at best, OSS-ish. Trying to play both sides of claiming to be open source but also (somewhat sneakily) building a walled garden to lock users into their hosting platform.

diggan 2y ago
> next.js when they switched from the pages router to app router It is react-router all over again. For those who weren't around, react-router appeared early in React's life, and lots of people were using it. But, for every major version they released, they completely changed the way of doing the routes/routing, so if you wanted to use a maintained release, you'd have to constantly refactor, often without any real gains except "now we're on the latest version". I, just like parent with next.js, eventually stopped using it because it was too much. It's kind of weird to me how programmers (especially of libraries like that) aren't more careful about introducing breaking changes, since the work needed to be done afterwards multiplies really quickly. I'd wish people just split their new stuff into new libraries instead of changing the interface of existing ones.
- ramesh31 2y ago
  >It's kind of weird to me how programmers (especially of libraries like that) aren't more careful about introducing breaking changes, since the work needed to be done afterwards multiplies really quickly. Programmers, generally, always aim to do that. But the JS framework world for whatever reason has this constant obsession with reinvention. I honestly think it stems from a sort of inferiority complex that FE devs had in the the 2000s/10s which led to every single library feeling the need to invent new words to describe some CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart. So stores became "reducers", promises became "thunks", and macros became "runes", and lots of FEs got to high five themselves and add that stuff to their FAANG promotion packets while we wallowed in their mountains of meaningless abstractions in the name of "doing things The Right Way" like FB and Google.
  - diggan 2y ago
    > Programmers, generally, always aim to do that Based on the amount of churn almost everywhere, I disagree with it seems like most are trying to aim to do that. I've been hit by similar issues (across multiple versions) in Python, Rust, Ruby, Go and bunch of other languages too. But then I'm comparing other ecosystems to Clojure which actually aims for interface stability, so maybe an unfair comparison.
  - jakubmazanec 2y ago
    > obsession with reinvention That seems like a comment made with an outsider perspective. Various front-end libraries keep changing APIs simply because the web and related technologies keep constantly evolving. When was the speed of change fastest and why? During 2010s, because usage of web/apps for everything exploded and browsers started to add features that designers and developer needed. If your CSS/UI library doesn't support for example CSS grid, you do what - not upgrade it and won't use modern grid at all? That's just a silly attitude. > CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart That maybe true, but 1) not only FE developers do that, 2) it's orthogonal to the actual reason I stated above.
  - kod 2y ago
    to be fair, "thunk" is decades old https://en.wikipedia.org/wiki/Thunk https://en.wikipedia.org/wiki/Thunk
  - martinsnow 2y ago
    No. These terms are not uniquely new.
- tmpz22 2y ago
  React-router can still cause weird build issues to this day, particularly with LLM generated code that cannot understand version compatibilities.
  - nonethewiser 2y ago
    An emergent benefit of stability
  - amrocha 2y ago
    If you try to build incompatible code and it doesn’t work, that’s not a bug
    - tmpz22 2y ago
      I'd argue there are too many incompatibilities between minor and major version changes between the "core" react libraries (DOM, react-router, etc) and those teams were a bit reckless with the API surfaces and how they fit together. At the end of the day it's free software and it's not like I've been submitting PRs to improve it. Further react-router is something you can setup at the beginning of a project and largely never touch again. Its not the end of the world, but it does cut a lot of folks who are new to React, Frontend, etc., and contributes meaningful costs to frontend development as a whole.
      - amrocha 2y ago
        I’d argue you should read the docs and write code that works and you wouldn’t have any problems
- debacle 2y ago
  I disagree with this a little bit. Yes, a lot of the react-router changes are a PITA especially since some of the breaking changes are non-obvious. But most of the changes have been syntactical, and seemingly logical. A bigger gripe with react is that everything is so interdependent that things like react-dom and react-router might as well just be part of react - if you update one, you need to update the other anyway.
  - nonethewiser 2y ago
    > Yes, a lot of the react-router changes are a PITA especially since some of the breaking changes are non-obvious. But most of the changes have been syntactical, and seemingly logical. "Syntactical" seems to reinforce his point, no? As opposed to functional.
    - debacle 2y ago
      The intent I think is "Lets refactor the syntax of the router so we can add more functionality without creating a boondoggle." At least from what I have seen.
- lelandfe 2y ago
  I love that the "new" way to use React Router just says "Most projects start with a template"... and then gives no installation instructions for adding it to an existing project beyond looking at an already configured one: https://reactrouter.com/start/framework/installation https://reactrouter.com/start/framework/installation
- Noumenon72 2y ago
  I was kind of offended by this with React Router version 6.4 and again when I saw the library/framework split with version 7, but without having time to switch I've found that the things like loaders and fetchers and useMatches and BrowserRouters are just what I should be doing, ergonomic and useful. Adjusting to them is moving my app forward.
matt-p 2y ago
To this day I still use pages only. Long term or for a new project I guess I'll have to look into astro or vite/express
- derkoe 2y ago
  I guess Tanstack Start is also a very good alternative to check out https://tanstack.com/start/latest https://tanstack.com/start/latest
  - matt-p 2y ago
    Looks like a pretty good option thank you
- floydnoel 2y ago
  i use Vite and built my own router. Works great and i can do a whole SPA with just that.
  - matt-p 2y ago
    Me too, but it's actually really nice ergonomics to have the backend in the same 'codebase' for small projects. Of course this can all be done manually, but the last thing I want to be doing when starting a three day project is spending the first morning/day doing boilerplate stuff.
buffalobuffalo 2y ago
I think the fundamental problem is that next.js is trying to do two things at once. It wants to a) Be fast to load for content that is sensitive to load speeds (SEO content, landing pages, social media sharable content, etc). It also wants to support complex client side logic (single page app, navigation, state store, etc). Doing those two things at the same time is really hard. It is also, in my experience, completely unnecessary. Use minimal html/css with server side rendering (and maybe a CDN/edge computing) for stuff that needs to load fast. Use react/vue/whatever heavy framework for stuff that needs complex functionality. If you keep them separate, it's all very easy. If you combine them, it becomes really difficult to reason about.
- tyleo 2y ago
  This is my approach. My website tyleo.com is just a bunch of CSS/HTML classic webpage stuff. If a page needs a small amount of JS I just bundle it ad-hoc. More complex pages get the full React/SPA treatment but it doesn’t mean the whole website needs to be that way. As an aside, I reuse code by using React as the template engine for HTML. Each page essentially has a toggle whether to ship it in dynamic mode or static mode which includes the full JS bundles or nothing.
- braebo 2y ago
  Sveltekit excels at this out of the box. And it’s simpler/easier than vanilla, let alone anything React-based.
deleted 2y ago
[deleted]
lenkite 2y ago
If you are using next.js, you are not really introducing a library/framework as a dependency - you have technically introduced a consultancy corporation as a dependency in your product.
- tealpod 2y ago
  Very well said.
- rco8786 2y ago
  This is an excellent way to frame it
- deleted 2y ago
  [deleted]
recroad 2y ago
Why is app router so bad?
- lioeters 2y ago
  Seemingly bad effort-to-reward ratio. I still have several large projects on previous versions of Next.js, and I'm not motivated (financially or otherwise) to spend the effort upgrading them for no reason other than to keep up with the newest version. One project I did upgrade, I had a hell of a time solving weird compiler errors, and the compile time degraded noticeably for some reason.

diggan 2y ago

> next.js when they switched from the pages router to app router It is react-router all over again. For those who weren't around, react-router appeared early in React's life, and lots of people were using it. But, for every major version they released, they completely changed the way of doing the routes/routing, so if you wanted to use a maintained release, you'd have to constantly refactor, often without any real gains except "now we're on the latest version". I, just like parent with next.js, eventually stopped using it because it was too much. It's kind of weird to me how programmers (especially of libraries like that) aren't more careful about introducing breaking changes, since the work needed to be done afterwards multiplies really quickly. I'd wish people just split their new stuff into new libraries instead of changing the interface of existing ones.

ramesh31 2y ago
>It's kind of weird to me how programmers (especially of libraries like that) aren't more careful about introducing breaking changes, since the work needed to be done afterwards multiplies really quickly. Programmers, generally, always aim to do that. But the JS framework world for whatever reason has this constant obsession with reinvention. I honestly think it stems from a sort of inferiority complex that FE devs had in the the 2000s/10s which led to every single library feeling the need to invent new words to describe some CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart. So stores became "reducers", promises became "thunks", and macros became "runes", and lots of FEs got to high five themselves and add that stuff to their FAANG promotion packets while we wallowed in their mountains of meaningless abstractions in the name of "doing things The Right Way" like FB and Google.
- diggan 2y ago
  > Programmers, generally, always aim to do that Based on the amount of churn almost everywhere, I disagree with it seems like most are trying to aim to do that. I've been hit by similar issues (across multiple versions) in Python, Rust, Ruby, Go and bunch of other languages too. But then I'm comparing other ecosystems to Clojure which actually aims for interface stability, so maybe an unfair comparison.
- jakubmazanec 2y ago
  > obsession with reinvention That seems like a comment made with an outsider perspective. Various front-end libraries keep changing APIs simply because the web and related technologies keep constantly evolving. When was the speed of change fastest and why? During 2010s, because usage of web/apps for everything exploded and browsers started to add features that designers and developer needed. If your CSS/UI library doesn't support for example CSS grid, you do what - not upgrade it and won't use modern grid at all? That's just a silly attitude. > CS concept that has been around for 40 years, and to massively overcomplicate things for the sake of sounding smart That maybe true, but 1) not only FE developers do that, 2) it's orthogonal to the actual reason I stated above.
- kod 2y ago
  to be fair, "thunk" is decades old https://en.wikipedia.org/wiki/Thunk https://en.wikipedia.org/wiki/Thunk
- martinsnow 2y ago
  No. These terms are not uniquely new.
tmpz22 2y ago
React-router can still cause weird build issues to this day, particularly with LLM generated code that cannot understand version compatibilities.
- nonethewiser 2y ago
  An emergent benefit of stability
- amrocha 2y ago
  If you try to build incompatible code and it doesn’t work, that’s not a bug
  - tmpz22 2y ago
    I'd argue there are too many incompatibilities between minor and major version changes between the "core" react libraries (DOM, react-router, etc) and those teams were a bit reckless with the API surfaces and how they fit together. At the end of the day it's free software and it's not like I've been submitting PRs to improve it. Further react-router is something you can setup at the beginning of a project and largely never touch again. Its not the end of the world, but it does cut a lot of folks who are new to React, Frontend, etc., and contributes meaningful costs to frontend development as a whole.
    - amrocha 2y ago
      I’d argue you should read the docs and write code that works and you wouldn’t have any problems
debacle 2y ago
I disagree with this a little bit. Yes, a lot of the react-router changes are a PITA especially since some of the breaking changes are non-obvious. But most of the changes have been syntactical, and seemingly logical. A bigger gripe with react is that everything is so interdependent that things like react-dom and react-router might as well just be part of react - if you update one, you need to update the other anyway.
- nonethewiser 2y ago
  > Yes, a lot of the react-router changes are a PITA especially since some of the breaking changes are non-obvious. But most of the changes have been syntactical, and seemingly logical. "Syntactical" seems to reinforce his point, no? As opposed to functional.
  - debacle 2y ago
    The intent I think is "Lets refactor the syntax of the router so we can add more functionality without creating a boondoggle." At least from what I have seen.
lelandfe 2y ago
I love that the "new" way to use React Router just says "Most projects start with a template"... and then gives no installation instructions for adding it to an existing project beyond looking at an already configured one: https://reactrouter.com/start/framework/installation https://reactrouter.com/start/framework/installation
Noumenon72 2y ago
I was kind of offended by this with React Router version 6.4 and again when I saw the library/framework split with version 7, but without having time to switch I've found that the things like loaders and fetchers and useMatches and BrowserRouters are just what I should be doing, ergonomic and useful. Adjusting to them is moving my app forward.

matt-p 2y ago

To this day I still use pages only. Long term or for a new project I guess I'll have to look into astro or vite/express

derkoe 2y ago
I guess Tanstack Start is also a very good alternative to check out https://tanstack.com/start/latest https://tanstack.com/start/latest
- matt-p 2y ago
  Looks like a pretty good option thank you
floydnoel 2y ago
i use Vite and built my own router. Works great and i can do a whole SPA with just that.
- matt-p 2y ago
  Me too, but it's actually really nice ergonomics to have the backend in the same 'codebase' for small projects. Of course this can all be done manually, but the last thing I want to be doing when starting a three day project is spending the first morning/day doing boilerplate stuff.

buffalobuffalo 2y ago

I think the fundamental problem is that next.js is trying to do two things at once. It wants to a) Be fast to load for content that is sensitive to load speeds (SEO content, landing pages, social media sharable content, etc). It also wants to support complex client side logic (single page app, navigation, state store, etc). Doing those two things at the same time is really hard. It is also, in my experience, completely unnecessary. Use minimal html/css with server side rendering (and maybe a CDN/edge computing) for stuff that needs to load fast. Use react/vue/whatever heavy framework for stuff that needs complex functionality. If you keep them separate, it's all very easy. If you combine them, it becomes really difficult to reason about.

tyleo 2y ago
This is my approach. My website tyleo.com is just a bunch of CSS/HTML classic webpage stuff. If a page needs a small amount of JS I just bundle it ad-hoc. More complex pages get the full React/SPA treatment but it doesn’t mean the whole website needs to be that way. As an aside, I reuse code by using React as the template engine for HTML. Each page essentially has a toggle whether to ship it in dynamic mode or static mode which includes the full JS bundles or nothing.
braebo 2y ago
Sveltekit excels at this out of the box. And it’s simpler/easier than vanilla, let alone anything React-based.

deleted 2y ago

[deleted]

lenkite 2y ago

If you are using next.js, you are not really introducing a library/framework as a dependency - you have technically introduced a consultancy corporation as a dependency in your product.

tealpod 2y ago
Very well said.
rco8786 2y ago
This is an excellent way to frame it
deleted 2y ago
[deleted]

recroad 2y ago

Why is app router so bad?

lioeters 2y ago
Seemingly bad effort-to-reward ratio. I still have several large projects on previous versions of Next.js, and I'm not motivated (financially or otherwise) to spend the effort upgrading them for no reason other than to keep up with the newest version. One project I did upgrade, I had a hell of a time solving weird compiler errors, and the compile time degraded noticeably for some reason.