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.
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.
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.
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.
> 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.
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
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.
>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.
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.
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.
I'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 :)"?
This reminds me of a bad vuln in Drupal years ago (2014, I think?).
Alot of people think Acquia, being started by the creator of Drupal, has special control of the open source project, but at the end of the day they really don't have that kind of control.
So when the security team found this vuln, they coordinated with as many Drupal hosting platforms as they could, and immediately Pantheon, Platform.sh, and Acquia had all blocked the exploit at the firewall level by the time the CVE was announced.
I warn everyone away from next.js. Unsurprisingly V0 has a real shot at massively increasing its adoption because people don’t know any better.
What are some salient counter points for choosing next.js? I see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect. If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase.
I've been building SPA apps for years with express and React. For a recent project we decided to use Next.js and self host. The biggest benefits have been
1) having the middleware contained in the same runtime and therefore not having to set up multiple projects and hosting for each. We just build a single docker image and put it in ECS.
2) having things like routing, bundling, linting, etc. already included. There are some downsides--like I would rather have biome out of the box than prettier/eslint, but most the developers haven't really cared.
There is a lot of magic and complexity under the covers that I haven't fully groked, and from that perspective I have reservations about it, especially after the recent CVE. As an example of the complexity, I had to set up Sentry, and while Sentry does have a package specifically for next.js, it was still tricky to ensure we were capturing errors with appropriate context in every possible spot.
It's possible as our project matures we'll hit some roadblocks that will make us question our decision to use next.js and self host, but overall our dev team has been productive with it.
>What are some salient counter points for choosing next.js? ... If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase.
Well there are alternatives to Next.js that handle SSR. Remix for example. That's a popular one.
For a smaller project I wouldnt be afraid of rolling your own with Vite. It's pretty simple.
And for any developer I'd really recommend implementing SSR yourself with an express server or whatever. It really increases your understanding of how frameworks work.
Remix unfortunately does not have (built-in) static export. Plus, the big rename that Remix is now "react-router" does not help their brand. Lot of people don't associate react-router with being a SSR framework.
> Maybe people should rediscover the joys of just FTPing files on a cheap host.
Trouble is that the reason we got away from that model because applications started to become so bloated by frameworks that it took ages to see them start up, thereby necessitating a bunch of hacks to see them respond in a reasonable amount of time, with that eventually evolving into services like Vercel that try to hide the hacks behind a "just upload it" service.
So, first, people would have to rediscover the joys of not creating monstrosities. But in an age when someone might consider Nextjs... Good luck with that.
Just having conventions around routing, and a "just works" build & lint is nice to avoid a team bikeshedding their own solutions. (Please don't suggest react-router... which seemingly reinvents itself every couple years).
API routes in same codebase that can use same TypeScript types instead of these typegen tools is really nice too.
I'm very much in the camp of not fiddling with build, routing, hydration, state, etc. as they end up being a distraction from just making the thing you set out to make.
As mentioned on another reply, it is favoured by many SaaS vendors as the only extension framework for their products.
Using something else, means not having support, and spending time yak shaving instead of coding the real solution.
From Java/.NET ecosystem point of view, Next.js is the framework where I feel at home.
I work with agencies that have partner agreements with Vercel/Netlify, which makes it a good option for SaaS products that are in the MACH architecture space.
There is such an exaggeration about the need/utility of SSR. Google is dead for new projects, if one is optimizing their stack based on the easiness for Google to crawl it, I think they are making a terrible architectural decision for no return. Deploying a React/JavaScript app is much easier without Next.JS.
The 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.
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?
It's acceptable for me because I (and others on my team) do not have to way 6-7 seconds almost ever, it is nearly instant. On odd occasion changes can take a long time to show up, ~5 seconds, but it seems restarting the server fixes it, so not sure what that is about.
> For folks who use this every day, how/why is this acceptable?
While I thankfully don't have to use Nextjs often, in general I am not sure I even launch my app in the browser every single day. Your tests and whatnot are already providing continuous feedback about the state of the code. 6-7 seconds every once in a while wouldn't be the end of the world.
But even it were instantaneous, Nextjs has a horrible developer experience for a multitude of other reasons.
I would have actually liked to have SSR in some cases but yes it was not critical for my app to have it. I just think Next.js (and react) jumped the shark so to speak with prioritizing SSR over client side rendering.
What most web-apps need is just a very basic SSR step for the shell of the app, not everything needs to be server side rendered, in the cases where that is required we've had other SSR first frameworks that already solve that problem.
Next.js' main offering is that you basically get SPA architecture but with a single browser<->server round trip on first load instead of two round trips.
That's where ~all of Next.js' complexity comes from, and it should definitely be appreciated for that because it's a hard problem.
But if you don't need that, I don't see why you'd use something so brittle, complicated, and experimental.
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])
I'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.
I’m mixed about Next.js. On one hand, it’s a company building a framework with investors, of course there are incentives for them to corner the market. Like the author mentions, Redis labs has a similar model. The license is MIT, so Netfify or anyone can fork and offer a better alternative, if they’re capable and willing to take on the risk of it flopping. Also, if I’m an investor in Vercel — why would I encourage them to put my investment at risk by aiding competition?
On the other hand, there does seem to be a sleight of hand with Vercel. They want it both ways — to be a company that champions and fosters open source while also keeping the necessary friction in place to make their hosting platform the best choice.
For better or worse, I think we’ll only see more of this model in the future.
I'm not really convinced the serverless approach is a good default. It adds a lot of complexity that you might not need at all. I'm also not a fan of Javascript on the backend, but that's really more of a personal preference. But it is quite common to have backends in different languages, so the focus on server components and Next.js in the React world felt a bit like some tunnel vision to me. It was focused on an entirely different use case than mine, which is of course perfectly fine as not all features need to target my use cases. But pushing a more narrow and specialized setup as the default does seem like the wrong choice to me.
And the serverless approach very likely was the reason they used HTTP headers for this kind of privileged communication between parts of the application. Which is a terrible idea for environments where you can't be sure those headers are never set by users.
Readit News
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.
Deleted Comment
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.
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.
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.
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.
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.
Deleted Comment
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.
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 :)"?
Alot of people think Acquia, being started by the creator of Drupal, has special control of the open source project, but at the end of the day they really don't have that kind of control.
So when the security team found this vuln, they coordinated with as many Drupal hosting platforms as they could, and immediately Pantheon, Platform.sh, and Acquia had all blocked the exploit at the firewall level by the time the CVE was announced.
What are some salient counter points for choosing next.js? I see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect. If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase.
Anything else?
There is a lot of magic and complexity under the covers that I haven't fully groked, and from that perspective I have reservations about it, especially after the recent CVE. As an example of the complexity, I had to set up Sentry, and while Sentry does have a package specifically for next.js, it was still tricky to ensure we were capturing errors with appropriate context in every possible spot.
It's possible as our project matures we'll hit some roadblocks that will make us question our decision to use next.js and self host, but overall our dev team has been productive with it.
Well there are alternatives to Next.js that handle SSR. Remix for example. That's a popular one.
For a smaller project I wouldnt be afraid of rolling your own with Vite. It's pretty simple.
And for any developer I'd really recommend implementing SSR yourself with an express server or whatever. It really increases your understanding of how frameworks work.
Maybe people should rediscover the joys of just FTPing files on a cheap host.
It's not like most project will have problems running on those hosts. And if it is the case scaling is one bare metal server + nginx away.
https://pgs.sh
Trouble is that the reason we got away from that model because applications started to become so bloated by frameworks that it took ages to see them start up, thereby necessitating a bunch of hacks to see them respond in a reasonable amount of time, with that eventually evolving into services like Vercel that try to hide the hacks behind a "just upload it" service.
So, first, people would have to rediscover the joys of not creating monstrosities. But in an age when someone might consider Nextjs... Good luck with that.
API routes in same codebase that can use same TypeScript types instead of these typegen tools is really nice too.
I'm very much in the camp of not fiddling with build, routing, hydration, state, etc. as they end up being a distraction from just making the thing you set out to make.
Using something else, means not having support, and spending time yak shaving instead of coding the real solution.
From Java/.NET ecosystem point of view, Next.js is the framework where I feel at home.
I work with agencies that have partner agreements with Vercel/Netlify, which makes it a good option for SaaS products that are in the MACH architecture space.
Deleted Comment
I now just use a React SPA with Vite.
For folks who use this every day, how/why is this acceptable?
While I thankfully don't have to use Nextjs often, in general I am not sure I even launch my app in the browser every single day. Your tests and whatnot are already providing continuous feedback about the state of the code. 6-7 seconds every once in a while wouldn't be the end of the world.
But even it were instantaneous, Nextjs has a horrible developer experience for a multitude of other reasons.
To be fair it sounds like you didnt need Next.js in the first place then? SPA is more of an alternative than an analog.
6-7s for HMR is terrible though. Agreed.
What most web-apps need is just a very basic SSR step for the shell of the app, not everything needs to be server side rendered, in the cases where that is required we've had other SSR first frameworks that already solve that problem.
That's where ~all of Next.js' complexity comes from, and it should definitely be appreciated for that because it's a hard problem.
But if you don't need that, I don't see why you'd use something so brittle, complicated, and experimental.
[Vike]: https://vike.dev/ [SSG]: https://vike.dev/pre-rendering
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.
On the other hand, there does seem to be a sleight of hand with Vercel. They want it both ways — to be a company that champions and fosters open source while also keeping the necessary friction in place to make their hosting platform the best choice.
For better or worse, I think we’ll only see more of this model in the future.
And the serverless approach very likely was the reason they used HTTP headers for this kind of privileged communication between parts of the application. Which is a terrible idea for environments where you can't be sure those headers are never set by users.