Ruby on WebAssembly

Item: Netguru
Rating: 4.9
Author: 30 Clients

Thu Le

Sep 24, 2019 | 7 min read

WebAssembly, shortened as WASM, is a performance optimized solution enabling web applications to run at a near-native speed. It is a cutting-edge technology with the current state as an MVP (minimum viable product), not the final version of WASM. Even though the standard is still evolving and new features are being added, the current, MVP version of WASM is guaranteed to be compatible with future releases.

This allows the developers to start using it right away, even for big projects, without worrying about future braking changes. This article takes a closer look at the WebAssembly roadmap and the future’s additional features in relation to Ruby language.

A brief introduction to WebAssembly

To describe briefly how WASM works, we would need to take a look at the concept of WASM modules - distributable, loadable and executable units of code in WASM.

WASM modules are delivered to the browser in binary format, and are executed by a virtual machine (VM) that works alongside the JavaScript VM, sharing resources (e.g. memory) and executing on the same thread.

To put it differently, developers can write code in high-level languages and compile it with compilers or interpreters beforehand to WASM (.wasm filename suffix) which would allow it to run in the browser at a near-native speed.

(Image: hacks.mozilla.org)

In the MPV, WebAssembly has developed the core features which are available today in most modern web browsers (Google Chrome, Microsoft Edge, Apple Safari and Mozilla Firefox). The introduction of WASM module, WASM binary format, WASM text format has been proved to bring high performance to the application on a wide range of platforms, including mobile and IoT. WASM applications running on the browser would be able to keep up with users’ expectations of smooth interaction, fast execution, fast loading and security in memory management.

Where are we at with WebAssembly and Ruby

For years, JavaScript has been the dominant language for web development. Ruby developers can transpile their Ruby code to plain JavaScript through source-to-source compiler like Opal. Since the development of WebAssembly, developers now have another option to choose from compilation targets.

At this state of its development, while WASM only has preliminary support for Ruby, it fully supports compilers for languages like C/C++, Rust, Go to run in WASM themselves. These statically-typed languages, therefore, can easily and directly compile to WASM in just one compilation step. This process is straightforward: just target WebAssembly in the compiler toolchain.

However, for a dynamically-typed language like Ruby, there are some fundamental issues blocking the compiling process to WASM. Though these issues can be resolved by some means, there are quite a lot of certain basic steps to be executed before Ruby can be fully supported.

WASM modules currently does not have direct access to DOM. There are active movements in WASM community where experienced developers attempted to develop many libraries which compile code to WASM and let developers manipulate the DOM, e.g. https://github.com/mbasso/asm-dom. However, unlike other languages like C, C++, C#, Rust and Go, Ruby does not have an active community around WebAssembly. Ruby developers would need to write a WASM module which contains a lot of glue code dedicated to manipulating DOM.
Ruby uses a garbage collector for memory management, while WASM does not have a garbage collector. In fact, it does not have any tools for memory management yet. Even a statically typed language which does not use a GC still need some sort of mechanism for managing memory allocation, e.g. https://github.com/rustwasm/wee_alloc for Rust language. Therefore, Ruby needs WASM support for garbage collection which is promised to be a coming feature in post-MVP state of WASM.
Ruby requires a direct runtime support which are not ready yet in WASM infrastructure. For now, Ruby developers need to create their own runtime and ship a required runtime alongside their code, and implement a JIT (just-in-time) compilation to give themselves a fast execution. It’s possible to create their own runtime today, but it takes some effort, and this effort will have to be duplicated across different applications. Ruby developers would have to bundle separate runtime with their applications, which is an impediment for many use cases.

For all the above reasons, Ruby does not compile automatically, cleanly and efficiently to WASM at this state of development yet.

Conclusion

It is no doubt that WebAssembly today is MVP complete, but not feature complete. There are more additional features which are expected to be implemented and are still in-progress state in the post-MVP will fundamentally change what we can do with WebAssembly. These features include garbage collection, multithreading, zero cost exceptions and fixed-width SIMD (single instruction multiple data), etc. Among these features, some can be developed rapidly while some would need much more time to reach the result. With the join effort of Google, Microsoft and Mozilla, and an active community where new ideas and proposals are openly raised and added into tracking issues. WASM is expected to become a more mature product and the future of high performance web development. See more here.

Hopefully this article has provided you with a useful brief insight into what’s the current state of WebAssembly in connection with Ruby language and where WebAssembly is heading in the future. Ruby traditionally has a comprehensive ecosystem of tools dependent on a Unix-like environment, compiler toolchain, standard libraries.