Why does WebAssembly feel as though we're going around in a big circle?
Back when I used to play games like "Carmageddon" and "Command & Conquer: Red Alert" on my Windows 98 SE PC, which I do indeed consider to be "back in the day" (I'm sorry about your old age), I used to pop a CD into the optical drive and run the installer. After the installation had completed its tasks, I would run the executable that was the game/application and off I went, never to be heard from again for several hours, sometimes longer, and rarely for an entire weekend.
Fast forward a few years and eventually I was downloading the installers/binaries from the vendor's website, instead of using a CD-ROM. The same process applied: install the game or application, then run the executable. The end results were the same, but the delivery method was different - the software came over the wire instead of some physical form. This made accessibility much better and easier (most of the time for most of the things), and it was a sign of things to come with regards to software delivery.
Pressing our magical non-existent fast forward button again and we enter an age in which some software suites are delivered right in our browsers, such as Google Docs, Microsoft Office 365, Cloud9 IDE, and so on. Now there's no need to even run an installer. Instead you transparently download a large set of JavaScript files, static assests, etc, and the application executes directly in a VM fitted straight into the browser. This kind of behaviour and approach to delivery is excellent for certain types of work, because it simplifies a lot of the complex aspects about developing and delivering software, especially when you think about checking for and providing updates and patches.
Now we come to today. I just read about a newly annouced effort at making web sites even faster again: WebAssembly (https://en.wikipedia.org/wiki/WebAssembly). This new technology allows developers to put there expensive CPU tasks, such as physics, graphics rendering, and so forth, into the browser in a binary format. This binary "code" can then be utilised from human readable JavaScript as a module, as if it were just like any other pure JavaScript module, thus allows developers to vastly improve the performance of critically slow parts of their application.
Overall this is good news and innovation like this is always welcome - we experiment and deploy new ways of working, and just like natural selection, we select what works and what does not, and move forward. And this selection process isn't just an exclusive club for the engineers and developers involved in our industry: consumers have an incredibly powerful voice when it comes to telling us what does and does not work too, and we have no choice but to listen. I enjoy this process of theory to practice, iteration and reform, improvements, and evetnaully retirement as something better replaces what we currently have.
That being said, I feel we're going around in a big circle here. What WebAssembly is now introducing to developers is another means of delivering a binary/executable to our systems and having us execute it, except it's an automatic process with regards to the download and the installation. Combined with JavaScript, WebAssembly cuts out the need to click "Next" fifteen times or even click "Download" on a vendor's website. That is, once a consumer visits our fancy new WebAssembly powered browser based game, they download a binary, it's installed locally, and then it is executed. The consumer then, well, consumes the end product. All that has changed is the need to click "Download", wait N minutes, "Next", "Next", "Finish."
Instead of slowly creeping forwards (or is it backwards?) towards what I was doing back in 1998, but with an automated download and installation process, can we not simply jump to the good stuff: embed a URL address bar into my operating system of choice; allow me to type in a vendor's installation URL; this triggers a background download and an automated installation process; the software is installed on my SSD and then starts up, waiting for me to consume it. Wait, that sounds familiar...
We already have the Apple iOS App Store; we already have the same thing on OSX; Microsoft have followed along; gaming consoles are doing the same thing, too. These systems allow a developer to write and distribute software on platforms with ease (I've never done it, to be fair, so I will admit I'm making some wild assumptions here), and the end user can install them with ease by searching for them, clicking a button, and then enjoying the automatically deployed software. Why isn't this route being utilised more, instead of these heavy browsers acting as bloated middlemen delivering half-arsed software that works in a half-arsed manner (unless you spent A LOT of money getting it right?) I want native binaries, even if they're written in JavaScript and use Electron, not a massive browser that is acting as a second operating system on top of my operating system.
One possible answer is the fact JavaScript, and now WebAssembly, allows all these applications to be written in a single set of languages, but then deployed across multiple platforms. But we have efforts like Electron to allow a developer to write in JavaScript and deploy a more "native" application to the end user's system? Sure, that's just a WebView wrapped in a native "shell" or, if you like, a small micro-browser, but I would much rather have that delivered via an automated process, such as an App Store, than having to work within the restricted view port of my browser window with very little of the OS integration. I also don't want the GBs of RAM being (ab)used, neither.
I don't like the idea of making browsers the place to launch complex applications. Google thought, and maybe still thinks, it's the way to go, but I don't see many ChromeOS devices at my place of work, at conferences, nor, well, anywhere frankly. They're rare because I feel very few people want the kind of limited experience ChromeOS offers: slow, clumsy, limited JavaScript based applications upgraded under your feet without your consent or desire.
I think the future looks bright, and I'm confident we'll all get this right eventually. I also think it'll be interesting to see where this goes, which hopefully isn't back to 1998, because the music back then sucked.
There are big problems with the App stores over browser distribution. Most notably you have to acquire a potentially expensive certificate, figure out the signing process, get the app stores to accept your submission, then surrender a large portion of your revenue.
WebAssembly should offer the nice in-browser sandbox that JavaScript enjoys to applications written in many other languages.