I think the broad historical sweep here is sort of along the lines of:

* From the early microcomputer era onwards, applications development focused on getting developers that knew the base platform or operating system(e.g. if you knew "Win32" dev, that was solid in the mid-90's) - and it was one platform per category of application, and for applications that integrated a database you also had platforms like Foxpro, Access, or Hypercard. Specialization beyond that was typically the domain of big-iron computing, which had an older market and talent pool that was used to a certain model and infrastructure of scaling to solve the data processing needs of the era.

* Increased usage of computer networking pushed all development towards a multi-tier setup(e.g. LAMP stack or the multifarious forms of Java and .Net), meaning that more applications needed "front-end" vs "back-end" division, regardless of their needs. We addressed the problem at a local level by gluing together big-iron concepts and microcomputer concepts to get an awkward-yet-servicable jumble of domain competence, with the Web as the dominant frontend. A very small number of Internet companies pushed the boundaries and set the standards on data processing and frontends, and the market followed in their footsteps and used their leftovers.

* Now that we have built out a lot of leverage towards all the possible speciality roles and computing is firmly in the hands of a few giants that can leverage all of that specialization, commoditization is creeping in and pushing smaller development teams back into more consolidated platforms. "The browser is the OS" is effectively true today, except that it's a terrible OS, scarred by numerous wars to control the platform and enable only specific categories of applications.

What developers are moving towards, but are having trouble reaching because of the sheer number of established layers and protocols and required features, is another Hypercard that consolidates concepts into a single consumable, more uniform package, without requiring you to know all the boundaries and sharp edges that exist when going between the JS type system, the SQL engine, the browser engine, serialization protocols, network conditions and hardware status, etc. This is not a project that can be accomplished by lightly papering over the existing systems with framework glue - it requires attention to detail to clean up and simplify each part of the whole. So it takes time.

But at the same time, I think we're also going to get where we want to go, faster than we think. The introduction of, and adoption of Web Assembly, is a major milestone because it raises the level of local processing and hence local platform consolidation, which in turn limits browser-specific APIs to importance in terms of their core I/O functionality, and not one-off standardized features. New platforms can carve out more and more space from that starting point, ultimately resulting in applications that have replaced the browser with a custom native runtime, but still ship WASM binaries.

Simultaneously, native code development is getting better. The bottom of the stack is getting attention after leaning heavily on the traditional C/Unix model for decades and accumulating features without major revision - Rust and systemd are two healthy(if polarizing) examples.

And at that point, the classical Open Web is dead, but it's due to be replaced in turn with a second coming of specialized, decentralized and federated protocols - new takes on Usenet, IRC, FTP, etc. The wheel will keep turning, though all the formats might churn.