A cartoon intro to WebAssembly

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.

theodorton• 9 years ago

And they've settled on a logo!

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

vvanders• 9 years ago

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.

EdSharkey• 9 years ago

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.

news_to_me• 9 years ago

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.

callahad6• 9 years ago

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".

pager86• 9 years ago

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.

batmansmk2• 9 years ago

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

azakai2• 9 years ago

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.

cm2187• 9 years ago

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).

n00b1013• 9 years ago

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/

azakai2• 9 years ago

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/

danellis• 9 years ago

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.

bhaak• 9 years ago

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?

evilpie• 9 years ago

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

mml• 9 years ago

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

irrational3• 9 years ago

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.

flaviuspopan• 9 years ago

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

callahad6• 9 years ago

Thanks! Looks like these have been fixed.

teabee89• 9 years ago

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

abstractbeliefs2• 9 years ago

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?

porjo• 9 years ago

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

nabla9• 9 years ago

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.

_uhtu2• 9 years ago

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.

Kenji3• 9 years ago

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.

_uhtu2• 9 years ago

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?

greenhouse_gas2• 9 years ago

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.

tdb7893• 9 years ago

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

callahad6• 9 years ago

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.

irrational3• 9 years ago

"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.

anowell• 9 years ago

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.

tracker12• 9 years ago

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.

tshannon• 9 years ago

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.

nickthemagicman• 9 years ago

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

judah• 9 years ago

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

dangerbird2• 9 years ago

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

vertex-four• 9 years ago

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.

n00b1013• 9 years ago

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.

bcoates• 9 years ago

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

Gaelan• 9 years ago

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.

white-flame• 9 years ago

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.

tannhaeuser• 9 years ago

    - DRM

paxcoder2• 9 years ago

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.

thristian• 9 years ago

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

Games, and WebGL games in particular.

paxcoder2• 9 years ago

Surely they're not chasing native just for games

A cartoon intro to WebAssembly

Related Stories