WebAssembly is coming (and ya probably ain’t gonna write it)
The web development tooling in general has undergone a huge transformation in the last five years. Packet management with NPM and transpiling code to with Babel, ClojureScript, CoffeeScript, TypeScript, etc. are a staple task in 2018. Reusing these skills for WebAssembly would be ideal.
WebAssembly, and asm.js before it, focuses on areas not common to web developers. You’ll likely consume a lot of WebAssembly in the form of libraries to do things like image and video compression for sure. It was a similar situation with jQuery: Everybody used it, but a handful developed jQuery.
TypeScript-wasm tools: AssemblyScript, TurboScript, Speedy.js
There are multiple options for compiling TypeScript to wasm, but there is no de-facto choice yet. Multiple tools available have reached a maturity where they are usable for real world development in limited cases. Application execution is guaranteed by the wasm spec — A compliant wasm binary will work identically regardless of the language it was written and the toolchain used for compiling.
The most common TypeScript to wasm compilers at the time of writing in February 2018 are:
Like WebAssembly itself, the TypeScript-wasm compiler scene is very volatile. The situation can be compared to the 2013–2015 when first task runners like Grunt and Gulp were prominent, but the industry then moved to Browserify for module bundler and eventually standardized on Webpack. It continues to evolve and there’s competition from Rollup and Parcel, but the pace is more relaxed.
As of now AssemblyScript seems like the most promising of the trio of prominent compilers. It has a standard installation procedure via NPM, does not reinvent the wheel. Binaryen, a compiler and toolchain infrastructure library, is used do the heavy lifting. Binaryen originates from the core WebAssembly and thus is a high profile project with over 56 contributors. Seems legit to me.
In addition to pure technical ability, AssemblyScript is also investing in softer side of developer tooling; Example code, documentation and an online playground (WebAssembly Studio) are available. Today AssemblyScript only has two contributors, which is an obvious disadvantage. On the other hand, the project can be seen as glue code between TypeScript and Binaryen, so a small team can be credible.
The reality is that the vast majority of web developers, including myself, will likely never write a single WebAssembly application from scratch. Having the possibility to a use familiar language syntax and toolchain is a something that would lower the treshold to make changes to WebAssembly components.
Or who knows? Maybe Facebook will launch competing Zuckembly that will eat web standards’ lunch, like with React. But until that day is upon us, the most important question on my mind is…
When will we get a Macromedia Flash plugin in WebAssembly, so we can all migrate to ActionScript?
— Jani Tarvainen, 20/02/2018
Originally published at malloc.fi.