▲ 284 points
back
137 comments
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.
> 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.
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
Why is app router so bad?
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.
Anything else?
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.
> I see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect.
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.
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.
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.
I now just use a React SPA with Vite.
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
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.
Not to mention the absolute worst dev build time that’s had an open PR with a lot of complaints for years and not addressed.
I do love a site that does it's own thing with design. We've become so lazy with Medium, it's nice to see someone having fun with their presentation.
Vercel and NextJS should not exist.
I tried next once, and I was met with a bunch of hydration errors in production. The concept is nice, but the framework just over complicates everything for some potential gain of rendering on the server, while in reality none of this is needed (just use traditional HTML rendering).
And I’m not even mentioning the fact that the entire framework was built as a nice facade to sell their overpriced cloud service because todays developers can’t write a CI/CD pipeline that rsyncs their code to a VPS and reloads whatever reverse proxy they use.
I still remember trying to host a Next.js web app myself (without netlify or vercel) and feeling so much PITA. The whole output was wonky and just didn't want to start right. I don't think it has gotten better considering the pull of Vercel
Stay away from anything that has to do with Vercel
Next.js is secretly a paid framework designed to be run on Vercel, masquerading as open source, and somehow they did it in a way where even the most popular YouTubers continue to shill for them as it being the "best" framework.
Funny how everything goes through a cycle of it's amazing, it's terrible, it's boring
I feel that open source is truly at its best when it’s done by enthusiasts/hobbyists and not necessarily by corporations. React and Nextjs always smelled a bit suspicious to me whereas Svelte and Vue did not.
There’s actually an old PG essay talking about Java where I feel a lot of what he says applies to Nextjs: https://www.paulgraham.com/javacover.html
I haven’t used recent versions but I remember trying to use it like 6 years ago on a project and trying to figure out how to display an SVG was ridiculous. The solution was a specific next-svg package… but that’s not a great experience to need to find Next-specific packages for common uses. We ended up going with CRA at the time, today I imagine we would’ve chose React/Vite but we also didn’t need any benefits of SSR for the project
I was always highly sceptical of vercel even though or maybe also because i really love the design and public appeal they are going for. But something about everything they do and talk about gives me the creeps, something is telling me that they are not genuine and keeping something. Its maybe the same feeling when you talk to a really pleasant to talk to person who you just know is a psychopath making the heir on your neck stand up.
This was probably at the strongest when they could not decide on the edge function strategy and made a handful of statements that made no sense or made partial sense but were very clearly not the full picture.
Buying rich harris while assuring this would have no impact on the level of sveltekit lock-in crossed a line for me to feel really anxious. So far i did not see anything concrete go bad with sveltekit but its hard to imagine a scenario where this would not happen. Lets hope rich can keep his integrity and awareness enough to walk away at the right time.
What is a good alternative, if I want to stick to React. Does any other framework support server/client hybrid rendering.
> With Next.js having such a sizeable share of the market, I would expect a lot more hosting options, which would foster competition and innovation across the board, ultimately benefitting users and the web.
Would it? Or would it turn Next.js hosting into a commodity with zero marginal profit, ulimately making it impossible to fund development?
It's because of articles like this that I can't understand those who say 'Just switch to Expo' when talking about React Native. The frontend should be a puzzle of solutions, not a monolith where a few companies sell the 'magic word' to get out of a problem.
If you wonder if you should justify your body text the answer usually is no, especially on the web.
As an architect who helps choose stack items, this article and thread screams very loudly not to use next.js.
Scrutinizing an oss maintainer is one of the first tasks I check off when researching tech stacks.
Even the slightest ethical concerns would exclude something from my decision making.
To add to this, in the last couple of releases Next.js got worse for static build exports (everything is compiled and exported to static html+js+assets and put into out/) - it seems it is not a priority anymore.
Their built-in image exporter (next/image) never had support for static export whatsoever (in contrast to gatsby). When I brought that up on HackerNews some time back, an employee of Vercel tried to argue against that and dial that down without disclosing he is actually an employee of Vercel [0].
Overall, sketchy company with sketchy business practices.
Next is a fantastic choice if you really have the problems that it solves well (SSR and backend proxying). If you don't, it's a huge bloated mess, and you should just stick with a traditional SPA.
Off-topic, but "Build Times" is a great name for a blog.
I just don’t understand takes like this at all. No tech scales without bottlenecks. Shopify built an empire on Rails, a framework frequently criticized for scalability issues, yet they thrived because they knew how to navigate its limitations. Great engineering teams turn bottlenecks into solved problems, not dealbreakers.
I am getting absolutely fed up with this type of condescending approach to those who dont drink the RSC or SSR kool-aid
I was under the impression that Next.js was the successor to React? Is that not the case?
I chose Next.js because it is the official framework fully supported by many SaaS vendors, due to partner agreements, and I don't feel like doing the support myself when using other framework.
Well shoot. I just started a new Next.js project least week. What's everybody's go to alternative?
Nice to see someone willing to stick their head above the trench wall. I worked on a "Vercel clone" for a year. After that experience I'd also warn friends to stay clear of Next.js. That said, we don't owe Vercel anything and if they want to ship a framework that's essentially a dongle for their service, they're perfectly entitled to do that.
> The official methods for self-hosting Next.js require running the application in a stateful way, as long-running servers. While technically possible, this is very hard to operate in any real-world production environment where a single instance isn’t sufficient.
Come on, this is a patently false statement.
There's nothing inherently stateful about Next.js deployment, and self-hosting is both thoroughly documented and straightforward: https://nextjs.org/docs/pages/building-your-application/depl...
If you've worked with any modern deployment pipeline, you'd know self-hosting Next.js is no more complex than any other React application. You build it, you deploy it, you scale it with standard practices.
For many teams with existing infrastructure, self-hosting is actually simpler than migrating to a platform like Vercel. This kind of misinformation reads like someone who either hasn't actually tried self-hosting or has some agenda against the approach.
> The setup needs to be able to dynamically scale up very quickly in order to handle sudden bursts of traffic, while at the same time being able to scale down to zero in order to be cost-effective.
This is obviously a non-issue with the vast majority of deployed apps as a even a single nextjs instance will be able to trivially handle thousands of requests per second.
Stay away from both Vercel and Netlify.
Both are hype technology and will go the way of Gastby.
I have been building a completely open-source platform for hosting your own complex web applications.
And I just recently open-sourced the JS framework. It loads modules on-demand as you need them. It’s supposed to be an all-in-one alternative to React+Redux, Angular etc.
Feedback would be welcome. I do want to start promoting it but it’s still early days.
EDIT: why so many downvotes, and no feedback at all? Just curious. Do the downvoters wish I not share my code with open source MIT license with others? They want people to hear only about existing encumbents?