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.
> 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.
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.
>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.
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.
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.
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.
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.
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.
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.
Actually, I do exactly that and Next.js does have support for static exports. I write the SPA in React/TypeScript/Next.js and export to static html+js+css+assets. Those I can simply sftp to a target static webhost. All the logic is in a REST backend that is written in .NET/C#.
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.
> 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.
> Having no SSR but everything be statically exported allows me to get away with cheaper hosting on the backend side
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.
You confuse a static website with a statically exported webapp. The site I do and posted a link to has a user/login section with lots of interactivity. Plus, there are features like using the webcam for scan QR codes (using a wasm library to read QRcode in JS from a media stream), receiving push notifications (and be a PWA on iOS), generating customizable print cards, etc.
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.
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.
> 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.
> That's where ~all of Next.js' complexity comes from
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.
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.
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
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.
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.
I can't speak for Rich Harris, but Svelte and Sveltekit were never created as part of any company. These tools were created organically.
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.
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.
I find the problem is that Vercel has great product vision, but is weak in the engineering department, so encounters end up in some kind of uncanny valley.
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.
I was trying out Astro recently. Seems fine. And it allows you to bring in any kind of components: React, Svelte etc. Has its caveats, but it's same stuff with slightly another approach.
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.
There are many Astro recommendations. I like it as well but only for more content heavy websites. If you dont have that it's not as easy to work with as something like Remix in my experience.
It's a common misconception. Astro is not just for blogs. They implement islands architecture[0] and advocate for progressive enhancement[1], which has many benefits.
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.
The reason I said that is because it's very easy for people to get the wrong idea that Astro is just one of those blog pre-rendering engines, because it strips JavaScript by default and has features like Collections API and built-in markdown rendering. But I'm also willing to argue that Astro is not any harder than Next.js or Remix, just takes a different approach (islands).
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.
> 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?
WordPress, despite all of the current drama, is an example of an open source project with many different competitors and development seems to move just fine.
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.
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.
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/image is a particularly poorly built piece of NextJS in my opinion.
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.
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.
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 could totally see how you'd arrive there. Backstory:
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.
> 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.
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.
> 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]
Yeah, this is what I was remembering. Glad to see I didn't flat out hallucinate the idea that "create-next" as the starting spot for creating a React site.
Don’t know why you are gray as when I was researching my front end platform choice “the universe” certainly seemed to frame it that way. It was framed as you were seemingly either using next.js or writing some kind of “legacy app” in boring old react. Which turns out isn’t true.
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.
No, React is purely a library for rendering HTML elements on a screen. NextJS uses React for that, but it's more comprehensive. E.g. it provides routing out of the box, and server-side/client-side rendering bits, and it can run your code as a web application.
Apologies, I worded my question wrong. I should have asked if that "Was not that the case?"
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.
You're not entirely wrong. React is maintained by Meta and Vercel. There is also a divide in React at the moment, like Python 2 and 3, between server first and client first. Next.js is the "official" way to do server first React.
Not really. Next.js is still React. It's more like a wrapper/sidecar/framework around React that brings in some opinions on how to build apps and provides some niceties if you buy in.
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.
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.
> Ultimately your cloud functions reach out to your database, that is centrally located...
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.
As far as I’m concerned, SSR is completely over-hyped and adds a ton of complexity to your project. All these search indexers are all running headless chrome anyway so the SEO argument is largely false now.
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.
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.
Yes, they can ship such a dongle, but they have no right to claim to be open source or listening to their userbase then.
The problem is the hypocrisy of the company, and therefore loss of trust.
> 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.
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.
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?
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.