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)
Yep absolutely, I agree and understand how much we're getting for free.
On the other hand, their marketing and hype machine has gotten the industry at large to buy into their product. So when you promise enough to get companies to move to your (free, open source) tech stack, but then are MIA when there are issues... I am of two minds.
I was about to say, just fox the bug submit a pull request and use your fork until it’s merged. Isn’t that the point of all these fancy source control tools?
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 really don’t understand this sentiment, it is extremely easy to build and deploy Next.js yourself??
You either:
- Build static files and host it like any other framework (e.g. throw it in an S3 bucket)[0]
- Or, run a Node.js server
Where’s the Vercel exclusive part there?
[0] Here’s me doing exactly that, going through the same steps I would for literally any Frontend framework, including the WASM alternative I also build in the post (exact same deployment) https://codetalk.io/posts/2023-10-16-the-stack-part-3.html#n...
It’s really annoying / impossible to implement all the fancy caching, incremental revalidation, etc if you need to run more than one instance to serve the load you get. Or you need a horrendously complex AWS buzzword graph that will kinda sorta do the things. We switched from AWS ECS deployment to Vercel after tiring of figuring out how to support Next features that require very tight cooperation from CDN/distributed cache magicks.
The total product is good, the web presence team is happy with Next and Vercel, I’m liking RSC and server actions, but I wanted to share my experience that beyond modest scale running Next yourself needs a lot of effort.
> We switched from AWS ECS deployment to Vercel after tiring of figuring out how to support Next features that require very tight cooperation from CDN/distributed cache magicks.
I guess that's how they get you, by making it onerous to self host and instead offering a clean yet more expensive solution.
Site predates Astro, Remix, etc. There was some interest in Gatsby but I said no (seems horribly over engineered, adds GraphQL for no good reason, like storybook promises a lot but seems to leave the team doing extreme amount of npm upgrade work).
I think Next was the clear winner, we knew what we were getting into with hosting it to some degree and it was still worth because of how well it fits the team.
Well that's the problem, you will not see the glass wall until too late. For my case, that you can add API middleware, but you can't run any "not edge compatible" code because of Vercel reasons.
It's easy but there are decisions made that hamstring you - like being unable to change cache-control headers in the next.config.js or middleware or have your middleware use node APIs, which is especially stupid because when self-hosting... it's running in node!
They are optimizing for deploying to the edge, which when self hosting you don't need to.
So whether malicious or not, their guard rails conveniently make it frustrating to self host once you need to do anything outside of their garden.
We put nginx in front to manage the cache headers.
My biggest gripe is that they made design decisions that are optimized for their paid products, at the expense of the open source. Middleware is the main example, because it has to run on their edge.platform, it has no routing association. For all the magic they do, they dropped the ball here, making you use regex to decide of middleware should be applied. All this because users were getting hit with surprise bills, which is.really a product of who they architected and charged, not a technical issue
I never claimed middleware doesn't work when self hosting. I claimed that it's not as useful as it could be, because your company has prioritized edge deployments over supporting self-hosting.
As someone in that discussion rightfully says: "We are grown-ups with access to the same tracing and profiling tools as you. There is nothing dangerous about us using Node.js as far as I’m concerned."
Additionally, your comment just reeks of PR to me. I don't know if you do it on purpose or what, but to read my comment and then come back with "Middleware works when self hosting"... it has to be intentional on your part to misunderstand my comment that badly.
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.
It's good practice to introduce strong biases at the top of articles so readers can take that into consideration right away.
The article they are responding to did precisely that on their second paragraph:
> I’ve been using Remix since it was first released in 2020. I loved it so much I joined the team for 10 months to help get the community going and now I recommend and teach Remix on EpicWeb.dev. [1]
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.
There’s a two simple reasons I would go for Next.js
- It’s React-based: Almost everyone knows how to do React these days
- It allows me to build and serve chunked static files, instead of just a single static files like classic SPA
The last part is the main reason for that over other React-based frameworks. While SSR is hot these days, I’m firmly in the camp of “less servers I need to operate is better” and almost have “needs to be servable via S3+CloudFront” as a hard requirement for Frontend stacks.
Is anyone just using vanilla React with no TypeScript or Framework of any kind? I’ve tried Remix and Next js and just find them so cumbersome. Typescript causes me more headaches
Typescript is a real pain, I’m still trying to figure out why it’s so popular. The constant nagging and extra typing (no pun intended) when using it vs regular JavaScript makes it a pain. Then, there’s the extra parsing step to change it back to JavaScript. Idk I don’t see the value yet.
Edit: I say “parsing step “ because that’s what it is. There’s no “compiling” and “transpile” is just a ridiculous way of saying parse and output.
Just to add some color to this… values come in from the DOM as strings or numbers or booleans. They go out over HTTP as strings. (These are approximations, I’m going from memory.) The question then becomes: Should I inspect the values or just pass the values along? You can see how a simple form might just collect data and pass it along to a backend, maybe do a bit of cursory inspection of the values to make sure they’re in range. A sophisticated web app, on the other hand, might construct an in-browser-memory model from the data, and so needs to vigorously ensure that the data is correct. In the first case types can be a pain since you’re not telling the compiler anything that isn’t already well understood. In latter case they’re a necessity.
I love types I just struggle with Typescript a lot because it seems to get in the way for me. I might like it more if I buckled down and really tried to figure it out. It’s probably the slowest language for me to grasp maybe outside of Objective C.
When you try to enforce typing on a language that wasn’t designed ground up with types in mind it just rubs me the wrong way. Python type hinting strikes a good balance though.
Yes, I am, all the best devs I know are, and I honestly believe it's the 10x play right now.
Since 2016 I've seen reasonably large enterprise SaaS projects with similar scopes go from $5M builds to $50M builds without anyone else batting an eyelid. I have no idea what's going on in the industry at the moment.
React, Express, node-postgres. It worked 7 years ago. It works now. I can't even remember the last time I got stuck implementing any kind of business requirement with that very basic stack. Compare that to my day-to-day in 2023 where I'm spending hours every day fucking around with old stack overflow posts and shitty documentation trying to get TS/Next/Gatsby/NestJS or whatever else working.
Yeah, even for my simplest projects, like single-file scripts directly modifying HTML, I'll use `tsc` to compile .ts into .js, just so that I can get better IntelliSense while I'm working
Why are you rushing on every comment critical of vercel?, I'm assuming you also work for them or you have been sponsored or taken money by them in their marketing department.
Judging from their latest release of Next.js, nothing has really changed or been done (except v0 which is cool which is besides the point from Next).
But the fact that I don't see an explicit disclaimer here and the framework is overhyped, I see this as an ad.
I'm using Next.js for a few reasons:
- SEO was the initial draw.
- First time doing real frontend web for prod, wanted to use React + MUI.
- Did not want to use Django, Rails, WASM, etc.
- I come from backend and devops (less a reason than a general note for context).
Right now, I'm most curious about DIY hosting in EC2 with Go (or Rust) instead of using Vercel.
This might seem old-fashioned in the days of ECS/EKS etc., but I'm really comfortable with EC2 and love the cost-savings and control (I build my own load balancers, NAT instances, reverse-proxies, health-checkers/deployment managers; saves a ton of money).
My last issue with Next was that when we were using SSR-mode with Server Components we couldn't change the env variables at runtime, unless the dev mode was enabled (otherwise it would just bundle them). We were deploying with Docker and needed for each deployment to have a different env variable. Sound like a simple task, until it's not
Are you being ironic? If not: Rails is most certainly an option, if building web stuff is your goal.
I think it's lame how bad the documentation around it is 40 years in, which I can kind of forgive because of how well thought out and complete pretty much everything is, once you figure it out.
That is not to say that there aren't very sensible JS options – for example AdonisJS is well long running, constructed and feature complete TS backend framework, that has little traction – only that the community seems to value excitement and Apple marketing techniques to the point, where even their darlings core concepts are so absurdly unstable, that it feels insane to start any reasonably sized project with it.
The problem with Rails is that I don't know Ruby. It's a different ecosystem than the one I'm used to (Node). I'm also not aware whether Ruby comes with built-in type-safety, which is a requirement for me. Another requirement besides type-safety is JavaScript on the frontend and TailwindCSS for styling
I’ve been learning more of these stacks and found out about remix here in the nextjs release 14 thread. Remix seems pretty ok so far but I don’t have super strong feelings on nextjs either, it seems to work for me. I’m functioning as a system liaison at work for a team on nextjs which was my first exposure to it. That got my interest so I’ve been exploring front end frameworks lately. I would give remix a shot.
I've tried Remix and Astro, but I found it was too hard to even get started. SvelteKit looked interesting, but I didn't like the syntax. Nuxt with Tailwind has been my current go-to for last couple years, so seems like it might not be changing any time soon
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