Next.js 15.1 is unusable outside of Vercel
omarabid.com
omarabid.com
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))
but it's still a very subpar backend framework :/
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.
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
Example:
https://react.dev/learn/creating-a-react-app
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.
Not necessarily, it's just (sadly) the best React framework out there.
Why is no one building a better framework?
I work with NextJs, <Image> and RTF, and never encountered such problem.
I'll admit that the way we were using the image tag was a little unusual, but still something that was imminently supported by a plain HTML image tag.
My point is more that Next is such a bizarre black box that things like this were a regular occurrence.
To clarify: yes, it was the next Image tag. The moment we switched to using a plain image tag it resolved itself.
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.
Anyway, thanks for bringing this up!
[1]: https://github.com/hashicorp/next-mdx-remote/issues/488
With whats mentioned in the blog post I would not use it even from static builds.
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.
The flicker seems to be because the collapsible nav items are done on the client, and closed by default.
I'm not sure where the title issues are coming from.
I use Next for a handful of small projects, and SEO was always touted as the big benefit to me.
I can just generate a bunch of static files, copy to S3, and be done. Is that not true anymore?
I'm still using React Router tho (as a dumb SPA router, not the new "framework" features). I might take a look at TanStack Router one day.
One time I simply made a post about how a page was simpler to code and understand in Remix.
You may not believe this but I had 3+ chat requests from multiple employees at vercel.
Across multiple social media accounts. All asking to take it down or meet and discuss with them.
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.
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 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!
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.
I can’t think of a stack I’ve worked with that I loathed more since that one and only time looked at helping someone fix their Sharepoint site.
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.
[0]: https://nextjs.org/docs/app/guides/local-development
Antivirus? Imports?
```
Compiled /analytics in 3.8s (3123 modules)
GET /analytics 200 in 5185ms
```
Doesn't explain the 10 seconds.
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.
Team is trying out Tanstack router + vite this week. Excited to build a regular ass CSA.
What is frustrating about RSCs? They work really well for me and I'm still using Next.js only because of RSCs.
But don't let a random internet stranger detract you. If it works for you, go for it.
[0] still are ... ¯\_(ツ)_/¯
How would you instead solve this, with the requirement that some users have metadata that takes a while to load?
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.
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.
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.
[1] https://vite.dev
[2] https://docs.postgrest.org
[3] https://tanstack.com/query/latest/docs/framework/react/overv...
Plain React, Vite, React-Router, & SWR. Is simple & works great for almost every use case.
Here is an article I wrote of why we chose it https://d13z.dev/blog/07-why-kleinanzeigen-picked-astro-over...
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've never opted for Nextjs for any client, but have experienced having to get rid of Nextjs from client projects.
I am hosting several nextjs apps for my day job. We just put them in a docker and throw them on the server, whats the confusion?
lets be real here, vercel did not maintain next js for a "free lunch" they want people that use next js be the customer of vercel
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.
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.
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.
Instead of being cowards, please reply what features of Next do not work in self hosting through a simple 1 line Docker image?
This kind of problem, and the vendor lock-in, is completely unimaginable for any web framework I can think of. Bizarre.
It did say this was a problem for very few people.
Let the programmer do high latency shit if they want. Give them a damn catch if they need it.
Is there anything else?
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.
Many people choose Next.js because it has better SEO support than other options.