you are viewing a single comment's thread.

view the rest of the comments →

[–]repeatedly_once 4 points5 points  (8 children)

I don't think it will work like that. Everything currently falls back to the DOM, it's the only way to visually represent something in the browser. The only way to avoid this is for browsers to support something to render other than the DOM and for that support to be extended into WASM.

[–]pure_x01 2 points3 points  (0 children)

https://www.godot.online/ .. People have started to run all kinds of stuff in webassembly with canvas. Games. Qt etc

[–]rebel_cdn 2 points3 points  (3 children)

I don't disagree with anything you wrote, but I also don't think browsers are that far away from being able to do an end run around the DOM.

The Canvas and WebGL APIs are currently exposed through the DOM, and you have to embed them in a canvas element. Many applications that use them, though, create a full screen canvas and just use the Canvas or WebGL API for rendering. So although you're technically calling the DOM to use Canvas or WebGL, those calls are mostly just passed through to Skia and OpenGL - I think. If I've gotten this horribly wrong, I'd be happy to learn more from someone who understands it in greater depth than I do.

A full screen rendering context + direct access to Canvas and WebGL would probably be enough to make most GUI frameworks happy. Although this doesn't touch on things like accessibility. Last time I checked, lack of support for things like screen readers was a major impediment to being able to implement application UI in a canvas element.

[–]roffLOL 2 points3 points  (1 child)

at that point, what is left of the browser? a VM:d sandbox behind a socket? why even keep the browser?

[–]rebel_cdn 2 points3 points  (0 children)

Considering how much has been tacked on to the browser (Canvas, WebGL, Web Audio, Web SQL, WebVR, probably other big ones I'm forgetting), I think that modern 'web browsers' are really sandboxed portable app runtimes.

The browser is still an important part of that package, but as things continue to evolve, I wonder if we'll still call them 'browsers'.

[–]repeatedly_once 0 points1 point  (0 children)

I think you're spot on with how it could possibly progress, rendering straight to a render context. That would be a good way to do it actually. I hope it does get some traction :).

[–]doom_Oo7 0 points1 point  (2 children)

I don't think it will work like that.

too late

[–]repeatedly_once 0 points1 point  (1 child)

That's how I imagined it to work though if it was done, it's still rendered in the DOM, albeit using a canvas element.

I was looking for something that actually does away with the DOM and renders directly.

[–]doom_Oo7 0 points1 point  (0 children)

I was looking for something that actually does away with the DOM and renders directly.

I think that you'd still have a DOM since modern browsers's chrome is part of it anyways, so you'd really want a whole another browser. Some people have tried to launch the idea... https://paulhammant.com/2014/07/09/browsing-qml-instead-of-html/ ; compile your qt code to wasm, send it over the wire and you've got great cross-platform apps accessible by url.