WebGL should never have been invented, at least on current architectures. It's a ticking bomb, precisely for the reasons this articles explored - drivers are complex and buggy black boxes that lie in kernel space so ring 0 access is never too far from reach for many exploits. WebGL has a potential to be exploit vector much more severe than what we've seen with other auxiliary web technologies like JavaScript or Java applets. Why not confine web to (mostly) nicely behaved x86 VMs?

Personally I think browsers will become service layers that expose the underlying OS in controlled and specific ways. Not a completely sandbox, but not a free for all either.

We've started creeping that way with a lot of the newer HTML5 stuff, but we have a long way to go.

Looking at the bug bounty record from Chrome and Mozilla it seems that fuzzing-for-bounties vulnerability research has largely moved away from WebGL. Must be at least partly due to WebGL reaching a reasonable level of robustness. Bounties may be harder to claim since bugs can be hardware/os/driver ver etc dependent, but still there used to be a lot more WebGL bounties dealt out.

To be fair, I think the takeaway isn't don't make/use abstraction layers, but don't make a one-size-fits-all abstraction and then hide the lower level stuff. A targeted abstraction that correctly supports the domain you are in is still a good thing. That's what the engine developers end up being here, an abstraction on top of this low level API that gives many devs exactly what they want.

Edit: To be clear, I don't think writing a web rendering engine meant to do the same think as the browser on top of WebGL will be faster in any respect, as really the HTML and CSS are just inputs fed into super optimized low level rendering engines. I don't see how JS could compete in that domain.

Reminds me of MIT's Exokernel- make the lower level interfaces as low-level as possible (while still providing security) and let user-level libraries provide various abstractions suited to different use cases.

No file systems, no network protocols, no processes; just a very thin layer that lets userspace implement those if/how it wants to.

Parts of CSS3 are already faster to implement "by hand" in javascript rather than using the browser's "native" implementation.

HTML/CSS was designed for requirements that don't apply to many modern websites. I would not be surprised if it were possible to implement a rendering engine that performed better for relevant use cases, e.g. perhaps assuming a grid as a first-class part of the layout.

Wouldn't that kill accessibility, selectable text, being able to call system services (i.e., on OS X hitting cmd+shift+D to get a dictionary definition of a word), any extensions which modify the page hierarchy, automatic translation/localisation, and so on.

Exactly; bypass this entire service layer maintained by thousands of engineers and try to do it in Javascript?! I think that's probably not a good idea.

Someone did this with their WebGL Terrain demo [0]. You can find a detailed post-mortem in the author's blog [1].

[0] http://zephyrosanemos.com/windstorm/current/live-demo.html

[1] http://zephyrosanemos.com/

Take a look at what Flipboard did recently, with their whole mobile site built in JS and canvas

http://engineering.flipboard.com/2015/02/mobile-web/

Except that it would all still be done via a layer of javascript (using asm.js may mitigate this)

Native JavaScript performance is not generally what makes web apps slow.

Just because it isn't the bottleneck today doesn't mean it isn't slow.

It's definitely feasible! A goal for my side project is to give developers a React-like declarative UI with a WebGL rendering backend that abstracts away the graphics programming.