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.
One of the things I 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'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.
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.
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.
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.
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.
Shame but also opportunity... These apps will not be good, they will look good and appear to work, but then... they will need to be rewritten.
I am often posting that if you pick Gleam for UI, Rails or Phoenix, which will make your codebase easier to follow and more stable, I will give you discounts.
Gleam as a language is genuinely underrated for porting.
I had made a Golang htmx + templ codebase and just out of curiosity I ported it onto gleam using an open weights model (glm 5.3)
Although it struggled a little bit first because of learning some parts of gleam but overall after it searched for documentation and learnt some things on its own, it was able to completely rewrite it in just 1/2 very small prompts which is crazy.
I think phoenix can be great as well and I am doing an experiment to try to port it to many functional languages and just testing which language is the best for it but so far I am impressed by gleam!
Have faith, you can be the change you want to see.
At my new job we needed a robust platform for executives and ops people to vibe code in. I created the project using latest Phoenix and everything works flawlessly. We get so much for free, hosting is peanuts, and iterating is easy for the AIs.
I even have tons of really strong deterministic guardrails for people vibecoding:
Before you commit, run mix precommit and make sure it's green.
Yeah, I’ve got a “mix quality” task that includes that one and the dup one and skill that points at it, keeps the codebase cleaner that I could manually even before llm era. I’ve thought about building something that can detect if helper functions in a module are generic enough to consider refactoring out to an app-wide helper module, that continues to be an annoyance.
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.
Same here.
One of the things I 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.
Still would not wish next upon any of my enemies.
Similar experience, started in the page router days.
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.
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.
Their act together was keeping improving pages router, with api routes for server side code.
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.
I have had some very nice experiences with the app router, but I see what you mean.
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 feel like solid-js is in a good place to be a platform
[dead]
Hard to call it a "unified platform" when a good portion of the developer base is using pages router despite app router being out for a few years now
Wishing for the day it stops being the darlings extension framework for SaaS vendors in the MACH ecosystem [0].
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/
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.
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.
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.
'use cache' works at the function level as well and is very handy to reduce scaling bottlenecks in a pinch.
Wow that’s so gross! Just put a random unassigned string in your function and it changes behavior completely. Bonkers.
Yes, since the whole app router and React Server Components it feels like Perl's magic strings.
Maybe these folks have rediscovered some mod_perl books.
It's not random though, and the good old 'use strict' directive also changes the behavior quite a lot.
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.
SaaS SDKs that only support Next.js, for example,
https://www.contentful.com/developers/docs/tutorials/preview...
Svelte and its kit are a much better dev experience
Every time next.js ships something new, I remember the cliché xkcd comic of competing standards and smile a little bit.
They have extremely good engineers, but product/feature management can really benefit from some self-reflection :)
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.
Shame but also opportunity... These apps will not be good, they will look good and appear to work, but then... they will need to be rewritten.
I am often posting that if you pick Gleam for UI, Rails or Phoenix, which will make your codebase easier to follow and more stable, I will give you discounts.
Gleam as a language is genuinely underrated for porting.
I had made a Golang htmx + templ codebase and just out of curiosity I ported it onto gleam using an open weights model (glm 5.3)
Although it struggled a little bit first because of learning some parts of gleam but overall after it searched for documentation and learnt some things on its own, it was able to completely rewrite it in just 1/2 very small prompts which is crazy.
I think phoenix can be great as well and I am doing an experiment to try to port it to many functional languages and just testing which language is the best for it but so far I am impressed by gleam!
Have faith, you can be the change you want to see.
At my new job we needed a robust platform for executives and ops people to vibe code in. I created the project using latest Phoenix and everything works flawlessly. We get so much for free, hosting is peanuts, and iterating is easy for the AIs.
I even have tons of really strong deterministic guardrails for people vibecoding:
And mix precommit is: Credo has https://github.com/elixir-vibe/ex_slop added to it.It's really great, try it out.
Yeah, I’ve got a “mix quality” task that includes that one and the dup one and skill that points at it, keeps the codebase cleaner that I could manually even before llm era. I’ve thought about building something that can detect if helper functions in a module are generic enough to consider refactoring out to an app-wide helper module, that continues to be an annoyance.
[flagged]
[flagged]