There's been shockingly little mainstream change in how we write apps in the browser. Not a lot of frameworks have stepped up to present interesting new compelling capabilities. To Alex's point: it's not just that the customer doesn't know what they're buying, it's that there's not much significant difference between the goods (frameworks) and most get us to similar ends.<p>Mainly I think this boils down to there not being much actual innovation. Usually whatever framework you pick is fine: so long as it has sticking power/can survive, it probably won't get too far in the way, and it probably won't really provide a major boost other than giving you some frame of reference to adhere to, some theme to riff off of. Sometimes frameworks overreach, promise to much, and collapse, sometimes they whither, but a huge amount stick around & just keep doing what they're doing, and few have real differentiating power. Although they are all written in their own distinct opinionated styles, they're usually not very important.<p>Here's some topics we could be making head-way on to make webapps better: incremental loading, early hints, url based routing, service-worker services, off-main thread services. There's more experimental areas: custom elements, p2p data-channels, offline capable apps. Web Share & Web Share Target and protocol handler capable apps. Multi-window placement apps, PIP apps. Reactive systems (mobx). IoC/Dependency Injection. WebBundles/WebPackage, Signed Exchanges, Http Signatures. Some of these wander far from the central core of what a framework might need, but others could be compelling dynamic parts. But the current position of frameworks, what they consider their purview, is very narrow. Personally I think the modern client stack should look a lot more like a web-server than it presently does.<p>Right now we still write code like it's a process, but the web browser is really a multi-process environment. We have yet to see frameworks that really take that possibility & aim for it. One of wasm's most interesting possibilities is that we end up not with big processes ported to wasm, but lots of smaller littler independent processes communicating: I think the server-side people have thought about that, are excited for those very lightweight virtual machines, but I don't see the front end as thinking about how to decouple & unbundle & un-monolithize their front-end. There's ideas of portals and front-end microservices, but these are still often talking about fair conventional webapp architectures, just having many at once: they don't tackle or think about interconnection & shared services, about a network of front end microservices/microapps.<p>The whole SSR thing is interesting & good work is happening to reshuffle & re-explore, but again, I just think interest arose here in part because the client-side failed to keep pioneering & failed to be exciting, so this was just an open/available other place to go explore. And while it has lots of virtues, I don't think it's actually that exciting or important, not nearly as much as improving the client-side, where the user agency is actually seated. The frameworks need to expand, especially client side. We all got safe & conservative, started to apply the industrialized tools that work, and the hotbed of exploration & innovation got demolished, was squelched. And we all had our energy sapped figuring out how to build & bundle our stuff, via endless tooling, which we still are only so so ok at (still nothing would be a nice/easy as an EcmaScript Modules that would just work with source-as-it-is-authored, which Deno seemingly sort of pulls off, but the web is still far from).