A cartoon intro to WebAssembly | Hacker News Reader

A cartoon intro to WebAssembly

hacks.mozilla.org

235 pointshappy-go-lucky73 comments

Open articleView on HN

The "cartoons" are buried in the navigation at the end of the post:

https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-...

https://hacks.mozilla.org/2017/02/a-crash-course-in-assembly...

https://hacks.mozilla.org/2017/02/creating-and-working-with-...

https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...

https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...

Heh, I was gonna say it seemed pretty low effort.

I'm a bit lost on the appeal of webassembly. I can see why it's kinda cool to be able to ship a different language to browser and retain performance and bundle sizes, but the problem is I, and everyone else I know, has little to no interest writing C/C++/Rust in the browser.

Most of the people I know want to write Java/Python/Ruby/Elixir/Scala/C#/Clojure in the browser: high level scripting/VM based langauges which require no memory management and have high level features and data structures. As far as I can tell, these can't target WebAssembly since they don't target LLVM (and you certainly will never be able to compile a language like Ruby to LLVM)

I'd love to hear some of you guys talk about what uses you have for Webassembly and what exciting things it will let you do.

I'd love to write C++ in the browser, but only if they fix timers. The power of C++ and manual memory management is completely useless if some independent overburdened thread gets to decide when you are scheduled and for how long you run. If you have to just take 5ms breaks in your thread execution, you might as well just get a garbage collector that stops your world for a couple of milliseconds once in a while. Performance and any resemblance of real-time programming is lost anyway.

Could you tell me a bit more about why you want to write C++ in the browser? What things are you doing that are so CPU intensive that C++ is higher productivity then just JS?

It's not about being CPU-intensive - it's about getting to write better, more maintainable code in a better language with better tooling than JavaScript. Let's keep in mind that all lipstick notwithstanding, JavaScript is still a pig, and it's use is not out of its desirability on its own merits, but a product of circumstance.

Not the same person, but for me, and a lot of the people I know it's a case of: "Anything but Javascript", rather than a specific language. Seeing as the web, and web "apps" are taking over, we don't all want to be pigeon-holed into writing JS/React/Angular/Node.

I like JS, so that's not my problem per se.

Not the OP, but you're assuming that systems languages are lower productivity than JavaScript. I don't believe that Rust and Swift are necessarily lower productivity than JavaScript.

Nevertheless, here are a few of the main reasons you might want to work in a language that can easily target WASM:

1. Wholesale porting of desktop applications and game engines to the Web. This is the guise under which we developed asm.js, and it resonated well enough that Epic and Unity added support for asm.js to their engines.

2. Re-using existing, well-tested libraries that are written in C/C++. Why settle for zip.js if I can use libarchive directly? What about libraries that don't necessarily have high-quality JavaScript equivalents, like OpenCV, Box2D, or libsass?

3. Shipping high-performance codecs for multimedia formats like FLIF, BPG, and AV1 that aren't natively supported by browsers. Mozilla is actively using this strategy to develope the AV1 codec: https://hacks.mozilla.org/2017/02/webassembly-will-ease-coll...

4. Optimizing hot paths in JavaScript codebases, in the same way that Python or Ruby programmers will often re-implement individual functions or modules in C to overcome bottlenecks. For an example of this, consider the Flask microframework in Python, which depends on the Jinja2 templating library, which depends on Markupsafe for escaping HTML. Buried inside markupsafe is a 200 line file, "_speedups.c", that speeds things up. So even if end-developers aren't writing C/C++/Rust, they can still benefit from libraries that incorporate WASM.

5. Saving battery life. The fewer cycles it takes to finish a computation, the longer the CPU can spend sleeping. WASM provides significantly greater control over exactly what executes, and you can opt to burn CPU cycles on optimization once, during compilation, to get more a more efficient .wasm artifact for everyone. Since WASM is statically typed, the compiler also has many more optimizations available to it; no more worrying about monomorphism or type inference as with a JS VM's JIT compiler.

Video games. They require soft realtime constraints which current browsers are far from satisfying. Think networking, frame rendering, physics loop (even with deltas), etc. All of that is highly time-dependent.

