Vercel finally admitted App Router caching was broken, shifting to explicit 'use cache' directives and ensureStatic build guards. Only took four minor versions for basic determinism.
It’s a shame that the LLMs default to Next when vibe coding instead of something serious like Phoenix. Then again, maybe it’s a good thing - all of the sloppy copies of my saas are complete dumpster fires and only going to slow them down.
It's a shame that some asshole liek this diss nextjs instead of bringing something contructive to the announcement. Then again, maybe it's a good thing - all of the assholes like cpursley are complete dumpster fires and will only slow web development community down.
Never heard of Phoenix. Went to their webpage and saw "Phoenix is the most loved web framework for the third year in a row.". That's some fart-huffing kind of thinking going on there. Sure, it may be great, and some people may love it, but this statement is just a huge turn-off. It's like they're desperate to be seen as being loved. You don't have to say something like this if it's actually true.
Okay, so I clicked "See results", and it's just as stupid.
"While its overall usage is still smaller than almost all other web frameworks in the survey, Phoenix's key story is in its developer satisfaction. It is the most admired web framework in 2025 (79%), and has been since 2023."
One of the things I have liked about Next is that it presented a “unified platform” instead of the fragmented sea of hacks that is web development. Eg. I was initially taken aback by having to use a special component for images but then it made sense when I realized the platform handles image optimization and stuff like that for me.
But over time I lost the ability to reason about my Next code almost completely. Sometimes it’s the caching, sometimes it’s some little arcane code differences that turn my route into an unexpected type. There is some logic behind it, I can respect that, but I no longer have a coherent mental model of what the framework / the platform does.
It feels like the reality that the abstractions are trying to cover is too wild not to break through at places. Which, I guess, is just web. But it’s a pity, it felt good to have a saner, simpler platform to develop for in older versions of Next.
I have used next in a pretty large application. Also built decently large things with base react (vite), vue (nuxt). Also small stuff using other platforms.
Next is by far the worst thing ever. Everything is broken in a weird way and the deeper you dig into it deeper it starts biting back. It was the only thing I dreaded maintaining.
Now that LLMs write code, it probably is not be as big of an issue though.
I still hope they will get their act together in the latest releases, after all server components were a huge shift with a lot of rough edges to figure out.
There are some people who see the web as a platform, and some people who see a web browser as a window for zero-install applications to draw into. There have always been people in the latter group who try to abstract everything away, but it does tend to discard pretty much everything that makes the web great.
A lot of what Next does/did _is_ leaning into web’s strengths. It was Next that made me declare image size beforehand, for example, drastically reducing layout jumps. It also made image optimization almost effortless, greatly improving load times for my websites. The web as a platform is a nice concept I would love to adopt more, but then I need to write some server-side code and I am completely on my own. Pushing the DX around the client/server boundary is one of the things that made Next great for me.
I still much, much prefer the page router. The caching model is much simpler. Shame that they hired all the open source react maintainers and now nothing other than Tan stack gets developed.
I've found Vite + React SPA ( Tanstack Router/Query) with a Nodejs/Fast API to work so simply and so easy to reason about. The entire SSR and caching etc. thing adds a lot of mental overhead.
Not to mention this stack can be deployed literally anywhere with great ease.
Completely agree. I've had to work with NextJS the past three places I've been and I hate it. I get that there are certain use cases where you want SSR, I guess like an e-commerce site where everything is dynamic but the user isn't logged in and you want SEO. But for a regular SPA, running Vite with a simple router (I like https://kyeotic.github.io/raviger/) is orders of magnitude simpler to work with.
My favorite combo is NextJS with static export and fastapi backend. Last three years I’ve done countless projects like this, now I just go forward with muscle memory.
For python just get SQLModel (that is basically SQLAlchemy + pydantic), alembic, develop in hexagonal architecture (or just follow the advanced architecture pattern with Python book) and that’s it.
For frontend, just go with tailwind, shadcn, tanstack...
Maybe in 10 years people will look at these technologies as I look at Oracle/JEE today, but they are making me so happy.
who even cares at this point, with LLMs you can just build exactly what you want without needing to worry about all the constraints a framework imposes on you. the benefits of frameworks are mute now, and you just end up with the downsides.
> The live preview SDK works with JavaScript and has optimized integration for any React.js framework (like Next.js). To see the examples for different frameworks, refer to the live preview SDK.
pretty sure any llm from the last 6 months could wire that SDK into whatever custom setup you're running
it's all about tradeoffs, you could also gain a lot by using a targeted custom approach. devs spend a lot of time dealing with managing frameworks and dependancies as well.
ime the hardest thing is convincing people with your mindset. it's completely valid, i understand it and this isn't meant as a criticism. at my company i'm convinced we could be moving about 10x faster by abandoning some previously held notions about best practices related to this. i could be wrong, but i'd like to at least try.
35 comments
[ 0.28 ms ] story [ 49.6 ms ] threadOkay, so I clicked "See results", and it's just as stupid.
"While its overall usage is still smaller than almost all other web frameworks in the survey, Phoenix's key story is in its developer satisfaction. It is the most admired web framework in 2025 (79%), and has been since 2023."
Stackoverflow hasn't been relevant in years.
But over time I lost the ability to reason about my Next code almost completely. Sometimes it’s the caching, sometimes it’s some little arcane code differences that turn my route into an unexpected type. There is some logic behind it, I can respect that, but I no longer have a coherent mental model of what the framework / the platform does.
It feels like the reality that the abstractions are trying to cover is too wild not to break through at places. Which, I guess, is just web. But it’s a pity, it felt good to have a saner, simpler platform to develop for in older versions of Next.
Next is by far the worst thing ever. Everything is broken in a weird way and the deeper you dig into it deeper it starts biting back. It was the only thing I dreaded maintaining.
Now that LLMs write code, it probably is not be as big of an issue though.
Still would not wish next upon any of my enemies.
Nowadays no idea what they are trying to do with it, I rather be dropped into a random Spring or ASP.NET project, or even C, than Next.js.
Sadly it is the new darling of SaaS cloud products as extension SDK and deployment partner, and thus the only way to some consulting gigs.
The closest any JavaScript framework had come to Java and .NET frameworks, battle tested in production for almost 30 years now.
It has been downhill since app routing was introduced.
At least the whole headless, DXP hype cycle seems to be wanning down, so maybe we get proper SDKs back.
And while we're at it, what about porting Next.js into Next.rs, and remove all that "use nonsense"?
[0] https://macharchitecture.com/
Maybe these folks have rediscovered some mod_perl books.
Not to mention this stack can be deployed literally anywhere with great ease.
For python just get SQLModel (that is basically SQLAlchemy + pydantic), alembic, develop in hexagonal architecture (or just follow the advanced architecture pattern with Python book) and that’s it.
For frontend, just go with tailwind, shadcn, tanstack...
Maybe in 10 years people will look at these technologies as I look at Oracle/JEE today, but they are making me so happy.
They have extremely good engineers, but product/feature management can really benefit from some self-reflection :)
https://www.contentful.com/developers/docs/tutorials/preview...
pretty sure any llm from the last 6 months could wire that SDK into whatever custom setup you're running
Spend project budget delivering features, or supporting in house custom implementation because the product SDK isn't being used for delivery.
ime the hardest thing is convincing people with your mindset. it's completely valid, i understand it and this isn't meant as a criticism. at my company i'm convinced we could be moving about 10x faster by abandoning some previously held notions about best practices related to this. i could be wrong, but i'd like to at least try.