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.
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
I was very happy then when I came across tinygo, compile down a web assembly module and come to found it it makes WAY less assumptions and has a very simple based comment based system for importing functions — something to my knowledge currently impossible in the mainline Go compiler.
tinygo takes advantage of LLVM and is able to reduce web assembly modules to a pretty extreme amount pretty well. What this enables me to do is write very minimal modules like this hello world:
Read the article: https://medium.com/@richardanaya/hyper-efficient-front-end-development-with-web-assembly-using-go-and-llvm-8e6a1ccdd2bc