https://github.com/WebAssembly
These are my initial thoughts. I reserve the right to change my mind, and almost undoubtedly will, but I thought it would be interesting to set down what I think now, so I can compare it with how it will all turn out later.
What is it?
The name is a good clue. It is an attempt at creating a portable web assembly language. Wait, isn't that what asm.js claims to be? Answer: yes.
According to its design documents WebAssembly wants to be a better version of asm.js. One that instead of being built on top of Javascript is actually built directly into the browser. The main advantage being performance (both execution speed and code size).
Is this really needed?
I'm sure this is going to be the main thrust of the debate as asm.js already exists. My own thoughts are that this has the potential to bring web applications on par with native applications in terms of performance and this in itself makes its adoption almost inevitable. But the thing is that asm.js was almost certainly going to achieve that anyway, so why bother? Answer: standards.
Asm.js is tied to Mozilla, and while it works on the other browsers (because it is just Javascript after all), it would be difficult for those other browsers to to optimize asm.js code to native code speeds. This is 'who controls the standard' problem is the same reason why NaCl/PNaCl is exclusively a Chrome thing.
By the Big 3 agreeing to cooperate on a standard it means that developers (application, tool, etc...) can focus all of their efforts and thus achieve progress faster.
How likely is this to succeed?
Right now I see its general adoption as quite likely. The fact that asm.js exists proves there is a real craving for a portable fast browser targeted assembly-like language. Because it isn't Javascript there are a lot of Javascript-language limitations that can be sidestepped rather than coded around (numbers and math calculations mostly but also potentially things like threading and memory constraints). Because the Big 3 browsers are all involved from the start, and all can benefit directly by making the browser a more popular option for a wider range applications, there is a huge incentive to make it work.
It all adds up to a lot of forces pushing in the same direction. The only real way for it to fail is technically. However, there are so many people who want and would benefit by this, it is hard to imagine that the brain-power needed to solve the (relatively small) technical challenges won't be there. For the most part the technical solutions already exist, it is just a matter of picking and choosing what will work from what doesn't. The devil will be in the details, but there is going to be a lot of angles whipping the devil into submission.
What does it mean for the Web, the Universe, and Everything?
It means that the web comes a step closer towards being the world computing platform. There is going to be less and less desire for so-called 'native applications'. Why write an application for only this platform or that platform, when I can write an application for all platforms simultaneously?
This is quite attractive to developers (one of the big reasons why Java has the popularity that it does even though it never fully achieved this). This is also attractive to users who no longer will be plagued by the chores of installing and maintaining applications. In the end almost everyone benefits by this sort of standardization which drives it forward into a sort of crystalized inevitability.
As I look at the computer I am using to write this post (which itself is being written inside of a webapp and so already no longer a native app) I see that my 'main' native applications that I use are: IDEs, virtual machines, note taking, and games. All of the other applications I use are really just OS support type apps (backups, machine monitoring, etc...), and of course my web browser(s).
The IDE and virtual machine are used in tandem and at this point I consider them part of a set. There are already primative web-based IDEs and cloud computing is everywhere. I can well imagine a not too distant future where my main IDE becomes web based, with the IDE-webapp tying directly into various cloud-vm infrastructures for testing/deployment/etc (In fact it already kind of exists).
The fact that I still prefer a native app for note taking exemplifies that web apps still aren't treated as 'first class' citizens from a conceptual point of view of the OS. Once I can easily bind a hot-key to a URL the need for a native app disappears. This is a UI problem, and one I feel confident will be resolved within the next 5-10 years as web apps continue their relentless domination of the desktop.
Games. Games will almost certainly be the final hold-outs, but paradoxically they are also the main drivers for WebAssembly and a web-centric future. Many of the simpler games I play should already be web-apps (card games), and the larger games (FPS, 4x grand strategy, etc) are just waiting for the performance and standardization that WebAssembly promises to be achieved.
In short, the gap from native to web apps is already quite small and shrinking. WebAssembly could be the final bridge that allows the world to complete the transition and relegate native apps to 'background plumbing'. It will be interesting to watch (and hopefully participate in) the migration.
No comments:
Post a Comment