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.<p>Not to mention this stack can be deployed literally anywhere with great ease.
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.<p>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.<p>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.
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.
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.<p>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.<p>Now that LLMs write code, it probably is not be as big of an issue though.<p>Still would not wish next upon any of my enemies.
Similar experience, started in the page router days.<p>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.<p>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 feel like solid-js is in a good place to be a platform
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
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.
Wishing for the day it stops being the darlings extension framework for SaaS vendors in the MACH ecosystem [0].<p>At least the whole headless, DXP hype cycle seems to be wanning down, so maybe we get proper SDKs back.<p>And while we're at it, what about porting Next.js into Next.rs, and remove all that "use nonsense"?<p>[0] <a href="https://macharchitecture.com/" rel="nofollow">https://macharchitecture.com/</a>
'use cache' works at the function level as well and is very handy to reduce scaling bottlenecks in a pinch.
Every time next.js ships something new, I remember the cliché xkcd comic of competing standards and smile a little bit.<p>They have extremely good engineers, but product/feature management can really benefit from some self-reflection :)
Svelte and its kit are a much better dev experience
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.<p>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.<p>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)<p>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.<p>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.<p>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.<p>I even have tons of really strong deterministic guardrails for people vibecoding:<p><pre><code> Before you commit, run mix precommit and make sure it's green.
</code></pre>
And mix precommit is:<p><pre><code> precommit: [
"compile --warnings-as-errors",
"deps.unlock --unused",
"format",
"credo --strict",
"ex_dna",
"reach.check --arch",
"dialyzer",
"test"
]
</code></pre>
Credo has <a href="https://github.com/elixir-vibe/ex_slop" rel="nofollow">https://github.com/elixir-vibe/ex_slop</a> added to it.<p>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]