I'll take it a step further and say we shouldn't be using the Web paradigm at all.
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.
I'm personally curious how far we could go with using just canvas and wasm. If we focused on making a browser that was just incredibly efficient and focused at using wasm and webgl, and had no other concerns, a lot of the cruft could be cut. Then any given "page" would essentially just expose the canvas for wasm to draw to, and GUI frameworks like Qt (which already can compile to wasm I believe) could just target this. We could then have different UI toolkits targetting this model, and hopefully even have something akin to Flash without being the same security nightmare.
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.
> I'm personally curious how far we could go with using just canvas and wasm
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.
Yes, the Web should stay what it is for static documents. In fact, what I advocated would continue to be based on Web standards (HTML, CSS, Javascript, and newer constructs like canvases, etc).
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?
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.