We also migrated away from Next.js last year to [Vike], big improvment on developer experience all around. Most of our needs are covered by just pre-rendering pages ([SSG])
[Vike]: https://vike.dev/ [SSG]: https://vike.dev/pre-rendering
You should know this before choosing Next.js
41–50 of 147 posts
Re: You should know this before choosing Next.js
#42I 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…
> 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 ga…
React-router can still cause weird build issues to this day, particularly with LLM generated code that cannot understand version compatibilities.
Re: You should know this before choosing Next.js
#43Well shoot. I just started a new Next.js project least week. What's everybody's go to alternative?
Re: You should know this before choosing Next.js
#44Re: You should know this before choosing Next.js
#45I'm currently in the process of picking the go-to React stack for the company I work for, and I cannot imagine why someone would pick Next.js over the alternatives. It seems like Next.js is just a Vercel product and something you'd want to move away from instead of in.
Remix (or React Router v7, it seems now, confusing) or even TanStack (if you feel adventurous with beta versions) seems like much more reasonable choices if you want SSR and such.
Re: You should know this before choosing Next.js
#46I 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…
> 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 ga…
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.
Re: You should know this before choosing Next.js
#47The single reason I switched from next.js was because it was taking me 6-7 seconds on a small project to see changes I made appear in the browser during development (on an M1 Max Macbook pro with 64gb of ram). This is when using the app router, where every change requires a compilation step. I now just use a React SPA with Vite.
Yeah, this is shocking to me. I’m a backend developer who occasionally tinkers with frontend. I gave nextjs a spin and couldn’t believe the reload times on a new project.
For folks who use this every day, how/why is this acceptable?
Re: You should know this before choosing Next.js
#48The single reason I switched from next.js was because it was taking me 6-7 seconds on a small project to see changes I made appear in the browser during development (on an M1 Max Macbook pro with 64gb of ram). This is when using the app router, where every change requires a compilation step. I now just use a React SPA with Vite.
what do you use for routing?
Re: You should know this before choosing Next.js
#49I've always been a little uneasy about Vercel after trying to self-host Next.js on a VPS and running into a few of the little traps they seem to have set to nudge you into hosting on their platform instead. I get they have to pay the bills somehow but it does feel a bit risky to bet on their goodwill long-term.
The way they've handled this vulnerability has made me even more uneasy.
Vercel's initial framing of their Firewall as having "proactively protect[ed]" their customers definitely leaves a bad taste.
This, plus the delay in notifying other platforms, reveals a conflict of interest I had not previously considered: is Vercel actually less motivated to prevent such vulnerabilities from being introduced to Next.js in the future because they can roll out mitigations on their own platform before public disclosure and then say "well you wouldn't have been affected if you used us for hosting :)"?
Re: You should know this before choosing Next.js
#50Earlier quoted context omitted.
> 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 ga…
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…
> 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.