I don't know, but I really, really don't hope we get to the point where every web application ships a bespoke, WebAssembly rendering engine and treats the browser as WebGL dumb terminal. That sounds like a complete dystopia.

Think loading times are bad on script-heavy websites now? Wait until every web app uses its own mix of graphics, font and layout libraries, all compiled from C/C++ to WebAssembly and shipped in a 100MB blob. And rendered without any integration with accessibility technologies, and with basic things like copy and paste disabled to stop you "stealing" content. No thanks.

That's probably going to happen anyway. Just sayin'.

That'll be the first step. Then people will notice all those crazy download times, and someone will figure out that things could be better if they could write a single reusable "container" app in WebAssembly and WebGL that could host nearly arbitrary content, described in some kind of high-level markup language that's reasonably concise...

SVG markdown

It costs more to employ C/C++ developers than Javascript/HTML/CSS developers, so people are not going to recreate everything with bespoke C/C++.

Neither WebAss, nor WebGL (nor the canvas API for that matter) is a vector graphics format. When using WebGL, you still need a way to integrate complex prepared graphic content. You could implement an SVG renderer in WebGL + JavaScript I guess, but that's certainly not easier than just using SVG content straight away.

SVG 2 leaves the "painter model" behind (where z-order is determined by document order of the respective shape within its container) in favour of the z-index CSS property, so that you can address it in CSS (eg. `:selected { z-index: 1 }`). This makes it possible to describe things like interactive maps and DVD-like menus where when you click on a shape, the shape gets scaled or applied some other transform for highlighting.

However, I agree that SVG 2 leaves a bit to be desired (for example, level of detail properties). Also, animation of SVG in FF sucks compared to Chrome and Safari, or at least it used to 3 years ago. I wanted to teach my 12-year old how to make a simple browser game, but had to resort to hackish workarounds to make it run smoothly on top of using rAF etc., ruining my pedagogical ambitions.

> Also, animation of SVG in FF sucks compared to Chrome and Safari, or at least it used to 3 years ago.

I can relate to this, I use to work on a svg-heavy project in 2014 and I had the same kind of issues and I filed many bugs on FF bug tracker .

Fortunately, they've all been fixed by the mid of 2015. I don't work with svg so I don't know if everything works well now, but at least there were improvements.

That's a great point. I bet WebAssembly will result in an altogether next generation of technology given what we want to achieve today, not what we wanted to achieve in the early 1990s. But I have a feeling svg will have a big roll to play, and not only as inspiration either.

I dont think that many websites will be made in webassembly. Its more made for full webapps and games.

CSS/SVG is used for websites.

Given that we see more and more desktop applications being built with web technologies (formerly with node-webkit and recently with electron), and new UI toolkit are not really popular projects right now, I really doubt that many people will develop/use a brand new UI toolkit built on top of wasm and webGL.

Time will tell though.