Edit to add a simple example:
Musk's wealth is mostly tied up in Tesla -> You think Musk uses his wealth to wield political power, political power that makes the world a worse place -> You still think Teslas are good cars -> Even though you think that, you don't want to spend your money on buying a Tesla, because this will make Musk more wealthly -> Start at the beginning
Exactly, it is a human behind the company that does every decision. Company is just legal shield. Every decision is affected by what they really are or think.
NextJS is a pile of garbage, and their platform is absurdly expensive and leans heavily on vendor lock in.
I hope this isnt the way that React as a whole will go in the end.
But fortunately there are enough alternatives about.
- inconsistent behavior between hosted and self hosted versions of the same code
- horrible build times, like laughably bad multi-minute builds for trivial code bases
- crappy directory based routing system with lots of weird gotchas
- schizo identity JAMstack -> serverless -> ssr -> now its microvms + ai
- multiple hilariously long running GH issues where the dev team is thrashing around trying to debug their own black box framework
- "framework" that barely provides any of the primitives necessary to build web apps
- major breaking changes around core features like routing that require painful migrations
- general sloppiness, churn, and insecurity that comes from being part of the nodejs ecosystem
Thats not even getting into all of the shady patterns vercel uses to lock you into their overpriced hosting.
I've been a part of multiple teams that decided to build apps using NextJS, and while the FE is not my responsibility I typically got pulled in to help troubleshoot random issues. It was a complete waste of time in almost every case, and in one case resulted in the entire FE team being let go because they were unable to ship anything on time.
I won't repeat what the sibling poster said, but I can tell you, I've been using NextJS from v12-v15 and in that time we've had:
- The catastrophic (and, at the time, UNDOCUMENTED) "aggressive, opt-out caching of all fetch calls", which confused the living daylights out of everyone who suddenly couldn't retrieve updated data from their servers. Like, don't override a native JS function that's supposed to work in an expected way, with black-box magic that adds caching behaviour that then needs to be overriden _per route_ with directives on each route. Cache headers can be added to fetch calls and are easy to configure globally via axios if needed. If you're going to do black magic, call it "nextfetch" or something
- The app router / page router transition was shockingly badly handled, with so much missing documentation around dynamic routes
- I don't know how many different ways of fetching / setting metadata / <head>-related techniques I've had to learn by now. It seems to change all the time. BUT, that isn't the worst part....the worst part was / is:
- You couldn't, for the longest time, fetch metadata for a page without duplicating fetch requests. I think this is where their fetch-deduping thing came from. But again, black-box magic on a native JS function with very inconsistent behaviour, so for a while, all pages in our app just had to make two fetch calls per page that needed specific metadata added to the <head>
- Vercel as a platform not allowing to set billing limits (have fun with your DDoS that they don't recognise as such)
- Middleware is one file. That's what you get. No chaining, nothing. One god-function for everything. Just think about the anti-pattern that is
- I don't know whether it's clever or terrible, but if you want to add a sitemap, you do so by defining a route by creating a folder called sitemap.xml (yes, a directory), where you then put your route.ts which is in keeping with the way the new router should work. But somehow it just doesn't sit right with me. Folders with file extensions. But it also adds a lot of ability to make the sitemap highly customisable and dynamic, so maybe it's ok
- You suddenly needed to start awaiting url params, cookies, etc. which is sort of fine, but was a huge change causing warnings all over the compiler for months and months
Anyway, those are just a few things off the top off my head. I already find React to be quite counter-intuitive and non-deterministic, but NextJS just adds a layer of pain on top with very, very few advantages.
I am dying to get my hands on an alternative, but also don't want to rebuild all of the apps I built when I was still optimistic about NextJS.
Whoever implemented that has no idea how middleware is supposed to work.
Vercel and Next.js have been the main testing ground during the development of React server components as well.
How much has Vercel contributed to the development of react over the past years?
The last truly useful react feature for me was error boundaries in React 16 (2017?) and I think hooks was react 16 too?
These days if I need ui components for an existing SSR app I just use web components or lightweight libs like mithril.
the official recommendation we got was to just run it on vercel
I would go as far to say that nextjs is not self-hostable in its current state if you expect high traffic and low latency.
It's designed to be deployed on Vercel. Production-ready hosting part of the Framework is not Open Source nor well documented.
https://github.com/vercel/next.js/discussions/59167 https://www.netlify.com/blog/how-we-run-nextjs/
I have a Clojure/ClojureScript app using React that I've been maintaining for the last 10 years. I don't use all the features of React, in fact I could probably use a much smaller library — the biggest advantage is that it provides a "re-render the UI based on app state change" model that fits Clojure very well. But I'm very happy that React is there and that it's been maintained with relatively little code rewriting necessary over the years.
Being able to ignore parallel rendering, RSC, hooks, etc, and just write simple code for simple sites again would be fantastic.
Unfortunately all the major competition I've seen seems so significantly different that migrating any kind of non-trivial application would basically be a full rewrite. Is Preact or similar offering much promise here?
disillusioned•1h ago
Like, I get that nothing is _owed_ here, but this feels like more of the same tragedy of the commons open source problem we see: tools that millions of apps depend on, barely propped up, and in this case, the child of a megacorporation that could easily create a proper evergreen endowment rather than a milquetoast token contribution to save face.
Or should we just be grateful?
nicce•1h ago
fcanesin•1h ago
BoorishBears•1h ago
They threw the resources behind RSC to make React, a framework for frontend reactivity, force opt-in for frontend reactivity. Meta is needed more than ever at this point, before React fully becomes a framework for burning compute on Vercel's infra.
karimf•1h ago
brazukadev•56m ago
physicsguy•1h ago
esperent•1h ago
philipwhiuk•1h ago
is probably worth more in practice. The $3m will basically just cover 'founding the foundation' I guess.
I do wonder whether this is a sign Facebook may no longer develop new stuff in React.
gampleman•1h ago
$600,000/year just to run a governance board and organize a conference seems extraordinarily generous to me. In fact I think it's more likely the $3M is more likely to form an endowment for the foundation that will fund it's expenses running forward.
mythz•41m ago
Somehow because Meta has released a popular OSS library and dedicated over 10 years of engineering resources to it (that has generated immense value for the wider ecosystem), that they should've shelled out more than the $3M they're contributing in order to give its ownership away to a non-profit.
Maybe it's just me but I think they've contributed more than enough. I'm grateful for what they've already contributed and anything else they choose to contribute in future.