11 ms·

A cartoon intro to WebAssembly

235 points by happy-go-lucky 10y ago

tantalor 10y ago
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-time-jit-compilers/ 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/a-crash-course-in-assembly... https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/ https://hacks.mozilla.org/2017/02/creating-and-working-with-... https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/ https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas... https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-whats-next/ https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...
- Heff 10y ago
  Heh, I was gonna say it seemed pretty low effort.
jrvidal 10y ago
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/2017Feb/0002.html https://lists.w3.org/Archives/Public/public-webassembly/2017...
- callahad 10y ago
  Firefox 52 will ship with WebAssembly support in exactly one week. The era of a JavaScript monoculture on the Web is over.
  - batmansmk 10y ago
    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.
    - callahad 10y ago
      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.
    - tomc1985 10y ago
      How is/was NPAPI a non-event? So many things were built with that!
- theodorton 10y ago
  And they've settled on a logo! https://github.com/WebAssembly/design/issues/980 https://github.com/WebAssembly/design/issues/980
vvanders 10y 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 10y 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 10y 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.
- callahad 10y 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 10y ago
danellis 10y 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 10y 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 10y 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 https://en.wikipedia.org/wiki/Netscape_Enterprise_Server
  - mml 10y ago
    Livewire, it was called, back when you bought your browser in a box at Best Buy.
  - irrational 10y 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 10y 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-fast/ 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
- callahad 10y ago
  Thanks! Looks like these have been fixed.
teabee89 10y ago
I am so afraid that WebAssembly will make too many assumptions that will prevent Go from targeting it as a platform.
- abstractbeliefs 10y 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 10y 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 https://github.com/golang/go/issues/18892
    - abstractbeliefs 10y ago
      Well, thankfully TFA includes a short paragraph talking about the standardisation of exception handling, so here's hoping to have that resolved soon.
deleted 10y ago
[deleted]
nabla9 10y 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.
coltonv 10y 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.
- Kenji 10y 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.
  - coltonv 10y 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?
    - sho_hn 10y ago
      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.
    - deleted 10y ago
      [deleted]
paxcoder 10y 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 10y ago
  > I don't know what number crunching web applications they're thinking of... Games, and WebGL games in particular.
  - paxcoder 10y ago
    Surely they're not chasing native just for games
    - __jal 10y ago
      Search for 'mobile app revenue by category'. I'll wait.

235 points by happy-go-lucky 10y ago

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-time-jit-compilers/ 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/a-crash-course-in-assembly... https://hacks.mozilla.org/2017/02/creating-and-working-with-webassembly-modules/ https://hacks.mozilla.org/2017/02/creating-and-working-with-... https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/ https://hacks.mozilla.org/2017/02/what-makes-webassembly-fas... https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-whats-next/ https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...

Heff 10y ago
Heh, I was gonna say it seemed pretty low effort.

jrvidal 10y ago

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/2017Feb/0002.html https://lists.w3.org/Archives/Public/public-webassembly/2017...

callahad 10y ago
Firefox 52 will ship with WebAssembly support in exactly one week. The era of a JavaScript monoculture on the Web is over.
- batmansmk 10y ago
  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.
  - callahad 10y ago
    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.
  - tomc1985 10y ago
    How is/was NPAPI a non-event? So many things were built with that!
theodorton 10y ago
And they've settled on a logo! https://github.com/WebAssembly/design/issues/980 https://github.com/WebAssembly/design/issues/980

vvanders 10y 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 10y 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 10y 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.
callahad 10y 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 10y ago

danellis 10y 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 10y 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 10y 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 https://en.wikipedia.org/wiki/Netscape_Enterprise_Server
- mml 10y ago
  Livewire, it was called, back when you bought your browser in a box at Best Buy.
- irrational 10y 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 10y 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-fast/ 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

callahad 10y ago
Thanks! Looks like these have been fixed.

teabee89 10y ago

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

abstractbeliefs 10y 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 10y 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 https://github.com/golang/go/issues/18892
  - abstractbeliefs 10y ago
    Well, thankfully TFA includes a short paragraph talking about the standardisation of exception handling, so here's hoping to have that resolved soon.

deleted 10y ago

[deleted]

nabla9 10y 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.

coltonv 10y 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.

Kenji 10y 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.
- coltonv 10y 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?
  - sho_hn 10y ago
    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.
  - deleted 10y ago
    [deleted]

paxcoder 10y 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 10y ago
> I don't know what number crunching web applications they're thinking of... Games, and WebGL games in particular.
- paxcoder 10y ago
  Surely they're not chasing native just for games
  - __jal 10y ago
    Search for 'mobile app revenue by category'. I'll wait.