use larger machine learning models in the browser

True real-time audio. The WebAudio API just connects a pre-existing collection of basic nodes implemented by the browser in C or C++. Being able to write sample-level processing targeted to WebASM would open up a lot of opportunities for different types of audio synthesis, effects, and analysis.

But even on C±+ your code takes brakes (unless you're running a RTOS), but it's not interrupted by a thread but by a process.

I'm more excited for the possibilities it opens rather than the immediate effects

> you certainly will never be able to compile a language like Ruby to LLVM

$ file /usr/bin/ruby

/usr/bin/ruby ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=4b353b68b7d8b46a570883c82efe48db9d77ef22, stripped

Looks like somebody managed it ;)

Snark aside, the trick for running managed languages on the WASM virtual architecture is the same as running them anywhere else: compile the runtime to the target, then ship the runtime with your program. That's what Go does, and why its hello world binary is 1.6 MB.

For a working example, PyPy.js (https://pypyjs.org) successfully ports Python to asm.js. It costs about 5MB in overhead, so it's not a practical alternative to JavaScript, but at this point it's mainly an optimization problem. If a language can statically analyze what libraries and runtime facilities a given program requires, then it can strip out everything else, leaving behind a reasonably sized binary for delivery over the Web.

"a reasonably sized binary for delivery over the Web" This frightens me. I consider a web page over 1 MB (including images) to be outrageous. I dread the day when web developers think its okay to include a 5MB file in a web page! At least other large binary files, like video, can be streamed. Can WASM binary files stream? I imagine the answer is no.

I am excited to write some Rust in the browser, and have been tinkering with what it might look to have a rust frontend framework with ergonomics comparable to what you might expect in other high level languages. (https://anowell.github.io/quasar/)

That said, I agree that more people will want to work in higher level languages, though I kinda suspect "most" are going to still prefer Javascript for the forseeable future - so I sorta see JS compiling to WASM as inevitable.

It's funny... the tactic that ReactNative runs for JS in different environments may well be contrasted with a "BrowserNative" library that bridges browser UI with another compiled (webasm) language.

Have you seen https://github.com/necolas/react-native-web

Yeah, but I'm referring to something to let wasm code target the browser ui... where as most react-native is a JS bridge to native UI.

The first language I see making use of webasm is typescript. They can see a lot of performance improvements over javascript by including type information in the compiled assembly.

Woah so TypeScrippt will be able to compile directly to Web Assembly. Thats reall cool.

FYI, the author noted that wasm-util[0] compiles TypeScript to WebAssembly.

Also, the author notes that future versions of WebAssembly may contain garbage collection features, which would be relevant to TypeScript.

"Garbage collection: If you can define your types ahead of time, you should be able to turn your code into WebAssembly. So code using something like TypeScript should be compilable to WebAssembly. The only hitch currently, though, is that WebAssembly doesn’t know how to interact with existing garbage collectors, like the one built in to the JS engine. The idea of this future feature is to give WebAssembly first-class access to the builtin GC with a set of low-level GC primitive types and operations."

[0]: https://github.com/rsms/wasm-util

Why can't Wasm compile the GC as simply another thread in the app?

Kind of like how it does on a regular compiler

Yes, when you're compiling a particular language to wasm, you could include a GC in wasm code as part of that language's runtime system. But it wouldn't interoperate with the Javascript GC, or GCs for other wasm modules compiled from other toolchains.

Typescript as it exists today is specifically designed to produce readable JavaScript. It does not make use of any runtime type system outside of JavaScript's , so I find it hard to see it that useful outside of a JavaScript compilation source

I'm building some peer-to-peer communications software where I'd like to support the browser as a secondary platform (for users who can't or don't want to download a client). My options for that would be to have the browser act as a thin client and run the software on a server, or run the software in the browser. WebAssembly lets me do the latter without being forced to write all my rather complicated networking code in javascript just to support a secondary platform.

> I'm a bit lost on the appeal of webassembly

A clue lies in the fact that all the major browser vendors (Google, Microsoft, Mozilla, Apple) are implementing WebAssembly. What is the strategic reason for this?

The speculation is that it all has to do with the rise of native mobile apps, which posed a threat to the web-entrenched interests. Google, I'm guessing, would prefer that you to stay in the web browser, using Google Search to to find all your applications, running them Google Chrome, and remaining a captive audience for Google's advertising clients. (instead of are searching for apps in the App Store and running them natively).

One important reason that native apps initially took off was that games, and other interactive content, could not be efficiently implemented for mobile web browsers. WebAssembly (in combination with WebGL) pretty much solves this problem. People have already ported a number of C++.OpenGL games to the web using emscripten.

> I, and everyone else I know, has little to no interest writing C/C++/Rust in the browser

I understand that most 3D game development is done in C++. I'm guessing that you don't know a lot of 3D game developers?

Besides games, many professional applications are developed in C++, for a variety of reasons. Examples could include scientific, engineering, graphics and audio processing software.

> Most of the people I know want to write Java/Python/Ruby/Elixir/Scala/C#/Clojure in the browser

Python is an interpreted language and CPython is implemented in C. You can cross-compile to WebAssembly today and start running Python scripts in the browser. Performance critical paths in Python scripts, like NumPy operations, which are offloaded to compiled C functions, would be offloaded to compiled WASM functions.

As for garbage collected languages, like Java and C#, future versions of WebAssembly will provide low-level GC primitives, which should theoretically allow those languages to run in the web browser as well. Having said that, you would incur the overhead of having to run the JVM/CLR virtual machine inside the browser engines's own JavaScript/WebAssembly virtual machine.

> I'd love to hear some of you guys talk about what uses you have for Webassembly and what exciting things it will let you do.

I suspect there is a lot of interest from C/C++/Rust developers already, and will continue to grow as WASM matures. Something like 10 million professional developers know and use C++ regularly, so this is a not insignificant usergroup on its own.

Some people think their problem is JavaScript (most of these people are wrong)

JavaScript (ES6) is a decent language, but some people prefer another language. While it is true that anything that can be accomplished on the web can be accomplished with JS (Turing completeness and all), people may not enjoy working with it.

Off the top of my head:

   - Games
   - Emulator cores
   - Crypto
   - Compression
   - Software graphics
   - Audio processing
   - Computer vision
   - Physics engines
   - Other heavy math/matrix/constraint solvers
   - In-memory databases

Besides games, all of these are library uses, and tend to have fixed structure definitions and often even fixed memory buffers to work with (crypto in particular). The developer is still writing the main application in JavaScript (or whatever other dynamic/GC'd language you wish to compile into JS) and gets the full speed and memory footprint benefit of pulling libraries such as these as opposed to seeking pure JS versions.

    - DRM

If it lives in the relatively restricted sandbox of the browser, then that's not any scarier than DRM written in Javascript in a browser.

Have fun writing a new adblocker for each page. Yes, debugging/decompiling is possible, but that is far scarier than the the current situation.

When it's possible to ignore the DOM by uploading your own renderer (e.g. custom freetype/etc compiled to webasm), it's possible to prevent adblocking based on HTML/CSS selectors.

WebAssembly doesn't necessarily mean "do everything in canvases".

Of course. Similarly, I doubt Adobe intend for Flash to replace entire websites with over-animated single page apps with terrible usability, but that's how many websites used Flash In the late 90s.

Yes, well-designed sites will use WebAssembly in other more reasonable ways. Entirely separate from that are the websites that try to disable the right-click context menu to "protect" images, and the businesses that are watching there revenue disappear with the rise in adblocking. Some businesses will - often foolishly - use all available means to "protect their content", so that's how they will use WebAssembly.

History keeps repeating itself. Alan Kay's idea was that objects are moved around. You don't request a data structure like html, you request an object and it runs in the new system.

1) Oberon had an idea of 'slim binaries' portable binaries that can be compiled into object code in a single pass. Loading would be almost as fast loading a file. Slim binaries were designed to be slim and fast.

2) Then came java, jvm and java applets People said that jvm is the plaform. Java will be is just one language using that platform. Compiled java objects were not so slim and fast to recompile :(

3) JavaScript became de facto portable platform but they are not binary. Browser became the client virtual machine.

4) Now we have WebAssembly. Lets' hope that WebAssemply is actually slim and fast representation like slim binaries.

