We've been having a lot of problems with weird bugs with nextjs, so I can't really recommend it. Feels like it's a eternal beta.
First, we've had a problem with nextjs not caching the response code for 404 pages, so 404 pages would have a 200 status code. Now they've fixed this they have a bug where they are caching the 304 response code, responding with 304 to every request and completely breaking the site. This has been open for a month now and has affected a lot of people but it seems like Vercel just doesn't care.
Yep their github management is atrocious. I understand it's a popular product so you get a lot of low quality issues opened, but there tons of real problems where no developer ever appears, and then are closed by the bot because of inactivity.
Infuriating. The longer I do this, the more that issue management responsiveness becomes a real consideration when choosing a dependency.
I’m not trying to victim blame but why not fork and fix the bug? Isn’t that the point of open source? If you’re not paying for support then I feel you should set expectations accordingly. Do they offer any kind of sla or some other guarantee on responding to an issue?
(I work in enterprise stacks where there’s a hard contract that defines these things so maybe biased)
My experience with NextJS has been very frustrating.
- it adds a layer of opacity between the front and backends (or as they are in Next: the frontend, the frontend backend and the backend backend).
- front end code can run in the frontend backend and consequently needs a lot of extra guards.
- front end stack traces are almost completely useless in dev mode. If you’re lucky, they will include the file name where the issue occurred, but often in these cases the line number will point to an empty line.
I think the common thread here is that Next has a lot of surprises, especially when not on the happy path. It frequently breaks my intuition about how the web works. I’m strongly considering migrating our Next projects to React.
Next’s support outside of Vercel is best effort it seems. Which is fine as Vercel funds it, but it feels like there is a conflict of interest. There is after all a reason for OpenNext’s existence.
I can’t recommend Next after using it even on a small project.
Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open. This was a daily recurrence.
Also, the “fix” for many issues was to throw “use client” at the top of problem files. Serving the application whether first time load or dev time with hot module reload took an age.
Really quite a miserable experience honestly. I have much better experiences with either a plain SPA or Astro.
> Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open.
Is this with a fresh Next.js project of after you've added user code? If the former and there's a GitHub issue, let me know and we can take a look. Thank you.
> Also, the “fix” for many issues was to throw “use client” at the top of problem files.
Next.js is such an odd experience.
On the one hand, I've built three apps in Next.js, a business directory on Vercel with a separate (Firebase) DB, a blog (Cloudflare, Next on Pages) which pulls from an API and a little calendar management app (Vercel), which also only pulls from an API.
The speed at which I could get something up and running was astounding. Before Vercel I tried Google's Firebase hosting, which was so hilariously bad that I switched to Vercel, where everything just worked. You'd expect that from the makers of the thing.
However, I was wary of vendor lock-in. When Vercel decides to arbitrarily break something you relied on, you are at their mercy to figure out when your app will run again.
And this is where things get hairy. The Next.js documentation is sparse. So you either get lucky and someone else has done the guesswork to figure out how to do the most basic things in Next.js (for example the transition from 12 to 13, aka pages-router to app router was ROUGH...you could only find SO issues related to 12 and all the libraries and structures you were used to had all changed in subtle ways).
Caching is another one of these things. There are fetch calls in some routes in my app that get cached no matter what. I've tried every which way to get the damn thing to stop them caching (the most obvious one being the no-store header), but to no avail. It caches and I can only get it to stop by redeploying. And no, purging cache from the Vercel dashboard doesn't fix it either. Only a redeploy will get me updated data from the DB. It's bizarre.
And so the story goes on. It's super easy to get up and running. There are many 'aha' moments, where you can see that a ton of work has gone into DX. So much so, that I really try to use Next.js where I can. However, when you run into problems, they are usually more difficult to solve than with React. And they are subtle and not infrequent.
Don't get me started on debugging. Since Next.js is sort of 'backend' to a large degree (which, in Google's and Cloudflare Page's case means edge-functions), trying to tease a meaningful log that isn't severely character-limited out of either service is very difficult. Error messages in the frontend are useless to an astounding degree.
So, it seems there's a lot of work to be done. Tread carefully, as it's very enticing to have this quick-start, but I'd hesitate to use this for anything too serious, as things will break for no reason and there will be issues that are nearly impossible to solve and I wouldn't want clients emailing me while I'm dealing with BS I simply wouldn't have had on any other stack.
> Only a redeploy will get me updated data from the DB.
This caching thing, when it wad released, is one of the sneakiest bastards ever.
I had to add a random string to a query of each request to avoid caching on the management panel. It happened that because of the cache, one client was able to see the cached data for another client.
We have had 4 FE on next and now gradually moving to remix and away from vercel.
+1. I spent hours to understand how the router cache works and turn off cache but failed. It is good in pages folder. But in the app folder I just can not stop the cache.
What why ? The term that you work for Vercel should be at the top so that people realise this isnt a neutral 3rd party but a company paid spokesperson.
To be completely fair, it's a response to someone who wrote about why to use Remix and not NextJS. The author of said post was apparently the CTO for Remix. Both sides are doing DevRel here
I want to leverage Next.js but not Vercel (if I don't have to). I have experience with backend and devops, so I care about and want to deal with the backend myself (cost-savings, control, decoupling).
The sentiment and complaints seem to sum up to, "if you're using Next.js, you basically [or eventually] have to use Vercel." But I do not want this to be true. That said, I also don't want to sacrifice benefits of Next.js or have to "fix" things constantly or unnecessarily.
Readit News
First, we've had a problem with nextjs not caching the response code for 404 pages, so 404 pages would have a 200 status code. Now they've fixed this they have a bug where they are caching the 304 response code, responding with 304 to every request and completely breaking the site. This has been open for a month now and has affected a lot of people but it seems like Vercel just doesn't care.
https://github.com/vercel/next.js/issues/56018
Infuriating. The longer I do this, the more that issue management responsiveness becomes a real consideration when choosing a dependency.
(I work in enterprise stacks where there’s a hard contract that defines these things so maybe biased)
Fixing bugs is down to priority and incentives of the parent company.
- it adds a layer of opacity between the front and backends (or as they are in Next: the frontend, the frontend backend and the backend backend).
- front end code can run in the frontend backend and consequently needs a lot of extra guards.
- front end stack traces are almost completely useless in dev mode. If you’re lucky, they will include the file name where the issue occurred, but often in these cases the line number will point to an empty line.
I think the common thread here is that Next has a lot of surprises, especially when not on the happy path. It frequently breaks my intuition about how the web works. I’m strongly considering migrating our Next projects to React.
Deleted Comment
Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open. This was a daily recurrence.
Also, the “fix” for many issues was to throw “use client” at the top of problem files. Serving the application whether first time load or dev time with hot module reload took an age.
Really quite a miserable experience honestly. I have much better experiences with either a plain SPA or Astro.
> Whatever it sends to the browser is enough to eventually freeze the entire browser tab if you have the dev tools open.
Is this with a fresh Next.js project of after you've added user code? If the former and there's a GitHub issue, let me know and we can take a look. Thank you.
> Also, the “fix” for many issues was to throw “use client” at the top of problem files.
The Server Components model is still really new. It'll take some time for the ecosystem to evolve here. Here's a good post if you want to learn more: https://github.com/reactwg/server-components/discussions/5
And this is where things get hairy. The Next.js documentation is sparse. So you either get lucky and someone else has done the guesswork to figure out how to do the most basic things in Next.js (for example the transition from 12 to 13, aka pages-router to app router was ROUGH...you could only find SO issues related to 12 and all the libraries and structures you were used to had all changed in subtle ways).
Caching is another one of these things. There are fetch calls in some routes in my app that get cached no matter what. I've tried every which way to get the damn thing to stop them caching (the most obvious one being the no-store header), but to no avail. It caches and I can only get it to stop by redeploying. And no, purging cache from the Vercel dashboard doesn't fix it either. Only a redeploy will get me updated data from the DB. It's bizarre.
And so the story goes on. It's super easy to get up and running. There are many 'aha' moments, where you can see that a ton of work has gone into DX. So much so, that I really try to use Next.js where I can. However, when you run into problems, they are usually more difficult to solve than with React. And they are subtle and not infrequent.
Don't get me started on debugging. Since Next.js is sort of 'backend' to a large degree (which, in Google's and Cloudflare Page's case means edge-functions), trying to tease a meaningful log that isn't severely character-limited out of either service is very difficult. Error messages in the frontend are useless to an astounding degree.
So, it seems there's a lot of work to be done. Tread carefully, as it's very enticing to have this quick-start, but I'd hesitate to use this for anything too serious, as things will break for no reason and there will be issues that are nearly impossible to solve and I wouldn't want clients emailing me while I'm dealing with BS I simply wouldn't have had on any other stack.
This caching thing, when it wad released, is one of the sneakiest bastards ever.
I had to add a random string to a query of each request to avoid caching on the management panel. It happened that because of the cache, one client was able to see the cached data for another client.
We have had 4 FE on next and now gradually moving to remix and away from vercel.
This alone should be further up the post…
https://news.ycombinator.com/item?id=38018217
I want to leverage Next.js but not Vercel (if I don't have to). I have experience with backend and devops, so I care about and want to deal with the backend myself (cost-savings, control, decoupling).
The sentiment and complaints seem to sum up to, "if you're using Next.js, you basically [or eventually] have to use Vercel." But I do not want this to be true. That said, I also don't want to sacrifice benefits of Next.js or have to "fix" things constantly or unnecessarily.
If it runs in the browser, it's frontend. Server? Backend.
There's SSR but the name itself clarifies: Server Side Rendering.