I am not impressed with Next.js or Lee's evangelism (yes, in the religious sense) of their platform. Being forced to develop in Next.js for a major project was the last straw, and convinced me to abandon the Javascript/Typescript/Node.js ecosystem entirely for future web projects (where I have the choice). Dev-fluencers and Next.js evangelists who gish-gallop and provide (non)-responses to serious developer problems with Next.js convinced me that Vercel is building an elaborate cash grab, on the enterprise scale, and securing vendor lock-in for many years to come. Don't tell me that Next.js is easy to deploy in Docker either - it's not, I wrestled with that implementation for months and it was fragile/broken in a way that I suspect a native Vercel-deployment is not.
The current stack I'm using is Django/Python, HTMX, Alpine.js, and TailwindCSS. Yes I know the middle two use Javascript under the hood, there is no way around that for client interactivity. But they do support the HATEOAS principal (https://en.wikipedia.org/wiki/HATEOAS) which has been a breath of fresh air imo. The book "Hypermedia Systems" is also a great way to achieve the mental reset needed to abandon modern web frameworks and go back to things that actually work, in terms of web development.
Next.js has many weird bugs and things that just... don't work and when you hit these edge cases and a >5 year old open GitHub issue you know you will spend the next two weeks searching for another way or just abandoning it because it doesn't work. Got burned out hard by Next.js while rewriting a very old project - it worked in the end and I was proud of it but just using something... simpler would've been better. Deploying Next.js outside Vercel is hell, too...
Also tried SvelteKit (with Svelte 4) which was quiet nice but it completely misbehave in production with a lot of corner-case bugs that were not reproducable in development and I abandoned it for good. Didn't the creator of Svelte even joined Vercel? They seem to want to "unite" all the JS frameworks "under one roof" which I find a bit... disturbing?
I'm not saying that Next.js is good or bad but we deploy our Next.js app in a docker container and it's never been an issue. I'm curious what issues you had?
It's been a year since I was on the project and have since forgotten. I remember it being related to configuring security and middleware with the granularity required by a high-security client. There were other things too that were very hard to configure as soon as you stepped off the Dockerfile template provided by Next.js documentation.
I do like templates for simple pages - but with ai now. Its pretty fast to build out your api completely with drf. Then autogen the api in vite. Once you have all of your types and queries auto created. You can pretty much 'vibe' code your UI how you see fit. Then leave django to handle everything data/backend.
But if HTMX is enough for your project, then your problem was picking the wrong tools from the get go. You didn’t even need react. They’re very different tools for very different kinds of UIs and frontend complexity.
I like hateoas as a concept but how can you maintain that in production scale???
we need to maintain access control and output that in client which is good but that move bulk of engineering into backend that would harder and harder given many scenario noo???
This is a good writeup, but the VP learnings/mistakes (#3, 4 and 5) honestly felt pretty amateur mistakes for any leadership position ... even for just a junior managerial role. It's a good thing they were able to learn on the job, but the team could have used a more seasoned leader - or the author could have had more pre-training/coaching.
I'd add, if feature A can't be shipped 10x faster, ask the same question about features B, C, and D and then redo your ROI calculations, before deciding to invest in feature A.
That keeps the team consistently delivering and motivated, and gives you more time to think about feature A. Some features are really important to get right and take the appropriate time, and some are just important to ship. Having that distinction explicit allows the team to maintain good shipping velocity without accruing "high interest" tech debt.
Also there's obviously no single correct ratio here. Newer companies, services, teams, products will probably lean toward shipping fast since architecture is still being defined (and too much architecture could be more detrimental than tech debt / too little architecture, if it doesn't match future requirements), whereas more mature ones will be more willing to sacrifice shipping velocity for better fit with the existing domain model.
Only been on a handful of react projects at this point: gatsby, next.js, and remix, in that order.
Gatsby was fine for the time for our static marketing site. Not really good but not painful. Then we started converting our SPA to next.js and a deep seated rage for react began to fester in me.
After being forced to use react at my current job and convincing leadership to go with remix, it turns out I don't hate react THAT much, mostly just next.js. As far as I'm concerned, next.js and vercel are the same and they're both not great.
Leerob, thank you for your patience and help on Reddit community! The NextJS gets a lot of criticism these days but you helped a lot of people, with self-hosting NextJs and other tricky questions.
Jumping onto a Next.js project right now that has no reason to have SSR. The code is now excessively complex, difficult to detangle, and I can't believe how bad the local DX is on a cold start on an M1 MBP. It's so slow; every nav is agonizing. Maybe it's how this is configured, maybe it's some other issue, but I definitely didn't encounter this with OOB stock Nuxt.js and of course, this project is an app that has no reason nor benefit for using Next.js.
No idea how Vercel scammed so many people. Founder paid an annual contract of $##,### to Vercel for what should be a freely hosted static web app + freely hosted (within credit boundaries) backend in a serverless container (e.g. Google Cloud Run, Azure Container Apps, etc.)
Hey that's short selling them, they also managed to make HTTP middleware not work like you'd expect in nextjs which has some arcane advantage when hosted on Vercel.
Indeed; I remember watching one of their tech sessions around the Next.js 12 to 13 release and then watching a Microsoft one. One was very clearly a marketing ad.
We shortly ditched Next.js afterwards because of how janky the whole DX was the entire time and how much worse it was during the transition.
Now I'm back in a Next.js 15 project and it's amazing that the DX somehow feels even worse!
Yes, of course, it has SSG and ISR as well, but then you are overall better off with something else like a VitePress for fully static, React + Vite if you still want React and build a static app, or use Astro.js if you need some client side reactivity.
Next.js is a lot of marketing for a terrible product.
You can't comment like this on Hacker News, no matter who or what you're replying to. Please take a moment to read the guidelines and make an effort to observe them in future.
You are right but it is hard to not go overboard when talking about nextjs/vercel. I am in IT 50 years now and so terrible 'tech', I could not have predicted. With so many critical security issues that 'do not affect vercel users', you have to wonder what fresh hell this is.
> thanks for contributing to the slopification of the web
This is against the guidelines, and the other sentence I won't repeat is also. Please only comment here if you want to make an effort to observe the guidelines.
The second one you could word better, I feel the intention is to be “phobic”, but I will assume your point is to really understand the demographics, so probably Vercel is more startup and small projects side?
> thanks for contributing to the slopification of the web
what was the demographic of the users of vercel (its 90% indian no?)
The enshittification isn’t because of a particular tool or technology. It stems from the way it’s used. As for the demographic comment, shame on you. Don’t be so pea brained.
I am not impressed with Next.js or Lee's evangelism (yes, in the religious sense) of their platform. Being forced to develop in Next.js for a major project was the last straw, and convinced me to abandon the Javascript/Typescript/Node.js ecosystem entirely for future web projects (where I have the choice). Dev-fluencers and Next.js evangelists who gish-gallop and provide (non)-responses to serious developer problems with Next.js convinced me that Vercel is building an elaborate cash grab, on the enterprise scale, and securing vendor lock-in for many years to come. Don't tell me that Next.js is easy to deploy in Docker either - it's not, I wrestled with that implementation for months and it was fragile/broken in a way that I suspect a native Vercel-deployment is not.
The current stack I'm using is Django/Python, HTMX, Alpine.js, and TailwindCSS. Yes I know the middle two use Javascript under the hood, there is no way around that for client interactivity. But they do support the HATEOAS principal (https://en.wikipedia.org/wiki/HATEOAS) which has been a breath of fresh air imo. The book "Hypermedia Systems" is also a great way to achieve the mental reset needed to abandon modern web frameworks and go back to things that actually work, in terms of web development.
Next.js has many weird bugs and things that just... don't work and when you hit these edge cases and a >5 year old open GitHub issue you know you will spend the next two weeks searching for another way or just abandoning it because it doesn't work. Got burned out hard by Next.js while rewriting a very old project - it worked in the end and I was proud of it but just using something... simpler would've been better. Deploying Next.js outside Vercel is hell, too...
Also tried SvelteKit (with Svelte 4) which was quiet nice but it completely misbehave in production with a lot of corner-case bugs that were not reproducable in development and I abandoned it for good. Didn't the creator of Svelte even joined Vercel? They seem to want to "unite" all the JS frameworks "under one roof" which I find a bit... disturbing?
Nuxt joined Vercel earlier this week too - https://vercel.com/blog/nuxtlabs-joins-vercel
I believe all the core contributors to Svelte and SvelteKit are employed by Vercel.
I'm not saying that Next.js is good or bad but we deploy our Next.js app in a docker container and it's never been an issue. I'm curious what issues you had?
It's been a year since I was on the project and have since forgotten. I remember it being related to configuring security and middleware with the granularity required by a high-security client. There were other things too that were very hard to configure as soon as you stepped off the Dockerfile template provided by Next.js documentation.
Love django. Its my go-to as well.
I have gone django, drf, heyapi + vite/react.
I do like templates for simple pages - but with ai now. Its pretty fast to build out your api completely with drf. Then autogen the api in vite. Once you have all of your types and queries auto created. You can pretty much 'vibe' code your UI how you see fit. Then leave django to handle everything data/backend.
I agree with your opinion on vercel and next.
But if HTMX is enough for your project, then your problem was picking the wrong tools from the get go. You didn’t even need react. They’re very different tools for very different kinds of UIs and frontend complexity.
I like hateoas as a concept but how can you maintain that in production scale???
we need to maintain access control and output that in client which is good but that move bulk of engineering into backend that would harder and harder given many scenario noo???
Plane with holes in wings returns to base, encourages engineers to reinforce wings to prevent holes.
This is a good writeup, but the VP learnings/mistakes (#3, 4 and 5) honestly felt pretty amateur mistakes for any leadership position ... even for just a junior managerial role. It's a good thing they were able to learn on the job, but the team could have used a more seasoned leader - or the author could have had more pre-training/coaching.
I'd add, if feature A can't be shipped 10x faster, ask the same question about features B, C, and D and then redo your ROI calculations, before deciding to invest in feature A.
That keeps the team consistently delivering and motivated, and gives you more time to think about feature A. Some features are really important to get right and take the appropriate time, and some are just important to ship. Having that distinction explicit allows the team to maintain good shipping velocity without accruing "high interest" tech debt.
Also there's obviously no single correct ratio here. Newer companies, services, teams, products will probably lean toward shipping fast since architecture is still being defined (and too much architecture could be more detrimental than tech debt / too little architecture, if it doesn't match future requirements), whereas more mature ones will be more willing to sacrifice shipping velocity for better fit with the existing domain model.
One of the best, or maybe the best, coding presenter I've ever come across on youtube.
Thank you!
Vercel raised $563M so far. Where do you think you guys would have been if you had bootstrapped?
Especially given that it's hosted on AWS.
(Reminds me of Heroku back in the day as being another "hosting" sold & layered on top of AWS)
Only been on a handful of react projects at this point: gatsby, next.js, and remix, in that order.
Gatsby was fine for the time for our static marketing site. Not really good but not painful. Then we started converting our SPA to next.js and a deep seated rage for react began to fester in me.
After being forced to use react at my current job and convincing leadership to go with remix, it turns out I don't hate react THAT much, mostly just next.js. As far as I'm concerned, next.js and vercel are the same and they're both not great.
Leerob, thank you for your patience and help on Reddit community! The NextJS gets a lot of criticism these days but you helped a lot of people, with self-hosting NextJs and other tricky questions.
Jumping onto a Next.js project right now that has no reason to have SSR. The code is now excessively complex, difficult to detangle, and I can't believe how bad the local DX is on a cold start on an M1 MBP. It's so slow; every nav is agonizing. Maybe it's how this is configured, maybe it's some other issue, but I definitely didn't encounter this with OOB stock Nuxt.js and of course, this project is an app that has no reason nor benefit for using Next.js.
No idea how Vercel scammed so many people. Founder paid an annual contract of $##,### to Vercel for what should be a freely hosted static web app + freely hosted (within credit boundaries) backend in a serverless container (e.g. Google Cloud Run, Azure Container Apps, etc.)
A complete scam.
I guess the branding and marketing worked.
Last time I checked Vercel was just reselling services of AWS.
Hey that's short selling them, they also managed to make HTTP middleware not work like you'd expect in nextjs which has some arcane advantage when hosted on Vercel.
We shortly ditched Next.js afterwards because of how janky the whole DX was the entire time and how much worse it was during the transition.
Now I'm back in a Next.js 15 project and it's amazing that the DX somehow feels even worse!
They introduce a lot of shiny half-baked features while abandoning old ones.
NextJS now is unecessary complex, and there are things to avoid to make sure everything works fine.
I am not sure why it is so slow for you, maybe you you can try run this boilerplate (work in progress to make it easy to use)
https://github.com/wizecore/boilerplate-saas/
It uses Pages router, comes with local postgres, redis and AWS sqs emulator. No docker, no cloud needed for it to work locally.
Such setup is crazy fast on my mbp m2 pro.
You don't have to use SSR: https://nextjs.org/docs/app/guides/static-exports
Yes, of course, it has SSG and ISR as well, but then you are overall better off with something else like a VitePress for fully static, React + Vite if you still want React and build a static app, or use Astro.js if you need some client side reactivity.
Next.js is a lot of marketing for a terrible product.
Thank you, I appreciate that.
I've never worked at a startup that hit it big, so I came in wanting to disagree with whatever was in this post.
But I liked it. Now I'm mad.
leerob is so active in the space that I didn't realize until reading this that he isn't Vercel's founder.
Well written Lee; and 100% on point. So very true. Much thanks for moving the needle and good luck on what's next.
[flagged]
Sort of conflicts with the other points though, which basically sum up to "Be a 10X developer or die trying"
The whole thing is affirmational in the jacket of happy warrior. Self consistency was never the point.
The conflict is resolved by realizing that points 2 and 3 aren’t valid.
P O W E R F V L
[flagged]
You can't comment like this on Hacker News, no matter who or what you're replying to. Please take a moment to read the guidelines and make an effort to observe them in future.
https://news.ycombinator.com/newsguidelines.html
You are right but it is hard to not go overboard when talking about nextjs/vercel. I am in IT 50 years now and so terrible 'tech', I could not have predicted. With so many critical security issues that 'do not affect vercel users', you have to wonder what fresh hell this is.
[flagged]
> thanks for contributing to the slopification of the web
This is against the guidelines, and the other sentence I won't repeat is also. Please only comment here if you want to make an effort to observe the guidelines.
A racist one? No, you can't
What is even the point of your first sentence?
The second one you could word better, I feel the intention is to be “phobic”, but I will assume your point is to really understand the demographics, so probably Vercel is more startup and small projects side?
> thanks for contributing to the slopification of the web what was the demographic of the users of vercel (its 90% indian no?)
The enshittification isn’t because of a particular tool or technology. It stems from the way it’s used. As for the demographic comment, shame on you. Don’t be so pea brained.
[flagged]
[flagged]
> radical deadline compression
lol