Tuesday, July 07, 2015

Making the Web Run Faster via WebAssembly

Digital and Mobile Guru, Peter Rogers
Like most of us, my colleague at Cognizant and technical mobile and web expert, Peter Rogers, spends his warm summer evenings pondering how to make the Internet run faster.  In this guest blog, Peter shares the latest developments in "WebAssembly."  Enjoy!


You probably saw the Blogosphere explode the other day when WebAssembly was announced. [Sorry Peter, I missed that one]. For the uninitiated Web Assembly is ‘a new low-level binary compile format that will do a better job at being a compiler target than JavaScript’. It is basically a binary form of AST (https://en.wikipedia.org/wiki/Abstract_syntax_tree) which means that it is much faster to load, process and potentially run. Half of the problem with JavaScript is that we need to load a text file and then wait for it to be interpreted. Web Browsers are trying to use JIT (Just In Time) and AOT (Ahead Of Time) strategies to speed things up but the language itself makes life hard. Suddenly Brendan Eich comes up with a project to deliver an actual binary AST (https://medium.com/javascript-scene/why-we-need-webassembly-an-interview-with-brendan-eich-7fb2a60b0723) that can be used and what really excites people is that Google, Mozilla and Microsoft have all agreed to work on the format. Browsers will understand the binary format, which means we'll be able to compile binary bundles that compress smaller and that mean faster delivery. Depending on compile-time optimization opportunities the WebAssembly bundles may run faster too. A quick overview can be found here (https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6) and the community page is now open (https://www.w3.org/community/webassembly/).

The rest of what followed was a whole load of confused articles about JavaScript being dead, writing everything in WebAssembly and questions as to why JavaScript itself cannot use WebAssembly instead of C/C++ .

Well here are some interesting bullet points for you:

  • You can actually run WebAssembly today and it does actually use JavaScript
  • WebAssembly is going to be a slow evolution not an overnight sensation
  • This solution is really useful for game developers and advanced web applications but it probably won’t be applicable in most cases 

The whole WebAssembly idea has actually evolved from Emscripten (https://github.com/kripken/emscripten), ASM.js (https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/) and NaCl/PNaCl (https://developer.chrome.com/native-client/overview). ASM.js is a subset of JavaScript that has been designed to be highly optimised by compilers but it is a textual format. If a Web Browser supports ASM.js and you have somehow managed to load this textual format then you can see as much as 1.5x native speed execution depending on the browser and the code itself. Just to put that in perspective that is pretty much the same speed as Java and C#. Sounds great, but how do I get my code in ASM.js? This is where it starts to get nasty…you have to code in C/C++…You use Clang to compile your C/C++ into LLVM bytecode (https://en.wikipedia.org/wiki/LLVM) and then use Emscripten to convert the LLVM bytecode into to a subset of JavaScript (http://ejohn.org/blog/asmjs-javascript-compile-target/) called ASM. The Unreal 3 Engine was ported to ASM and it ran surprisingly well in ASM capable web browsers.

In a nutshell, you have to write in C/C++ and then use a few tools to output a highly optimised subset of JavaScript (albeit still a textual one) that can be accelerated on web browsers that support it. The rendering part needs to be considered though and normally we use WebGL because it is hardware accelerated and perfect for dealing with the ASM data structures. Unity have been quick to support ASM, NaCl and now WebAssembly. Any WYSIWG tool or dedicated programming environment can always spit out ASM. Of course there will always be an overhead if you are switching ASM contexts on and off, so you have to consider your application structure. Ideally one huge lump of heavy processing gets handed over to ASM and the rest of the application carries on with normal JavaScript. You could write the whole application in ASM but the whole thing becomes totally unreadable unless you use a tool like Unity: but that is probably more suited towards a canvas type approach like a Widget or a game rather than a full web application.

Quite a few browsers support ASM according to this excellent article (https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/):

Exciting…but what if you do not wish to program in C/C++? Here is where it gets very interesting. As it stands there is no WebAssembly but there is a Polyfill (https://github.com/WebAssembly/polyfill-prototype-1) that uses ASM. Which means you can run WebAssembly today using ASM, but you are still actually using JavaScript, only a highly optimisable version in a textual form. The roadmap basically starts here with the logical progression being a binary form of the existing ASM before we move to a new whole new language. At the moment you have to use C/C++ in order to generate ASM but there is nothing to stop you hand-coding it - other than patience and sanity. Anyone familiar with writing video game pokes in machine code from back in the 80s will probably smile at the challenge of hand-coding ASM.

So why C/C++? Well the problem is that scripting languages are very high level. This excellent article talks you through the argument tremendously well (http://mrale.ph/blog/2011/11/05/the-trap-of-the-performance-sweet-spot.html). Probably the best scripting language I know is Ruby and even that does not have the low level capabilities of C/C++ required for performance optimisation. Indeed the whole web was founded on a mixing of declarative languages (CSS, HTML) and simple scripting languages (ECMAScript, JavaScript, JScript and even VBScript). There is a reason why game developers use C/C++ and that is for performance and so if you really want to get close to the metal then a traditional scripting language is probably not going to cut it. Most of this is down to the data structures and the overhead in storing objects.

However…what about a next generational scripting language…he said mischievously. I was amazed to find a new scripting language that fitted the bill called LLJS (http://lljs.org/), which I presume stands for Low Level JavaScript. They have just been able to compile LLJS into ASM (http://jlongster.com/Compiling-LLJS-to-asm.js,-Now-Available-). This is a very exciting glimpse into the future. I can see tool vendors like Unity and next generation scripting languages like LLJS, all being able to spit out ASM and deliver a much improved web experience. Soon you will be to write a 3D application in Unity and export it to WebAssembly and use the WebAssembly Polyfill to actually run it in most modern web browsers. LLJS will probably not be the only next generation scripting language and ECMAScript 7/ECMAScript 2016 along with new APIs are already adding lots of new features which makes it much more effective to accelerate JavaScript such as: Typed Objects (http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects); and SIMD (https://hacks.mozilla.org/2014/10/introducing-simd-js/).

My guess is that ECMAScript will start to evolve into a much more lower level language and this will rapidly accelerate as soon as a few next generation scripting languages start to challenge it. It will be very interesting to see how low level a scripting language can actually become. Swift has arguably proved an initial attempt at just this, by embracing the best practices of scripting along with much deeper control.
Thanks for sharing this article with us Peter!

Kevin Benedict
Writer, Speaker, Senior Analyst
Digital Transformation, EBA, Center for the Future of Work Cognizant
View my profile on LinkedIn
Read more at Future of Work
Learn about mobile strategies at MobileEnterpriseStrategies.com
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.