The web is controlled by players who have shifting agendas. There's always at least one player that wants to advance the web, because they are doing poorly in t

The web is controlled by players who have shifting agendas. There's always at least one player that wants to advance the web, because they are doing poorly in the native OS market (or some portion of it). There's always at least one other that wants to keep web technology stagnant, because they are doing well in the native OS market. These players switch roles as the market evolves. The power in the web is that once you have a critical mass of content that requires a certain feature, browser makers have very strong incentives to support that feature, and very strong disincentives to not support it (such as undermining their market share, and thus control over future web evolution). Which means that progress is pretty much monotonic, but also very path-dependent. Hence why the technology is often such an awkward fit for its current uses. It also means that the web api will always lag behind the richest native apis, but that's how all technology works, and must work if there is to be progress; the cutting-edge is always non-standard experimentation. In terms of controlling presentation, WebAssembly, HTML canvas, and WebGL are conspiring to bust the monopoly of the Javascript/HTML/DOM model. Look at this: http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt-examples/kate/kate.html http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt... (takes a while to load, worked on Chrome for me despite warning). It's a full blown Qt app running in the web browser. There's obviously a lot of kinks to sort out, like the massive loading times, but it's not that far from being viable. WebAssembly and the ecosystem that will grow around it (to some extent, this already happened with asm.js and Emscripten) are game-changers for the web because they shift the burden, i.e. developing for an inferior platform designed by a committee full of bad-faith actors, from every single app developer to the compiler and core-library developers. Of course, this will lead to inefficiencies like drawing with Qt inside a VM inside a web browser that's itself drawn using Qt. And so smart browser vendors will figure out how to optimize, thus some web apps will work much better on their browsers. This will force the less-eager browser vendors to improve the performance too. And so the cycle continues... This is actually exactly how WebAssembly came about in the first place. Asm.js provided a solution that worked on all browsers by brutally and inefficiently repurposing existing technology, but that could be heavily optimized by enlightened browsers. One browser vendor gained a temporary advantage by doing this, and thus forced everyone else's hands. A binary format was just the next step. I suspect that this dynamic is a general phenomenon that causes technology to naturally trend toward standardization and therefore openness.