In my previous articles I talked about how WebAssembly allows you to bring the library ecosystem of C/C++ to the web. One app that makes extensive use of C/C++ libraries is squoosh, our web app that allows you compress images with a variety of codecs that have been compiled from C++ to WebAssembly.

WebAssembly is a low-level virtual machine that runs the bytecode that is stored in .wasm files. This byte code is strongly typed and structured in such a way that it can be compiled and optimized for the host system much quicker than JavaScript can. WebAssembly provides an environment to run code that had sandboxing and embedding in mind from the very start.

In my experience, most performance problems on the web are caused by forced layout and excessive paint but every now and then an app needs to do a computationally expensive task that takes a lot of time. WebAssembly can help here.

Read: https://developers.google.com/web/updates/2019/02/hotpath-with-wasm

Sometimes you want to use a library that is only available as C or C++ code. Traditionally, this is where you give up. Well, not anymore, because now we have Emscripten and WebAssembly (or Wasm)!

Read: https://developers.google.com/web/updates/2018/03/emscripting-a-c-library

WebAssembly (wasm) is often framed as either a performance primitive or a way to run your existing C++ codebase on the web. With squoosh.app we wanted to show that there is at least a third perspective for wasm: making use of the huge ecosystems of other programming languages. With Emscripten you can use C/C++ code, Rust has wasm support built in and the Go team is working on it, too. I'm sure many other languages will follow.

In these scenarios, wasm is not the centerpiece of your app, but rather a puzzle piece: yet another module. Your app already has JavaScript, CSS, image assets, a web-centric build system and maybe even a framework like React. How do you integrate WebAssembly into this setup? In this article we are going to work this out with C/C++ and Emscripten as an example.

Read: https://developers.google.com/web/updates/2019/01/emscripten-npm

I was lucky to be involved in an evaluation of WebAssembly for an in-house web frontend project. The project basically involves an Admin Dashboard where a user logs in to monitor what is going on, looks at some sales charts and orders activities. In the evaluation, our goal is to determine whether it is feasible to use WebAssembly for front end web development, and if possible, build a prototype to prove the feasibility.

Read https://medium.com/@ConnectCode/webassembly-for-front-end-web-development-emscripten-vs-rust-vs-blazor-c02fb70b3e19

For the last year I’ve watching the the tooling of the web assembly world evolve, primarily from the perspective of a Rust developer. What has concerned me is my inability to escape JavaScript at every turn. Not that I dislike JavaScript, I’ve programmed JavaScript for 10 or so years, but more so that when I imagine the future of web development, I imagine it being free from what unnecessary as much as possible.

Read https://medium.com/@richardanaya/a-better-way-to-write-web-assembly-1e28616864f7

In my book, I wrote an Appendix that included some code samples illustrating how to cryptographically sign WebAssembly modules, but these were more to illustrate some interesting Rust syntax rather than prescribe real-world, production patterns. For example, the signing in that appendix prepended a 64 byte blob to the Wasm binary, making it unusable by any of WebAssembly’s standard tooling (or parseable by regular hosts).

Read https://blog.usejournal.com/signing-webassembly-modules-with-rust-dd45fbb6987a

ABI stands for Application Binary Interface (wiki page).

We can see an ABI as a contract between two binary applications, to assure that one binary is able to access certain native functions from the other binary.

Each time we compile a C or C++ application there is a set of system calls that the application will normally use, for example, to open a file, read its contents… or even opening a socket.

For doing that, the applications normally target the POSIX ABI to run these syscalls in Unix-like systems. There are different implementations following POSIX, such as libc, musl…

Read the article: https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9

A few days ago, I wanted to take Go WebAssembly out for a spin, but I wasn’t sure what to build. Maybe a game ? but I didn’t really want to build a game from scratch. So I remembered the Elevator Saga, a programming game by Magnus Wolffelt I stumbled upon a few years ago: The goal is to transport people up and down building floors by controlling elevators, writing the rules in Javascript. What if I modified it to accept WebAssembly flavoured Go instead of JS !

Read the article: https://medium.com/@didil/practice-your-go-webassembly-with-a-game-7195dabbfc44

The technology that most directly underpins webpiling is WebAssembly. The details are best explained on the official site, but for our purposes you can think of WebAssembly as being a kind of platform, like x86 or ARM, in that you can compile native libraries to be executed from this format. The output of this compilation process is a .wasm file, which can then be loaded and called from JavaScript in order to run natively-implemented functions in a browser. WebAssembly has a number of benefits, but the two that are most important for webpiling are (1) it’s a logical output format for native library implementations and (2) it runs very, very fast.

Read the article: https://medium.com/@babylonjs/marker-tracking-in-babylon-js-ce99490be1dd

We’ve been working steadily to get Wasmer to execute WebAssembly modules on the server-side as fast as possible.

TL;DR — We got 100x improvement on startup time on Wasmer 0.2.0

Before getting into details, it’s essential to understand how Wasmer works under the hood to see what could be improved.

Read the article: https://medium.com/wasmer/running-webassembly-100x-faster-️-a8237e9a372d