The benefits of such a setup are numerous, especially for small sites and side projects:
Hosting a static website is much easier than a “real” server - there’s many free and reliable options (like GitHub, GitLab Pages, Netlify, etc), and it scales to basically infinity without any effort.
The how is also super interesting:
So how do you use a database on a static file hoster? Firstly, SQLite (written in C) is compiled to WebAssembly. SQLite can be compiled with emscripten without any modifications, and the sql.js library is a thin JS wrapper around the wasm code.
There’s more to the story, and the resulting solution is also open source.
<input>on your web page, download the index you’ve specified, and display the best search results immediately to your user, as they type. The precomputed index and WebAssembly frontend module make the entire Stork engine very good, and very fast.
Get started with WebAssembly through this simple hands-on tutorial that assumes only general knowledge in web development. The only tools you’ll need to get a taste of Wasm through runnable code examples are a code editor, any modern browser, and a Docker container with toolchains for C and Rust that comes with the article.
I built a new go Playground that uses Web Assembly to run Go code right in the browser. One of the cool things about this is is that it made it way easier to build a secure server execution environment because the server doesn’t execute anything, it just compiles.
A Rust/WASM port of the Python code from the article “Writing a full-text search engine using Bloom filters”. This can be seen as an alternative to lunr.js and elasticlunr.
The idea is to generate a small, self-contained WASM module from a list of articles on your website and ship it to browsers. tinysearch can be integrated into the build process of generators like Jekyll, Hugo, zola, or Cobalt.
Kick the tires on the author’s blog.
Firefox is mostly written in C and C++. These languages are notoriously difficult to use safely, since any mistake can lead to complete compromise of the program.
The team has thus far had 2 strategies for securing the codebase, breaking code into multiple sandboxed processes with reduced privileges and rewriting code in a safe language like Rust.
today, we’re adding a third approach to our arsenal. RLBox, a new sandboxing technology developed by researchers at the University of California, San Diego, the University of Texas, Austin, and Stanford University, allows us to quickly and efficiently convert existing Firefox components to run inside a WebAssembly sandbox.
This strikes me as a bonkers idea and kinda brilliant.
The core implementation idea behind wasm sandboxing is that you can compile C/C++ into wasm code, and then you can compile that wasm code into native code for the machine your program actually runs on.
Click through to read more about how they’re pulling this off.
When’s the last time you read the ECMAScript spec? Marja Hölttä on the V8 dev blog:
Also check out How to read the ECMAScript specification which covers most of the material from this post, but from a different angle.
The Lumen Project is an alternative implementation of the Erlang VM, more known as the BEAM. It is designed to work in WebAssembly with the specific goal of bringing Elixir and Erlang to the browser with minimal overhead, tightly compiled rather than porting a full VM. Can it replace JS for some developers?
Results are in for the 2019 State of JS survey. I’ve been digging through charts to see what I can see. Here are 7 insights that jumped off the page to me.
Mozilla, Fastly, Intel, and Red Hat are forming a “Bytecode Alliance”, which is described as:
a new industry partnership coming together to forge WebAssembly’s outside-the-browser future by collaborating on implementing standards and proposing new ones.
We have a vision of a WebAssembly ecosystem that is secure by default, fixing cracks in today’s software foundations. And based on advances rapidly emerging in the WebAssembly community, we believe we can make this vision real.
Security seems to be at the dead center of this alliance. Click through for an in-depth rundown of why this is a problem and what they plan to do about it. Also, some awesome code cartoons from Lin Clark (I assume).
A look at a new proposal for WebAssembly that will make it possible to easily communicate between WASM and pretty much any language/runtime. This will allow seamlessly embed code from one language into another… think “native modules” except you no longer have to re-compile them on the user’s machine, not to mention you can use them “for free” on the web, and you get sandboxing built in! Wow!
Love that they shared the actual customer-facing results too. As authors Pranav Jha and Senthil Padmanabhan say:
Technology evolves at a very rapid pace. Every day we hear new things getting launched. But only a few make a difference to customers, and WebAssembly is one of them.
WebAssembly is a powerful tool for bringing command line utilities to the web and giving people the chance to tinker with tools.
Yet another excellent use case for Wasm.
A city building game that uses microscopic models to vividly simulate the organism of a city arising from the interactions of millions of individuals.
Runs in the browser via WebAssembly.
A cool/fun intro to Wasm where you build a game for cats (catch the red laser dot) completely in Go.
Wasmer is a standalone JIT WebAssembly runtime with an aim to be fully compatible with Emscripten, Rust, and Go. Check the roadmap and tune in to a future episode of The Changelog with Syrus Akbary, the creator of Wasmer.
curl https://get.wasmer.io -sSfL | sh
wasmer run nginx.wasm
Running Nginx on localhost:8080 Press Ctrl-C to stop...
In a post with a title borrowed from Ariana Grande, Steve Klabnik is announcing his departure from Mozilla and what he hopes could be his next moves.
Mozilla is not interested in hearing what I have to say. And that’s fine, but when I take a step back and think about things, that means it’s time to go, for both my sake and Mozilla’s. So I’ve just put in my two weeks’ notice.
The interesting thing isn’t exactly that he’s moving on from Mozilla, it’s that he’s betting big on WebAssembly.
I’ve also been enamored with another technology recently: WebAssembly. 2019 is going to be a huge year for WebAssembly, even if many people don’t know it yet, and may not see the effects until 2020.
So what’s his next move? Something different…
In terms of the actual work I would like to do, I don’t think a traditional engineering role really suits me. Don’t get me wrong, I love to write some code, but I don’t think that those kinds of roles really play to my unique strengths. What I really love to do is teaching, evangelizing, and growing something.
We’re tracking the activity around Wasm quite well, but we’re open to more suggestions if you have them. In this post Divya shares some insights and the big idea behind Wasm.
It is undeniable at this point that WebAssembly is (and will be) a huge game changer for web development. As a lower level language, it efficiently handles more computationally heavy tasks and allows us to so more, with less. Though we’re still in the early stages of WASM, the future looks bright.
Very cool! I tried to get to a Command Prompt, but it seems key input has been disabled.
There’s lots of fun comments in this Twitter thread.
A lot of people wanted Steve Klabnik to elaborate on this from a recent post on WebAssembly…
Some have compared WebAssembly to Java applets; in some ways, they’re very right, but in some ways, they’re very wrong. Eventually I’ll write a post about the wrong, but for now, the right: in some sense, WebAssembly is a different way of accomplishing what the JVM set out to do: it’s a common virtual machine that can be used to build very cross-platform software.
Here’s a great take away if all you want is a tldr…
Benjamin Bouvier, Compiler Engineer at Mozilla, writes about speeding up calls from JS to Wasm in Firefox.
If we want more WebAssembly (wasm) adoption, there shouldn’t be a big costly barrier between the two universes. That is, calls from one world to the other should be fast. For a very long time, calls from JS to asm.js/WebAssembly have been quite slow in Firefox. In fact, we didn’t optimize them at all.
He goes on to say…
Benjamin continues through several more bugs mentioned on the Bugzilla bug board with fixes to speed up calls from JS to Wasm in Firefox.
Vim in your browser! Compiled from the C code and emscripten and binaryen
With the advent of WebAssembly, the race is on to bring new languages to the web. This is the first example (I think!) of a Ruby interpreter running in the browser.
The path to get there is circuitous.
Ruby script → MRuby bytecode → C → emcc → LLVM → Binaryen → WebAssembly
The good news is access to that path is just a
gem install wasm away. Read the entire post for some great context and history around these efforts.
Want to try WASM before you buy WASM? You’re in luck! I found this while prepping for this week episode of The Changelog with Lin Clark. It’s really well made and definitely lowered the barrier for me to tinker with both WebAssembly and Rust. Worth a 🔖 for sure.