WebAssembly, or WASM for short, is a performance-optimized solution enabling web applications to run at 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 developers to start using it right away, even for big projects, without worrying about breaking changes in the future. This article takes a closer look at the WebAssembly roadmap and future additional features in relation to Ruby language.
A brief introduction to WebAssembly
To briefly describe 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 a 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 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 MVP, WebAssembly 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 the WASM module, WASM binary format, and WASM text format brought high performance to applications on a wide range of platforms, including mobile and IoT. WASM applications running in the browser will be able to keep up with users’ expectations of smooth interaction, fast execution, fast loading, and security in memory management.
Where are we 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 stage of its development, while WASM only has preliminary support for Ruby. Currently, it fully supports compilers for languages like C/C++, Rust, and Go. 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 do not have direct access to the DOM. There are active movements in the 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 that would contain a lot of glue code for manipulating DOM.
- Ruby uses a garbage collector for memory management, while WASM does not have one. In fact, it does not have any tools for memory management yet. Even a statically-typed language that does not use a GC still needs some sort of a mechanism for managing memory allocation, such as https://github.com/rustwasm/wee_alloc for Rust. Therefore, Ruby needs WASM support for garbage collection, which has been announced as a coming feature in the post-MVP state of WASM.
- Ruby requires direct runtime support, which isn’t 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 your own runtime today, but it takes some effort, and this effort will need to be duplicated across different applications. Ruby developers would have to bundle separate runtime with applications, which is an impediment in 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
Without a doubt, WebAssembly is MVP complete as of today but not feature complete. There are more additional features that are expected to be implemented and whose development is still in progress, they will fundamentally change what we can do with WebAssembly in the post-MVP phase. 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 others would need much more time. With the joint efforts 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 useful insights into what the current state of WebAssembly is in relation to the Ruby language, and where WebAssembly will be headed in the future.
Read more
- https://webassembly.org
- https://blog.scottlogic.com/2018/07/20/wasm-future.html
- https://github.com/WebAssembly/design
- https://github.com/appcypher/awesome-wasm-langs
- https://github.com/opal/opal
- https://github.com/wasmerio/ruby-ext-wasm (Ruby library for executing WASM binaries)
- https://github.com/wasmerio/wasmer (standalone JIT WASM runtime)
- https://github.com/blacktm/ruby-wasm (Ruby library for compiling Ruby script to .wasm file)
- http://blacktm.com/blog/ruby-on-webassembly
- https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/
Photo by Francisco Casero on Unsplash
