
WebAssembly without the browser - pacificat0r
https://alexene.dev/2020/08/17/webassembly-without-the-browser-part-1.html
======
tess0r
Author of wasmex[1] here (an elixir package which allows runnung WASM).

Next to the mentioned wasmtime, wasm3, and wamr, there is also wasmer[2] I
would add to the list of capable WASM runtimes.

The great things these runtimes offer are how easy they are to integrate into
other programming languages environments. E.g. with wasmex you could easily
run WASM from your elixir application (or with wasmer from ruby[3] or many
other languages if you want).

Imagine building shopify, but without needing to invent your own template
language for customers to extend their shop-template[4]. They could provide a
WASM extension API where shop-owners could let sandboxed WASM files render
their shop. This would let allow shop-owners to write templates in their
favorite language instead of e.g. liquid and still be secure.

[1] [https://github.com/tessi/wasmex/](https://github.com/tessi/wasmex/) [2]
[https://github.com/wasmerio/wasmer](https://github.com/wasmerio/wasmer) [3]
[https://rubygems.org/gems/wasmer](https://rubygems.org/gems/wasmer) [4]
[https://github.com/Shopify/liquid](https://github.com/Shopify/liquid)

------
hardwaregeek
One area that I'm hoping WebAssembly will help with is running native
extensions in a portable sandbox. That way libraries like nokogiri can be
compiled to wasm ahead of time, then executed on a wasm runtime. There will be
a perf hit but not having to wait for nokogiri to compile native extensions
will be worth it.

~~~
jnwatson
I think the ability to run unknown code in a sandbox is probably the most
interesting use case. This is particularly compelling in P2P computing
projects.

~~~
enos_feedler
I am really hoping the mobile platforms like iOS offer pure wasm sandbox APIs
for this use case. This could be a powerful way to support programmability,
app extensions, etc outside of the appstore. It could appease both Apple for
security and developers for flexibility.

~~~
millstone
What is the advantage of wasm sandbox over the native sandbox?

~~~
afiori
proponents of wasm claim that the wasm sandbox was designed with security in
mind from the very start. From apple point of view they could offer a runtime
with very specific and limited permissions and trust that the plug-ins will
respect them.

------
follower
Interested to see a number of people mention one of the attractions with
WebAssembly being the sandbox &customisation angles.

Sandboxed in-game avatar customisation was one of the motivations behind the
"WebAssembly Calling Card" (WACC) project I released within the past couple of
weeks, posted a Show HN here:
[https://news.ycombinator.com/item?id=24072304](https://news.ycombinator.com/item?id=24072304)

"WACC: Like an avatar but WASM!"

The WACC specification defines how three 32-bit ints (returned via 3 calls to
a function in a WASM module) get turned into triangles:

* 256x256 coord system.

* 15 bit color + 1 bit alpha per vertex triangles.

* 1 FPS!

In part, WACC & the WACC Viewer app is a demonstration of a WIP add-on for the
Godot game engine that wraps the libwasmtime WebAssembly runtime so desktop
Godot games/apps can call functions in WebAssembly modules. (The other demo
app is a tool to help explore `.wasm` files:
[https://gitlab.com/RancidBacon/wasm-
exploder](https://gitlab.com/RancidBacon/wasm-exploder))

The other main goal with WACC is to provide more visually interesting "first
run" experiences for people embedding WASM runtimes and/or provide a creative
outlet for starting to play around with generating/writing WebAssembly.

So, if you're interested in playing around with some non-browser WASM you
might like to have a play with WACC--maybe implement the spec for a different
host or create your own Calling Card. (I would particularly like to see it
running on standalone hardware like a badge or similar.)

Main site here: [https://wacc.rancidbacon.com/](https://wacc.rancidbacon.com/)

------
pansa2
> _This is powerful because you [can] use Rust or C++ as your scripting
> language._

Do people really want to use such complex, heavyweight languages for
scripting?

> _WebAssembly enables predictable and stable performance because it doesn’t
> require garbage collection like the usual options (LUA /JavaScript)._

Do garbage collection pauses cause significant issues when embedding Lua or
JavaScript? If so, I would expect implementations of those languages to switch
to reference counting, but none of them are doing so.

> _Extremely fast programs in environments where you can’t JIT for reasons._

To get good performance, don't WebAssembly implementations need to use JIT-
compilation internally?

~~~
danShumway
> Do people really want to use such complex, heavyweight languages for
> scripting?

This is a surprising reaction to me, given the history of Javascript and
NodeJS in general, but you're not the only person I've seen bring this up.

Ask yourself, 'do people want to use such a strange, high-level language as
Javascript for programming servers?' Of course they do, because the primary
factor in choosing a language isn't whether or not it's perfectly suited for a
specific task, it's how familiar you are with it and how much tooling you
already have built up and available around it.

Being able to program your back-end and front-end in the same language is a
_massive_ productivity win. It allows you to do all kinds of cool things with
architecture and code reuse, and most importantly you don't need to switch
mental contexts as often while you're programming.

So if it was reasonable for JS devs to bring their scripting language to the
server, it is just as reasonable for Rust/C++ devs to want to bring their
server language to the browser. It's not about the language semantics; if
someone is primarily familiar with Rust then they'll be faster building web
apps in Rust than they would be in Javascript.

------
Shared404
This seems to me like WebAssembly works basically like Java, but the bytecode
can be compiled to from multiple languages.

Is this correct?

~~~
throwaway189262
It is like Java bytecode, but design geared more towards supporting C.

Wasm in many ways is dumb. They could have easily adopted CLR or JVM bytecode.
But no, the web is too "cool" for that. It's better to have a brand new VM
that's slower and missing GC and a standard library.

~~~
danShumway
> missing GC and a standard library.

Many of us consider these points to be features. We don't want a runtime
that's as complicated as CLR or JVM bytecode.

~~~
throwaway189262
Any popular VM inevitably becomes as complex as those. Look at V8, it's grown
into a JVM sized beast.

It would save countless hours of human effort to just adapt what's out there.
It will be a decade before WASM has the kind of support JVM and CLR do. By
then it will have the same huge codebase that causes vulnerabilities

------
rapidlua
I doubt that WASM is good as an embedded language, unless performance
requirements outweigh the inconvenience.

Dynamic languages are great for experimentation and exploring the system, e.g.
a console in the browser is the fantastic tool and web dev people tend to try
things there first. By embedding wasm, you are making tinkering with the
system you provide less enjoyable for your users.

One could argue that since many languages compile to wasm, you can pick
whichever suites you best. But in reality, you are probably limited to
languages with thin runtimes, e.g. Rust or C. Otherwise you will end up with a
huge wasm blob. Imagine, there are 2 Java extensions, a C# one and something
in Python, all running simultaneously. It means 3 different runtimes with a
footprint by far exceeding that of the application logic in an extension.

Another burden is the bridging between the host and an extension. Unlike lua
or js you can’t pass and inspect objects, the only option is to marshal data
as a byte blob. So if you were to pick up a language no one used to write
extensions for the particular application before, the very first think you
have to do is writing marshalers.

Last but not least, I disagree with the article calling S-expressions ugly and
strongly believe in the opposite.

~~~
flohofwoe
IMHO WASM is the perfect replacement for native plugin DLLs for DCC tools like
Maya or Photoshop (but not a replacement for a scripting interface which such
applications usually offer too in addition to DLL plugins).

Instead of having to distribute a multitude of DLLs for each OS/CPU
combination, you only distribute a single WASM module, and the WASM runtime
that's integrated into the DCC tool takes care of the platform-specific
details. And WASM is also easier to sandbox than DLLs, so a crash in the WASM
plugin can't take down the entire application.

~~~
eggsnbacon1
IMO in this regard WASM is pretty much the same as Java/C# except slower and
less mature.

In Java, distributing libraries as cross-platform "jars" is very common.

------
azakai
> WebAssembly enables predictable and stable performance because it doesn’t
> require garbage collection like the usual options (LUA/JavaScript).

GC is a small part of that - the much bigger factor is dynamic optimization is
necessary for fast Lua or JavaScript. Wasm is designed to not need that (like
most languages that are not dynamically typed).

~~~
wffurr
Some wasm runtimes, eg V8 and Spider monkey, do tiered compilation, where all
code is first compiled with a high throughput streaming compiler, and then
only the hot paths get recompiled with an optimizing compiler.

~~~
azakai
True, good point!

Tiered compilation in general does dynamic optimizations, definitely in
JavaScript (runtime type collection, etc.) but also to a lesser extent in C#
or Java (inlining, etc.). In wasm none of the tiers do dynamic optimizations
AFAIK, but tiered compilation definitely helps there too, mostly with startup
times.

------
jmnicolas
I'm not sure I understand the use case of the author. He mentions languages
(Rust, C++ etc) that can be natively compiled to (almost) any platform, so
what's the point of running them in web assembly ? Like Java write once run
everywhere ?

~~~
rmoriz
My speculation: WASM will be used as default for edge computing and further
cloud based containers. Cloud vendors will develop custom silicon optimized
for WASM that won't be available for general public, maybe on ARM or RISC-V.

~~~
MaxBarraclough
> custom silicon optimized for WASM

I doubt it. Like Java, WASM is intended to be used with an optimising JIT
compiler. It doesn't make sense to try to implement Java or WASM directly in
hardware.

ARM used to offer _Jazelle_ , which could run Java bytecode directly on the
CPU. It's now long dead. It makes more sense to use a sophisticated optimising
JIT to produce efficient machine-code, than to make hardware to directly run
an unoptimised IR.

~~~
rmoriz
I'm sure it is already in the works. WASM is the key to be independent of the
ISA and allows to switch to custom silicon without having the customers to
know. That's how cloud vendors will drive the future in the race to get
independent from x86 and ARM (very likely that a future owner of ARM will
limit the licensing business). So even if there is no performance gain
possible due to the reasons you have pointed out, it's probably the
abstraction layer of the future for pretty much everything.

~~~
MaxBarraclough
> I'm sure it is already in the works.

Why? As I just said, this kind of hardware approach doesn't make technical
sense.

> WASM is the key to be independent of the ISA and allows to switch to custom
> silicon without having the customers to know.

We already have ISA-independence with JavaScript, Java bytecode, .Net, Python,
and other high-level languages.

Again, WASM isn't intended for direct execution on hardware, it's intended to
be fed to an optimising JIT compiler. Direct execution on hardware isn't how
you get good performance out of an IR like this.

> That's how cloud vendors will drive the future in the race to get
> independent from x86 and ARM

I don't think cloud vendors care all that much who they buy their CPUs from.
AWS offer instances on Intel, AMD, and ARM CPUs. If they really want ISA-
freedom, their best bet is RISC-V.

> even if there is no performance gain possible due to the reasons you have
> pointed out, it's probably the abstraction layer of the future for pretty
> much everything.

There will never be a single abstraction layer for everything. Compiler
engineering doesn't work that way.

------
devwastaken
Without proper security audits on wasms runtimes they can only be used as
hypothetical tools. The main purpose of wasm is a sandbox that's well defined,
but that doesn't matter if it's implimentations are vulnerable.

You could use it to just "deploy software anywhere", and that's a neat idea,
but it's not 'web' assembly, there's no protections thst make it fit to run
arbitrary code from the web.

------
erlend_sh
There’s a working proof of concept of WASM as a scripting foundation in a WIP
programming game called Robot Rumble:

[https://github.com/robot-rumble](https://github.com/robot-rumble)
[https://rr-docs.readthedocs.io/en/latest/technical-details.h...](https://rr-
docs.readthedocs.io/en/latest/technical-details.html)

~~~
eat_veggies
Are there screenshots or demos of what it's like to play? Their website is
down and their docs don't really have any cool pics.

------
sriku
(shameless plug)

I gave a talk, about a year ago, covering history of the problem statements
from which WASM was born and the various forms it is taking.

[https://labs.imaginea.com/talk-the-nuts-and-bolts-of-
webasse...](https://labs.imaginea.com/talk-the-nuts-and-bolts-of-webassembly/)

Welcome thoughts/comments/corrections/additions.

~~~
pacificat0r
This is a really good article. I will include it in my reading materials at
the end of the post :)

------
chrisweekly
I found this writeup to be fairly well-written and detailed, but I lack the
WebAssembly knowledge to comment on its other merits.

------
thdrdt
I wish things like this could be used to break free from mobile app stores.

Download a virtual machine via the app store and then run any app written in
any languages and compiled only once.

Almost like JAVA..

------
MPSimmons
Things like this is how we got NodeJS. Sigh.

~~~
Kye
I don't see how this is a problem. A lot of good came with the bad. This is
like when people complain about Visual Basic or PHP. They were awful in so
many ways, but they got a lot of people into programming, and those people did
a lot of cool things.

------
nicetryguy
If you are going to target WebAssembly outside of a browser environment, uh,
why not just target LLVM, GNU, or uh, you know, Assembly... X86_64 or ARM are
pretty standardized. Another part 1/1 "tutorial" with some brilliant insight
as per usual.

~~~
Skinney
LLVM bitcode is, I believe, not portable. Neither is Assembly. Nor are the
resulting binaries of that processed something that is run within a sandbox.

~~~
aerismio
This, i think webassembly is the sweet spot. It has portability but doesn't
have any opinion about how the code should be structured. No opinion about GC
or objects etc.

Works really really great with Rust.

