Why I'm using Next.js
leerob.io
leerob.io
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.
Fixing bugs is down to priority and incentives of the parent company.
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)
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.
But yes at the end of the day you're right.
- 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.
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...
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.
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.
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
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.
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.
I guess that's how they get you, by making it onerous to self host and instead offering a clean yet more expensive solution.
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…
If it runs in the browser, it's frontend. Server? Backend.
There's SSR but the name itself clarifies: Server Side Rendering.
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.
- 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.
While other SPA frameworks are supported, they are a kind of second line, without all the bells and whistles that Next.js users are given to enjoy.
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.
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.
It reads that Vercel told him to do this because he works there rather than him responding on his own accord.
I don't see a 'DISCLAIMER: I WORK AT VERCEL' at the top on here, so I assume this reads like an ad.
Pot, kettle?
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.
In the post:
> I'm Lee. I work on Next.js.
On the homepage:
> I lead the community for Next.js
I still don't see this anywhere at the top of your website and not deceptively hidden and buried on your website.
Also:
> I'm Lee. I work on Next.js.
> I lead the community for Next.js
Isn't explicit, there are a few open source contributors who work on Next.js but don't work at Vercel.
So my point still stands on this being an ad for Vercel.
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).
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.
How have all these other developers been managing this whole time without Next?