Maybe the most interesting bit (in part 6/6): Browser Preview is over, they can start shipping it!

https://lists.w3.org/Archives/Public/public-webassembly/2017...

Firefox 52 will ship with WebAssembly support in exactly one week. The era of a JavaScript monoculture on the Web is over.

WebAssembly has no access to any of the web API (DOM, ...) . WebAssembly cannot start without javascript as of right now. Flash died because of one platform not supporting it. The very same platform still doesn't support WebAssembly. As much as I love the hyper around WASM, I don't want to overhype it, otherwise, it will be a almost non-event as NPAPI.

I think that's an overly pessimistic view, which complements my overly optimistic view. :)

> WebAssembly has no access to any of the web API (DOM, ...)

WebAssembly can access those APIs via indirect, opaque shims today. Direct access is on the roadmap.

> WebAssembly cannot start without javascript as of right now.

We're still hammering out semantics on the HTML side, but WebAssembly modules can define a `start` entrypoint that is automatically invoked when the module is loaded. Combine that with ES6's `<script type="module">` and you've got WASM that can load and begin executing without JS.

> Flash died because of one platform not supporting it. The very same platform still doesn't support WebAssembly.

Apple is a party to WebAssembly's development and a co-signatory on the linked announcement that the WebAssembly binary format and Web APIs are complete. This doesn't mean they'll necessarily ship in a timely manner, or at all, but it's a damn good sign.

