Don’t ever use Next. Terrible developer experience, vendor lock in, weird undocumented conventions that make building anything other than some kind of B2B SaaS CRUD site full of undocumented foot guns. My favorite thing I’ve encountered is the Next <Image /> tag somehow dropping the FPS on a webgl scene on the same page to 2 FPS.
How was Vercel able to frog-boil normal React users with vendor lock-in? React was supposed to be Meta's baby and open source was supposed to defeat vendor lock-in.
If you are new to React and just figuring out how to get it running, you will likely end up on this page. The first recommendation is Next.js.
The real best way for a beginner to start is IMO Vite. Comes with everything you need to get started and lets you choose what to do next. Curiously, the link to Vite only appears at the very bottom of the page and is implied to be only for those not already served by other options. Wink wink nudge nudge.
because they pushed shiny new features that are reaaaallly good for a certain set of commercial users (think webshops, where time to first contentful paint equals time to money)
and the tech is not bad, it's just meh (immature and a bit misguided) after all
by flipping the whole thing upside down, defaulting to server-side, a lot of previously hard problems became easy (the usual glueing of different APIs - user, CMS, metadata, "security", adtech, blablabla - translate to `const user = await auth();` and so on, and still after processing the request emitting a React page is kind of nice, Server Actions are also nice because Next manages the API URLs for you), and since mobile technology (phones and networks) evolved a lot it's not a problem to do a request for each page (especially on webshops where Next prefetches the ha$$y path))
Can you name/explain your problems with them? What was the intended use case and goals, what did you like about them, and what you didn't, and what was something that was definitely missing for you?
Svelte is very immature in terms of tooling and IDE support and that hasn't seemed to improve in the last 7 years of using it. Libraries are sub-par vs React and the design of the language does not favor making things explicit. $:{} for example is not explicit, I'd much rather use a slightly longer token (like useEffect) to help document what's going on. That's just one example, it's riddled with things like that (e.g keyed foreach, store $ syntax). Also calling all files +page.svelte leads to such a messy experience in the IDE. There are other problems too I'm not thinking of. I think a lot of the draw of Svelte comes from it "feeling" very fast (both to build and to iterate on) when you first start using it, but imo using it for anything non-trivial is a nightmare.
Built in scoped CSS is a great idea and compiled bundle is nice. I used it for multiple projects (order system, admin panels, etc) and it always feels that little bit more brittle when I use Svelte vs something more mature. I won't use it again for any project.
I have less experience with Next and it was longer ago but iirc I found it needlessly hard to use and deploy as well as some problems with Image tags (you need the exact size of the images?). I also found their gamified tutorial really off-putting and indicative of corporate bloat which I guess makes sense now that they're locking users in. The reason I used it was for page loading speed optimization (SSR) and didn't find any better alternatives that use React at the time. I use Next for my landing page https://audiodiary.ai and for its admin panel.
> $:{} for example is not explicit, I'd much rather use a slightly longer token (like useEffect) to help document what's going on
FWIW you're describing a legacy syntax — modern Svelte has explicit effects, and addresses your other concerns. I think you'll find it's much more to your liking https://svelte.dev/docs/svelte/$effect
100%. Used it last year for the first time in a long time and was surprised by how awful the experience was. Docs were vague and hard to navigate. My web application seemed slow by default. We also had a hell of a time trying to deploy it with Docker to AWS using the sample Dockerfiles provided by Vercel (not sure if this is still the case).
Oof. I'm sure Vercel might patch this issue. But I had had enough of these little annoyances. For example, the documented way to identify prefetches in the middleware has been broken for weeks (months?).
A lot of small issues that keep adding up. I'm not going to shill something else here, but I have a bit of Next.js fatigue lately. Still love the JS ecosystem though.
I moved away from Next.js, and switched to Astro. Originally I just wanted to go back to basics, but didn't want to bother with having to set up all my routes, templating, serving static assets, build tasks. Astro just handles all that, and it's SSR by default.
I also feel that Astro uses React/Vue as it was intended, as an interactive layer on top of HTML. It also made me realize how little I needed JS frameworks to begin with.
Next just started to feel like to much magic, the server actions felt weird, and just lots of things that required the "NextJS way".
Now:
1. There's a flicker in the content where the sidebar moves on the left
2. The title displays `docs.astro.build` for a split second before it says "Routing | Docs"
Especially the second is quite annoying. I see it in every Astro site.
I'm still using Next.js in my work and projects because I still think it may be the best way to ship React to production, but it used to be something fun, enjoyable and productive. sometimes I feel a bit sad about the direction it's going in since the move from pages to the app router.
The best way to ship React to production is with Vite. It opens up tons of options (Tanstack, RR, Simple SPA, whatever) and you don't even bring the hosting provider into the discussion.
This - I spent quite some time fighting the new Next.js conventions not working for me making a legit web app instead of traditional site, switched to vite and was like yay, things work again and so fast. Normally I am all about embracing the framework, but kept thinking for what was happening I could use PHP instead and host anywhere.
Another follow-up. Some libraries[1] started to break from 15.1.8 onwards, so you had to downgrade to the vulnerable versions the author mentioned as well.
Next has become a joke. It’s mildly frustrating that with Remix’s inexplicable transformation into react-router, there’s few great react frameworks left (for me), I’m back to plain vite with tanstack router.
I've been trying and learning TanStack Router with a new project and it's been really nice, so nice that I then added TanStack Query, and then also added TanStack Form.
I'm not sure if you are implying that you aren't using remix anymore after the rebranding, or that it's not a framework anymore?
Because React Router 7 definitely works as a framework [1] and it works like a charm.
Source: Backend developer with 15 years experience, lately switched to full stack, using RR7 after advice from a very good friend, still getting amazed every day.
Remix still works fine. React router v7? Well, I guess? Ever since I switched that on the project all my types come out weird. It’s not the end of the world, but remix is a framework, react-router is a component. Now they’ve conflated the two, and it just doesn’t work for me.
I started learning Remix, which was then relaunched as RRv7. Now Remix is going to be revived, and based on Preact instead[0].
I have given up and started learning NextJS. At least it has marketshare, while Remix will never gain traction because it keeps getting torpedoed by a couple of pivot artists.
I’ve worked with Next.js professionally for the past 3 years, and it’s been torture.
(hosted on Vercel, and the company used almost every single service Vercel sold. Worst vendor locked-in ever)
I replied to Dan’s previous HN post about RSC, sharing how I had a terrible experience and he was right to highlight:
"I think RSC itself is pretty solid by this point but frameworks around it (primarily Next.js) are still somewhat rough."
React is fairly mid overall, and Next.js is only accelerating its bad reputation.
Stay away!
I've been saying for years that everyone should put much more consideration into using anything that Vercel has its hands in, such as React, Next, and Svelte. Their goal is to lock people in the same way Heroku did, but even more aggressively by tying people to their full stack solutions from the language to the runtime to the machines.
Not that they're the only company to be weary of. I recently found out that Cloudflare's CLI tool for development and deployment only supports macOS 13.5+, which is less than two years old. I couldn't track down why exactly, but it's a sad state of affairs when two years is considered obsolete.
In fairness, you can still use an older version of wrangler, but it's a previous major version. Documentation and features are misaligned, and will only get worse. They could also break compatibility with it on their end in the future.
Meanwhile, new versions of other tools like vim, neovim, emacs, llvm, etc. all still work fine on OS X. I'd argue it's because they have no incentive to lock people in.
For real. It makes me feel like I'm coding in C++ again. I have the suspicion that many Next aficionados are using M12 Macs with 512GB RAM and don't know how bad the DX is on anything less than a bleeding edge machine.
We've gone so far that the promise of a simple scripting language like JS has multiple build and compile steps, and they're taking longer than a god damn C++ compiler.
Who knew that if we just threw Clang in a browser we'd somehow have a more pleasant experience?
On a related note, we use PHP at work. Same fucking problem. It's a scripting language, should be painless no? Wrong. PHP has awful performance characteristics, so we need to generate some code ahead of time. So we have a custom build step that uses Composer. That custom build step is SLOW. Probably because it was created by shitty PHP programmers and not the people who wrote GCC.
It is unknown though what causes it to take 10 seconds to compile a route in dev mode after each change. They have a development environment guide[0] but it's all lies and doesn't actually work.
Next and RSCs have become some of the most frustrating things I've worked with on frontend. Dealing with FE is already annoying enough, but having to wrestle the magic of Next and then vendor lock-in to Vercel to top it off.
Team is trying out Tanstack router + vite this week. Excited to build a regular ass CSA.
It's fine if you know them well. The unclarity in boundaries between client and server components, and the unintentional complexity that brings, is just frustrating to work with. I will gladly take a CSA any day.
But don't let a random internet stranger detract you. If it works for you, go for it.
It's really sad what Next.js has become. I still use it, but I have to maintain my own fork with patches. The next.config.js file is an ugly escape hatch that lets you change default behavior for things that should be properly extensible instead of being hidden behind "feature flags" in the first place. Honestly, the framework is a solid D grade at this point — complete spaghetti code.
I don't know. I felt NextJS got too complicated for me years ago and may have had a sweet spot back then when it felt magic. Now id just use a boring web server for most things. Chuck on a front end framework when needed for a SPA. If you choose classic or SPA things are far more simple.
people who were[0] "not even wrong" about understanding how an SPA maps naturally to the server-client boundary are now free to cook their fine pasta-based product however they think is best.
This seems blown out of proportion. Anyone who knows how streaming in React works knows, that you can't stream your HTML line by line. And there was the need to not block first paint (HTML, not JS) just because of metadata. It's reasonable to have a list of user agents that are exempt from that behavior since those are also not the bulk of your traffic where you want to show something as fast as possible.
How would you instead solve this, with the requirement that some users have metadata that takes a while to load?
It’s opinionated, and they’ve been pushing streaming—just like the React team—right? Yes. Is it unusable outside of Vercel? No.
As far as I know, Next works without hiccups if you deploy to containers. However, that’s not our case, as we use Lambdas on AWS. We’ve been using OpenNext since the early versions. I must add that I’ve followed a lot of libraries on Discord, and among all those I’ve joined (PayloadCMS coming second), there’s none as helpful, friendly, and open to discussing issues as OpenNext.
We serve millions of pages per day at TelevisaUnivision, and we have nearly 5 million pages indexed on Google. Since migrating to RSC nearly three years ago (we started with the betas), we now pay only 10% of what we previously did on AWS, and we’ve transformed almost all of our poor-performing pages into fast ones in Google Search Console. We cache significantly more now and don’t follow the typical caching conventions of Next/OpenNext—we use ElastiCache with Redis. Nonetheless, the framework and library have enabled us to do this and even allowed us to use a different CDN (currently Fastly, previously Akamai).
We trigger our deployments from GitHub Actions using SST. It’s opinionated, and one of the individuals behind it isn’t the friendliest, but it works—so I respect it for that.
Vercel recently spammed my work email with news about a local talk/webinar. On the one hand that's useful info (I'm a front-ender after all). On the other hand it's freaking creepy. I've been in this job three months and hadn't signed up to anything Next/Vercel from my work email. That means (at best) they scraped me from LinkedIn and guessed at my email address. At worst I've left a data trail that someone's compiled me into a few categories and Vercel bought me in a bundle. Clever growth hacking, give that employee a bonus, but jeez is it why I hate parts of the interwebs these days.
What's the recommend full-stack setup, if not NextJS?
My background: I have ~15 years of software development experience, but practically all of it in backend stuff. (Well, I did some AngularJS a decade ago but that's it.) So, when I recently wanted to build a fullstack app for the first time for a side project, I looked around and learnt NextJS was the way to go. (Gemini said that, then Cline's official documentation said the same.) I am early in the process, so happy to learn of solid alternatives.
I am planning to host everything on some VPSes through Docker, because that's what I am comfortable with. So, no Vercel or Netlify.
If you don't need server rendering, I'd just recommend React without framework, and Vite [1] to run the app in dev and build the app in prod, then host the build (basically a HTML page with a JS file) on AWS S3 or similar static hosting platforms. That's the solution I've been using for 10+ years without any problem.
For the backend you can use whatever you are comfortable with. I mostly use PostgREST [2] nowadays. I recommend to use react-query [3] to call your APIs on the client side.
What are you building? I am working on a classic SaaS webapp, and I have found that using React/Refine.dev/Vite has been great. Refine.dev let me focus on my features, and not basic CRUD page stuff.
I am building an AI application (of course). It'll have an agentic workflow in the backend and exposes a chat style interface to its users. So, not a lot of CRUD stuff.
I would recommend still looking at it for 15 mins. You will still need basic stuff like login pages, a profile page, a responsive nav system, etc., right?
This might be confirmation bias but I'm very happy that we picked Astro over NextJS. Support for Standalone server is a must for our case since we run the biggest classifieds site in Germany and vercel costs are impossible to pay.
Vite has gotten really good and I don't need NextJS anymore to make React easy.
However, it did really feel like magic a few years ago and has become the default choice. At this point it's a legacy framework that we all have to deal with the same way Spring is.
I think that it depends a lot on how much customisation you have to do on top of NextJS to make it work for your personal use case.
For example if you stay as close as possible to the framework defaults, everything is golden. But as soon you start pushing it to the limits the cracks start to appear.
Last year I was working on a NextJS app with 15k files, 18k unit tests, 100+ developers in the same repository and a page with hundred of millions of page views daily. Under that conditions NextJS doesn't scale, but again, those conditions are not the majority of the NextJS cases.
In that project, we have been using NextJS as a standalone for around 5 years and each time NextJS rollout a major version it take us at least 2 months to be able to upgrade and keep it working.
The confusion is that there are plenty of front-end developers that have no clue what they are doing, and then blame it on the tool. Believe me, I interview plenty of front-end developers each month.
The main problem is that building a website is very different than programming a web application.
As a senior software engineer with a Masters degree in CS, NextJS works great for me.
Another poster here claims an <Image> drops his Three.js to 2 fps, and of course blames it on NextJS. I work with Three.js, and never seen such issue (React-three-fiber however does have some peculiarities). Before blaming some random tool, maybe first investigate where the problem lies. If you pinpointed it to NextJS, sure, it's NextJS. Before that, don't blame anyone but yourself.
I always laugh when I read HN and Lobster commenters. I use NextJS and LLM's, and I leave my competitors in the dust. So yeah, the proof is in the pudding, not in some random folks commenting on the internet.
This also reminds me of some commenter here on HN who was angry at Java because their sorting function was unstable for many years :D.
Dude, I explicitly replied that I pinpointed it to Next. The moment I removed the Image tag and replaced it with a regular <img />, it resolved itself. I didn’t even say I was using three, did I?
My above text was written before you replied to my other message.
And besides, just because using <img> instead of <Image> doesn't imply that the actual issue was in <Image>, it might also be in another part and <Image> triggered it. As I told you, as long as you don't pinpoint the problem, you can't say where the problem lies.
Maybe your definition of pinpointing is different than mine.
It's hard to get Next.js to build because it runs your code during build time, and it has some obscure DynamicError shit, I barely got it to work somehow.
I noticed that I actively got downvoted on this comment, it seems there are malicious actors who are against NextJS and Vercel company for some reason.
Instead of being cowards, please reply what features of Next do not work in self hosting through a simple 1 line Docker image?
It made it by default. It's also not much of an "opt-out". An opt-out would be called "disableStreamingMetadata". Names convey intent, and it's obvious this is intended to be the behavior for all users with maybe an exception.
The problem is that this is needed for a minuscule amount of users. This should've been an opt-in. The choice to make it opt-out is quite weird.
make sense now. They should add disableStreamingMetadata option to completely disable it instead of disabling it by matching user agent in a irreverent field name.
Many people choose Next.js because it has better SEO support than other options.
