Yeah - there really is a opportunity now to rethink browsers as just sandboxed rendering windows using WebAssembly + WebGPU.
Could still have typical DOM rendering handled with Webassembly delivered by the web sites (ideally cached). The challenge is though still having standards and accessibility options. That VeryGoodGraphics example allows for no text selection - and doesn't at all handle zooming. Still though it'd be a good bottom up way for a new browser to disrupt Chrome
How would ad blocking work in this world? A browser without ad blocking is useless.
How would ads work in this world? The advertising ecosystem relies on adding a 1-2 line JavaScript blurb to the page, and then the ads are added at display time.
Re:So You Want to Build a Browser Engine
by robin_reala on Monday June 10, 2024 @11:02AM
(#40634377)
VeryGoodGraphics has no accessibility tree and no results when searching the documentation for “accessibility”, which makes it broadly immoral (or if you want to disagree with that, at least illegal to use it to build production systems in many locations). If you can’t get that right from the start, or even have plans for it, then you’re obsolete.
If there is a VGG-native browser then accessibility is not so hard to implement. The awkward problem is that current VeryGoodGraphics is just a canvas node in HTML (using WebAssembly + WebGL). So adding accessibility support will be a nightmare technically.
Even if you don't care about that (and you should!), "you can't highlight text [without doing additional work that nobody will do because it wasn't an explicit KPI for them]" is itself really disappointing and bad.
We escaped Flash. We shouldn't clamor to go back.
The reasons to escape Flash are the performance and power-consumption issues, rather than accessibility.
If you take browser as a document viewer then accessibility is critical. However if you take browser as a universal application platform, then accessibility is not necessary, right?
Re:So You Want to Build a Browser Engine
by robin_reala on Monday June 10, 2024 @11:40AM
(#40634747)
No? Why shouldn’t apps be accessible?
Re:So You Want to Build a Browser Engine
by RussianCow on Monday June 10, 2024 @12:49PM
(#40635482)
> However if you take browser as a universal application platform, then accessibility is not necessary, right?
Are you really suggesting that people with disabilities shouldn't be able to use web apps?
Sorry, I was just raising my question. Because in my country most app maker does not care about accessibility. Now I know.
Lively Kernel was one such idea.
My opinion is that the rendering engine should be WASM specified in a header. This way the site provider can choose whatever engine they want, including possibly not even using HTML.
Lock Casey Muratori in a room until he designs the right API? He definitely believes the current one is the wrong API :-)
Re:So You Want to Build a Browser Engine
by promiseofbeans on Friday June 21, 2024 @09:34AM
(#40749455)
Relevant XKCD: https://xkcd.com/927/
An (early) alternative spec/engine would be a Figma-compatible vector graphics spec[2] and its rendering engine[3]. It is called VeryGoodGraphics[1].
[1] https://verygoodgraphics.com/, the website is built with its own technology. [2] https://docs.verygoodgraphics.com/specs/overview [3] https://github.com/verygoodgraphics/vgg_runtime