> I don't want to overhype it

That's fair. The world won't change overnight, but it's clear that the world is changing in fundamental ways. The initial changes may be insignificant, but they'll compound over time and as WebAssembly matures.

JavaScript isn't dead, and WebAssembly won't kill it, but it will dramatically change the landscape. In a similar vein, C will never kill Python, but I'd be shocked if most moderately complex Python applications didn't depend on a module implemented in C somewhere in their stack.

How is/was NPAPI a non-event? So many things were built with that!

And they've settled on a logo!

https://github.com/WebAssembly/design/issues/980

This web assembly scheme saddens me a bit. I wish the scripting line would not be crossed and we could stick to JIT-compiled JS or even dialects that can execute closer to the metal (like asm.js). It's just so nice to be able to have all the codes - I've found that even the most aggressively minified uber-scripts can be pretty printed and studied.

All the arguments in favor about saving bytes and offline compiling would seem like only short term gains since network, cpu's, and memory sizes are going to continue to improve.

And, it's certainly not Flash or Java Applets all over again since there are multiple competent vendors in the mix. Yet, I fear a new wave of unconstrained, impenetrable code schlock will flow from content creators once this thing hits the mainstream.

> since network, cpu's, and memory sizes are going to continue to improve.

As the article mentions, the drastic speed improvement that JIT gave us let us build even bigger, more complex web apps. Maybe things will continue to get bigger and more complex and we'll need wasm, or maybe wasm will allow us to build apps not possible now.

> I've found that even the most aggressively minified uber-scripts can be pretty printed and studied.

I haven't found this to be the case. Most minifiers rename variables to one-letter, which makes any moderately-complex web app unreadable, or at least not very fun. Furthermore, I don't think that technically requiring source-code distribution for execution is really the solution - Open Source is a social problem at root, not technical.

I, for one, welcome the possibilities.

For purposes of pretty-printing and studying, the WASM MVP is effectively a binary encoding of asm.js. Imports and exports have names and are statically defined, while the degree to which unexported symbols are mangled is determined by your compiler settings.

Debugging tools will need to improve, and you'll need to learn WASM's (limited) vocabulary, but if you're happy enough with asm.js, then I think you'll be ultimately be happier in the future. I, for one, would much rather see actual type signatures like: "param $x i32" than asm.js's cryptic annotations "x = x|0".

Just because its binary doesn't mean it can't be studied. Even with something like compiled native machine code its still relatively easy to disassemble and look at how it works with the right tools. With WebAssembly, dissassembly should be even easier and be more clear than native x86 or something. Still not as easy as well written javascript, but I expect it will approach the difficulty of minified js.

