You should know this before choosing Next.js
eduardoboucas.com
eduardoboucas.com
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.
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.
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.
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.
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.
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.
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.
"Syntactical" seems to reinforce his point, no? As opposed to functional.
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.
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?
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.
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.
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.
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.
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.
Unfortunately, Next.js dials back static export support with every major release, but it is still usable to create a 100% SPA with static export.
Wasn't it even originally created to produce static websites?
But, man, at that point you're bringing a bulldozer (with a super uncomfortable operator's station!) to drive a nail.
I think I do exactly the opposite. Having no SSR but everything be statically exported allows me to get away with cheaper hosting on the backend side (the REST API is on a cheap VPS). Static exported SPA means, the user's browser does all the heavy rendering. Plus, no AI bots or search engines contribute to my server's load.
Additionally, the site is fast. Not sure if you know how Next.js works, but since the initial load is already prerendered and just static html+js, it loads instantly. Then hydration happens in the background, unnoticed by the user and the actually JS takes over. JS+CSS are chunked where possible, and Nextjs employs a neat trick: It pre-loads the js+css for the next page once you mouse hover over a link - whether you click it or not. Also increaes the user-perceived speed. Plus, since all js chunks have its sha1 hash in the filename, they can be served with long caching times (even immutable, so cached forever) - once you loaded the website, recurring visits will be blazing fast.
If you want to try it out, the url is https://lockmeout.online - although I do not use a CDN and host verything on a cheap hetzner VPS - hence loading time might be higher outside europe.
Building a static website is very reasonable. Using the monstrosity that is Next.js to build a static website seems like super overkill, and I am not sure it offers a good developer experience to justify it[1].
[1] My experience with it had a need for dynamically driven pages, so it may just be that it's horrid design is only a problem once you move past static page generation.
I now just use a React SPA with Vite.
For folks who use this every day, how/why is this acceptable?
I had the same experience of slow refreshes on the NextJS project I worked on (running locally) and the other seasoned NextJS developers didn't think it was unusual.
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.
Complexity does arise there, but equally arises from limitations imposed by the Vercel service that Next.js ultimately needs to deal with. A lot of its seemingly dumb design decisions make sense once you consider the constraints Vercel (the service) forces upon it, but they are still poor decisions you have to live with that wouldn't have been necessary if it were intended to run in a "normal" computing environment.
[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.
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.
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
The svelte guy was hired by Vercel a few years ago and is completely on board. Same strategy used to co-opt React.
To my knowledge, Rich is just an employee of Vercel where they pay him to work on it full time. Despite that, I believe that Svelte still aims to remain independent. I imagine that Vercel just wanted him in-house so they could keep their eye on the latest developments in the js-framework space.
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.
Aside from the "appeal to authority", what suggests to you that they are strong in engineering?
> The CTOs previous role was in charge of Google’s search experience.
Google search also having decent product vision, but poor engineering execution, sounds about right. I don't know how many times I've heard people say they want to use Google search but have to resort to silly hacks, like adding "site:reddit.com", just to get anything useful out of it.
But, to be fair, he in particular only worked on "Google Search on Desktop" which probably isn't the search results department. The one text input box and two buttons did stay centered. I suppose some do say that is the hardest problem in engineering, but I'm pretty sure they are joking.
Yes, this multi billion dollar revenue stream is “one text input box and two buttons”.
Truly amazing insights.
But anyway, I think there's plenty of alternatives. Next.JS simply took everyone's attention making it to seem like there's no other tool like it out there.
[0]: https://docs.astro.build/en/concepts/islands/
[1]: https://www.gov.uk/service-manual/technology/using-progressi...
I think this makes it sound like I'm repeating something I've heard. It's my experience, not just some preconceived notion I have. I find it much easier to use something like Next.js, Remix, etc. (if we are comparing frameworks) than Astro for more dynamic web apps.
I would be very surprised to hear someone who prefers to build substantial dynamic SPA in Astro. But if that's you I'd love to hear more.
I actually did build a substantial dynamic SPA in Astro[0], and I would still choose Astro if I could start all over again, because just like other frameworks Astro has great support for data fetching, and also allows you to trivially have some parts of your application fully JavaScript-free, such as the login page where just the browser-native form is sufficient.
I agree that it doesnt only do blogs and static sites. I found it to be harder to use for other cases but I'll poke around in that repo.
Astro has more focus on content based sites whereas the other two may also be used for web apps.
Would it? Or would it turn Next.js hosting into a commodity with zero marginal profit, ulimately making it impossible to fund development?
Creating an artificial moat and misrepresenting capabilities, as outlined in the article, may bring value to Vercel, but it can hurt consumer confidence. I would not and have not chosen Next for projects because of the lock in.
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.
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.
At least the last time I used it (around a year ago), their was very little support for basic image transforms. Image resizing and cropping, for example, would always ignore the height provided and resize to the requested width. Any change to aspect ratio was done via a div wrapper and CSS, the image itself wasn't actually cropped to the requested aspect ratio.
This complaint is less about Next as many image services do it, but I've never liked the idea of an image service returning an image format other than what was requested. Deciding what image file size and format to request is a browser concern, the back end should just serve up what was requested rather than trying to cleverly decide the "best" format based on request headers.
Similar to SvelteKit, that's built on Svelte, and Nuxt that's built on Vue.
You should probably read the article before posting.
My memory was that the hello world, "starter" project, was to create a "Next.js" application at some point. I see, now, that they have https://react.dev/blog/2025/02/14/sunsetting-create-react-ap... documenting that they don't recommend any "starter" path. That somewhat surprises me, but I couldn't say it shocks me.
create-react was a starter boilerplate for React built and maintained by Facebook. This was when webpack was the standard and just getting a local development environment to "hello world" for React could be challenging.[1]
That project was depreciated and the popularity of the Next.js site framework for react projects (plus I certainly assume heavy lobbying from Vercel) pushed the react docs to officially suggest create-next as the new starting point.[2]
Note that there are many other ways to start a react project and there are also many react projects that don't use or need Nextjs. (I use react quite a bit but I pair it with Astro.js, for example.)
I would say that a lightweight Vite template is really all you need for a lot of early success with a local environment for learning / building with React.
[1] https://github.com/facebook/create-react-app [2] https://react.dev/learn/creating-a-react-app
This is a very generous take.
It seems like Vercel had enough money and hype to lure react devs away from facebook to work for them. I see this as the biggest reason why react is pushing users towards vercel. Further, Vercel was able to work very closely with the react dev team when developing react server components, giving vercel a first-to-market advantage and a headstart on vendor lock-in.
I didn’t need SSR and my research suggested that next.js might be overkill so I landed on react + vite. So far so good.
If you have time for the project, you have time to learn a proper setup that every company for the past 15+ years has used.
SSR is quite frankly a performance myth if you distribute your frontend on a CDN. Ultimately your cloud functions reach out to your database, that is centrally located... SEO work well without SSR for the most part.
A big difference is that your code running in the datacenter should always be well connected to the network. The user running your code out in the middle of nowhere teetering on the edge of available mobile coverage... Not so much. SSR means the user can begin after one round trip instead of, at bare minimum, two (and more realistically at least three – HTML, JavaScript, and data), which becomes significant as latency rises.
Although I would agree that the cases where you actually need that are not as common as we like to think, and even where justified a lot of developers are bound to screw it up such that the app isn't usable without multiple round-trips anyway. It is certainly something you should think long and hard about. It is not tradeoff-free.
Running vite and deploying a fully static site that interacts with an API is, to me, vastly simpler to reason about than a blackbox react framework (next.js) sitting on top of a black box rendering library (react).
Having a “backend for your frontend” is pure overhead for most projects. I’ve been building on the FE for a decade and have only needed SSR once and certainly never needed some hybrid static/dynamic/islands setup.
If you need SSR, you need it, but I find SPAs to be vastly superior in terms of dev speed and overall performance of an app once the JS has loaded.
Python and Django (SaaS Pegasus is a good paid boilerplate, complete with a standalone React frontend example.)
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.
Both are hype technology and will go the way of Gastby.
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?