At this point, I am convinced the problem is not web frameworks but browsers. Someone needs to take all the legacy bloat away and put it in the side while starting from the scratch. Web doesn't need three different languages. It doesn't need freedom that costs accessibility. It doesn't need to be so primitive.
It smells. Awful defaults.
import "reset.css"
import "reset.js"
</rant>
It will never happen, but I wish there was a second stack that browsers understood, totally separate from the DOM, purpose built for developing _applications_, rather than abusing the fact that this document creation tool allows us to put styled boxes in different places.
This is not really a failing of HTML, CSS, or JavaScript, but if your platform SDK's total feature set for building UIs amounted to some basic form inputs, incredibly inflexible tables, and a handful of ways to add semantics to otherwise featureless blocks of text and boxes, you'd be laughed out of the room. The fact that anything remotely feature rich must be built from scratch is part of the reason the ecosystem has such a bad rap for over reliance on packages, and for constantly reinventing the wheel.
The whole conversation ignores, for example, the reason that jQuery was invented: At a time when there were many competing browsers, all of which spoke different dialects of JavaScript (that's my punny way of saying that they had different bugs), HTML/CSS bugs that were all different across browsers... jQuery brought order to chaos.
And the problem is, that as browsers improved and got closer to general standards compliance (where we STILL ARE NOT today), they didn't remove the cruft and the past bad behavior - no, they continue to support code that implements that crappy API that was deprecated 15 years ago.
These problems continue today and as long as that is true - as long as fundamentally, the problem is the browser itself -- these frameworks will continue to have a place.
We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc.
But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense.
So, why do we just keep forcing it? If leveraging the ubiquity of the Web is the objective, then there's nothing to say we couldn't have a VM running in a browser that itself uses web protocols/languages, but abstracts them away. That would leave us writing code a la Swing, an event-driven, component-based model that makes so much more sense for a GUI style application. No CSS, HTML, fighting back-buttons, state management, routing, etc. That's all handled in the VM.
Because hyperlinked documents are the whole ball game. Web technologies are a pain in the ass for developers but a boon for the advancement of human knowledge and connectedness.
The great islands and continents of web space float in the same aether. They interconnect, despite being built at different times, in different styles, on different technologies. It all just, for the most part, works. It’s fucking beautiful.
The system is greater than the sum of its parts.
Keep the current browser stack for the things it still makes sense for - static content like articles and blogs, and forums too, but anything with greater complexity and reactivity would run faster and get better gains from just abandoning html/js completely, and browsers themselves could stem the unending march of feature creep.
I'm just spitballing here, I'm not sure I think this is actually a good idea - you'd be losing a lot of accessibility you get for free with HTML for example, but I'd like to see some experiments in this area to see how far this could go.
In a word: accessibility. HTML is inherently accessible - you can curl a webpage and read the contents of any (static) web page. If you curl an entirely <canvas> based web page, you'll walk away knowing only that the web page has a <canvas> element in it.
You mentioned Qt. I've never programmed a Qt app, but I went hunting for its accessibility features in the docs[1]. I'm encouraged that Qt takes accessibility and Assistive Technologies seriously. However, if you're coding a web page in canvas/wasm/Qt you're going to need to make sure all the content, links and additional accessibility/AT requirements get ported from the <canvas> into the surrounding DOM to make it accessible.
That's a huge amount of work!
So, you would have a JS-based VM that runs in the browser. No Flash or other binary. Just pure Web standards for executing the code, rendering, etc. However, as an app developer, you wouldn't touch HTML or Web standards. Instead, they'd all be abstracted away and you'd work within a component/event driven model that's provided by the VM.
Instead of CSS, you'd roll themes, allowing you to stylize components. They'd ultimately be applied via CSS, but ideally you'd have a GUI interface for creating these themes. CSS gives you ultimate flexibility, but why are we still fighting whitespace and these other low-level document layout constructs when we are really working at a UI component/control level? It's like designing in assembly.
Instinctively, people won't want to give up this granular control. But that's only because we've been thinking about apps in Web terms for so long.
For me, that's the problem with a lot of these frameworks. They do a great job of helping you to wrangle the impedance mismatch between the web and apps. But, they are all predicated on deference to the Web, so they keep us immersed in this world, essentially fighting the Web's ill-fittedness to the task: HTML templates, DOM management, render functions with HTML strings, CSS styling embedded in "components", etc.
Why go so far to create a framework only to hamstring it with the very problems it aims to solve?