The Big Bet on Web Performance: What to Do Until WebASM Takes Over?
What do WebASM, Reason, Dart, Rust, and Go all have in common? They’re all trying to make the web faster. However, they do it in different ways.
WebASM’s approach is obvious. Take high performance code written in C and C++. Find a way to run it safely in the browser.
Dart’s initial approach was different. In the short term, Dart was meant to be compiled to JavaScript that would be faster than the JavaScript that you could write by hand. To a small degree, it succeeded. In the long term, the goal was to integrate the Dart VM into browsers. Unfortunately, this vision failed, and they gave up.
Reason’s approach is a combination of the above two approaches. In the short term, it can be compiled to JavaScript. In the long term, the hope is to use the OCaml-based version of Reason, and run it in the browser using WebASM. This is pretty forward thinking–which you might expect from Jordan Walke, the author of Reason.
Go is a language aimed at replacing server-side C++. However, they’re working on compiling to WebASM as well.
Rust is a language aimed at replacing C++ as well, but it was originally written specifically for reimplementing Firefox in order to make the browser faster. It too can be compiled to WebASM.
If we think back on the history of the web–things like React, Chrome, etc.–one thing’s certain: performance is a key differentiator. It’s particularly interesting to think of approaches, such as Dart’s initial approach or Reason’s current approach, which allow your code to run on a JavaScript VM today, but on WebASM in the future. This is an interesting approach to future-proofing the performance of your application.
Thanks to Alex Russell, Lars Bak and Kasper Lund, Lin Clark, and Jordan Walke for inspiring me to think in this way.
Published on Web Code Geeks with permission by Shannon Behrens, partner at our WCG program. See the original article here: The Big Bet on Web Performance: What to Do Until WebASM Takes Over? Opinions expressed by Web Code Geeks contributors are their own. |