[onion2k]

But that isn't because of the technology, it's because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that.

This is only sort of true. The problem can be mitigated to a large extent by frameworks; as the framework introduces more and more 'magic' the work that the developer has to do decreases, which in turn reduces the surface area of things that they can get wrong. A perfect framework would give the developer all the resources they need to build an app but wouldn't expose anything that they can screw up. I don't think that can exist, but it is definitely possible to reduce places where devs can go astray to a minimum.

And, obviously, that can be done on both the server and the client.

I strongly suspect that as serverside frameworks (including things that sit in the middle like Next) improve we will see people return to focusing on the wire transfer time as an area to optimize for, which will lead apps back to being more frontend than backend again. Web dev will probably oscillate back and forth forever. It's quite interesting how things change like that.

[tomca32]

Unfortunately, developers often write code in a framework they don't know well so they end up fighting the framework instead of using the niceties it provides. The end result being that the surface area of things that can go wrong actually increases.

[runlaszlorun]

True. But I also find that a lot of frameworks are narrowly optimized for solving specific problems, at the expense of generality, and those problems often aren’t the ones I have.

Supposedly declarative approaches especially are my pet peeve. “Tell it what you want done, not how you want it done” is nice sounding but generally disappointing when I soon need it to do something not envisioned by its creator yet solved in a line or two of general purpose/imperative code.

[CSSer]

Most companies unfortunately don't let developers adequately explore solutions or problem spaces before committing to them either. The ones that dominate do, but that's also because they often have the resources to build it from the ground up anyway.

The average mid-sized business seems to have internalized that code is always a liability, but they respond by cutting short discovery and get their just deserts.

[CSSer]

That oscillation probably wouldn't happen if it were possible to be more humble about the scope of the solution and connection to commercial incentives. It's gotten to the point where a rite of passage for becoming a senior developer is waking up to the commercialization and misdirection.

You can see the cracks in Next.js. Vercel, Netlify et. al, are interested in capitalizing on the murkiness (the middle, as you put it) in this space. They promise static performance but then push you into server(less) compute so they can bill for it. This has a real toll on the average developer. In order for a feature to be a progressive enhancement, it must be optional. This is orthogonal to what is required for a PaaS to build a moat.

All many people need is a pure, incrementally deployed SSG with a robust CMS. That could exist as a separate commodity, and at some points in the history of this JAMStack/Headless/Decoupled saga it has come close (excluding very expensive solutions). It's most likely that we need web standards for this, even if it means ultimately being driven by commercial interests.