Emscripten - the saviour we have been waiting for?

Turn the clock back a few years and listen to the promise of this new language called Java. "Write once, run anywhere" was going to change the way developers wrote applications. It didn't matter what OS, browser or device you were using, Java was going to be there.

It didn't quite work out that way. Most mobile devices don't run the garden variety of Java (Android certainly relies on Java, but much to Oracle's disgust, it is not their Java), I haven't seen an applet based website in years, and even desktop Java applications are hard to come by if you are not a developer.

It was JavaScript that won the battle for the ubiquitous development platform. Speed and functionality still varies between devices, but if you want to write code that at least has a chance of running everywhere, JavaScript is your best choice.

The problem with JavaScript is that it lacks a lot of the libraries that other languages have had years to build up. This void is something that emscripten hopes to fill by giving developers the opportunity to compile their favourite C/C++ apps into JavaScript.

I recently used emscripten to compile two XSLT libraries into JavaScript. XSLT on the client is quite limited by a number of longstanding and low priority bugs (https://bugzilla.mozilla.org/show_bug.cgi?id=69799 and https://code.google.com/p/chromium/issues/detail?id=8441 combine to make any serious XSLT transformations impossible with JavaScript), so I had high hopes that I emscripten would allow me to run either xsltproc or xalan on the client.

The good news is that I got both application compiled and running in the browser. The code for xalan can be found at https://github.com/mcasperson/xalan.js and xsltproc can be found at https://github.com/mcasperson/xsltproc.js.

The process for getting both to compile was quite manual and time consuming. You are building in clean room environment, which means you have to manage all dependencies beyond the few provided by emscripten (like libc or sdl). I imagine the standard libraries provided by emscripten will grow, but at this point it is up to you to know what your application depends on and include it in your build environment.

I also found that optimization was a case of start with everything and work back until you find what options break the application you are compiling. Neither xsltproc nor xalan would work with the recommended setting of -O2, and removing the optimizations one by one, recompiling and testing was very time consuming.

And unfortunately the end result was not all that useful: both applications resulted in 20 MB+ JavaScript files; a bug in chrome (https://code.google.com/p/chromium/issues/detail?id=252492) prevented xsltproc from running in a web worker; Firefox was slower than Chrome when running xsltproc by a factor of aruond 6; and xalan took upwards of 90 seconds to transform a simple XML document (compared to the less than 1 second for the native build).

As cool as emscripten is (take a loot at some KDE applications running in the browser), it seems that it will be some time before it is possible to take any existing C++ application and have it compiled reliably into JavaScript and run consistently in the major browsers.
Post a Comment

Popular posts from this blog

Fixing OpenVPN "Authenticate/Decrypt packet error: cipher final failed"

MinHash for dummies

Exporting from MySQL to H2