In my eyes, the size and offline compilation aren't even the biggest benefits. Having a low level assembly language for web computation lets people write in any language and compile it for the web. There's already an LLVM backend for it - although still experimental. But this may even mean we can simply port existing codebases to WebAssembly with little performance loss.

You've been able to compile stuff for web for a while, by transpiling to javascript, but the result has been too slow for many applications, so it never really picked up.

You have asmjs working well for 3 years to cover your usecase. WebAssembly is not really faster to execute than asmjs in our tests.

> I expect it will approach the difficulty of minified js.

WebAssembly has less structure than minified JS (instructions are a linear list - a stack machine - for example) and it is less hackable (it isn't intended to be written or modified by hand).

WebAssembly will be somewhere in between native x86 and minified JS in terms of how open it is to being studied.

If I understand webassembly, to me the main benefit will be to precisely code in a language other than javascript. Some people love javascript, like others love C or assembly. I personally prefer high level statically typed languages, where the IDE can help me a lot, do refactoring, checks for syntax errors, etc. Then we will have the equivalent of a JVM or CLR but truly cross platform (if Apple plays the game).

> I wish the scripting line would not be crossed and we could stick to JIT-compiled JS or even dialects that can execute closer to the metal (like asm.js). It's just so nice to be able to have all the codes ...

This is addressed in the WASM FAQ:

"Will WebAssembly support View Source on the Web?

Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool..." [1]

[1] http://webassembly.org/docs/faq/

There will be a text format, but it's important to keep expectations low, as here is what it looks like:

http://webassembly.org/docs/text-format/

I suspect that's no worse than minified JavaScript or ASM.js.

That's a joke, right?

> With this improved performance, JavaScript started being used for things no one ever expected it to be used for, like server-side programming

Oh, how quickly we forget.

Please elaborate, I don't get what you are suggesting.

JavaScript was hacked together in short time for the browser. You can't get any less server-side than that?

Might be a reference to Netscape Enterprise Server[1], which had server-side JS in 1995?

[1] https://en.wikipedia.org/wiki/Netscape_Enterprise_Server

Livewire, it was called, back when you bought your browser in a box at Best Buy.

I did server-side programming in JavaScript in the late 90s. In retrospect it was a bad idea, but people were doing it. Note: this shouldn't be confused with the more recent node.js version of server-side JS.

>Some applications of WebAssembly may be held up until [direct access to DOM] is resolved."

I don't know what number crunching web applications the vendors are thinking of. I want wasm for client-side web programming without JS.

> I don't know what number crunching web applications they're thinking of...

Games, and WebGL games in particular.

Surely they're not chasing native just for games

Search for 'mobile app revenue by category'. I'll wait.

Awesome intro, that was pretty easy to follow :)

Just a few small typos to point out:

https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas...

"Executing" section - "...know how to write code so that they compiler can type specialize it" - the compiler instead of they compiler

"Conclusion" section - "etching WebAssembly takes less time because it is more compact than JavaScript, even when compressed" - missing the f in fetching

Thanks! Looks like these have been fixed.

Article misses one of the big marks as to why WebASM could be faster. Manual memory management allows for much better cache utilization which is usually where managed languages spend most of their time vs native languages.

I am so afraid that WebAssembly will make too many assumptions that will prevent Go from targeting it as a platform.

A well designed assembly language should be targetable by any well designed IR. When the Go team decided to work on their own compilers instead of writing frontends for existing compilers, they chose to take on that effort.

What assumptions is wasm making that will prevent Go from targeting it, and why are those assumptions fundamentally harder for Go to target than LLVM IR?

Not sure about assumptions made by wasm, but current limitations preventing Go from targeting it are:

> there is no efficient way to implement setjmp/longjmp functionality currently, therefore it's not a viable target of a gc port. We need to wait until it gets real stack unwinding and exception handling support.

https://github.com/golang/go/issues/18892

Well, thankfully TFA includes a short paragraph talking about the standardisation of exception handling, so here's hoping to have that resolved soon.

Reply on news.ycombinator.com