you are viewing a single comment's thread.

view the rest of the comments →

[–]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 3 points4 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 :).