7 ms·

Web Assembly

135 points by Siecje 11y ago

purplerabbit 11y ago
Been checking in on this since the initial hubbub a few months ago... It would be great if it started to swing into high gear. I'm still in love with the idea of a language-agnostic, web-centric compilation target, but I think we should all emotionally prepare for 10+ years before it's feasible to use in production, let alone well-integrated with our favorite languages.
- s3th 11y ago
  Things are definitely picking up speed! There are already a bunch of awesome community implementations of the MVP WebAssembly spec [0][1][2]. Meanwhile, the V8 [3], SpiderMonkey [4], Chakra [5], and JSC [6] teams have all started work on implementing wasm in actual browser engines. We've still got a long ways to go, but it's much nearer than 10+ years! [0]: https://github.com/WebAssembly/wasm-jit-prototype https://github.com/WebAssembly/wasm-jit-prototype [1]: https://github.com/WebAssembly/wasmint https://github.com/WebAssembly/wasmint [2]: https://github.com/WebAssembly/wasm-aot-prototype https://github.com/WebAssembly/wasm-aot-prototype [3]: https://github.com/WebAssembly/v8-native-prototype https://github.com/WebAssembly/v8-native-prototype [4]: http://hg.mozilla.org/mozilla-central/file/ca086f9ef8bc/js/src/asmjs/AsmJSValidate.cpp#l2510 http://hg.mozilla.org/mozilla-central/file/ca086f9ef8bc/js/s... [5]: http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/working-on-the-future-of-compile-to-web-applications.aspx http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/workin... [6]: https://bugs.webkit.org/show_bug.cgi?id=146064 https://bugs.webkit.org/show_bug.cgi?id=146064 (Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
  - biggestbob 11y ago
    Very good news! It is exciting. I am looking forward to this.
  - ilaksh 11y ago
    What about Servo?
    - jmhain 11y ago
      Servo uses SpiderMonkey.
  - purplerabbit 11y ago
    Very happy to hear this! I greatly appreciate an update from the inside
- tracker1 11y ago
  I'd guess 3-5 if you look at most penetration once an initial implementation takes hold in browsers... now, you may have upwards of 30-40% of people not covered by a feature, but that doesn't mean you can't target it... it comes down to your audience... If MS actually keeps its' promise of rolling releases, or closer to it this time, it could be much sooner than later.
  - fulafel 11y ago
    This doesn't require browser support though. https://github.com/WebAssembly/design/blob/master/FAQ.md#can-the-polyfill-really-be-efficient https://github.com/WebAssembly/design/blob/master/FAQ.md#can...
TranquilMarmot 11y ago
I imagine a future where instead of the DOM, everything is driven by WebGL with logic being in Web Assembly. So, basically... a standardized game engine, running across all platforms. Almost feels like a throwback to the days of entirely flash-based websites......
- nathancahill 11y ago
  It feels exactly like a throwback to the days of entirely flash-based websites. Not entirely sure how I feel about that.
  - ino 11y ago
    Big regression in accessibility, copy/paste, automatic translation, everything that makes the web uniquely great.
    - jacobolus 11y ago
      The #1 thing that makes the web uniquely great is that all you need to do to access a program is to paste a short string into a box, and your browser takes care of the rest. Anyone can slap a website onto a server they control, and anyone in the world can then access it. Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s not without reason that Photoshop, ProTools, Maya, Excel, Final Cut, SolidWorks, ArcGIS, Sibelius, Mathematica, Visual Studio, and thousands of other serious tools don’t have credible web alternatives.) They’re slower. They aren’t persistent. They change all the time with no ability for the user to prevent it, sometimes spontaneously breaking when the developer stops supporting the user’s browser or goes out of business. They make it hard for users to load/save local data, and instead they store personal data on a faraway server. Accidentally pressing the back button can destroy hours of user work. They usually have terrible accessibility. They don’t interoperate with other applications on the system. They flagrantly violate UI design conventions on every platform. They can’t access most local hardware devices. They have an extremely limited user input device model. Their UI layout tools are limited, inflexible, and incredibly hard to work with. They throw out decades of implementation effort on various standard solutions to problems and force complete reimplementation from scratch. They are difficult or impossible to build proper cryptographic primitives on top of. In short, web applications are inherently second-class citizens on every platform. BUT! Web applications are also amazing. Dropping the barrier to entry – URLs and HTTP and fairly reliable code sandboxing – makes all the difference, and makes the web an extremely attractive platform despite its many flaws.
cauterize 11y ago
As someone who works in the web space, albeit on the back-end, can anyone explain why a project like this is desired over a better language / run-time?
- jfb 11y ago
  I guess the argument boils down to "path dependence". We're highly unlikely to get any language environment other than Javascript, so mutate Javascript to try and strong-arm it into something better.
- richdougherty 11y ago
  wasm and asm.js are perfect examples of incremental improvements rather than building something from scratch. The benefit of this is that incremental improvements can be built slowly on top of existing deployed JavaScript engines, whereas writing something from scratch has a serious bootstrapping problem. The wasm/asm.js story goes like this so far: 1. emscripten, a JavaScript backend for LLVM, demonstrates that you can "compile" C/C++ code into JavaScript. 2. Some vendors start writing specific optimisations for emscripten-style JavaScript code. 3. This is formalised into a subset of JavaScript called asm.js. 4. More browser vendors get onboard with asm.js optimisations. 5. wasm is proposed. Initially it is a compact binary format that is equivalent to asm.js and that can be trivially translated into asm.js at runtime using a polyfill. The future might look like this: 6. Browsers adopt wasm natively, so the asm.js shim can be dropped, giving more performance benefits. 7. Further enhancements to wasm follow and wasm perhaps begins to diverge from its underlying JavaScript runtime. 8. ???
  - cpeterso 11y ago
    How long until someone implements WebAssembly instructions in hardware? ARM's "Jazelle" supported some JVM instructions in hardware.
    - h1282227 11y ago
      Hardware support only makes sense if the optimisations are already included in the compiler output. The JVM does all the optimisations which makes Java Bytecode not suitable for that purpose.
dccoolgai 11y ago
With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what APIs are getting called. Difficult to see how one could do the same with wasm. Not saying wasm is a bad idea (i think it's good), I'm just concerned about what this will look like in terms of keeping the nuts and bolts of the web semi-readable.
- s3th 11y ago
  It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
  - pdkl95 11y ago
    The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will introduce the Halting Problem in to a lot more areas. The concern isn't asm.js - it's frameworks like angular (no-content-without-js websites are already a problem). The availability of a parse tree doesn't help if I have to run it to access the structure that is current available in the DOM. With the current drama over adblopcking, I expect advertisers will jump at a technology that lets them treat clients as something they control. (compile an obfuscated version of freetype into small WebAssembly download will be be the key features).
    - reissbaker 11y ago
      This is uneducated FUD. WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to run, it's killed. There's no reason that would be any different with a faster-to-parse and smaller-in-bytesize compilation target, which is all that WASM is. If "the concern isn't asm.js — it's frameworks like angular," then — what? Angular already exists, and is written in regular JS. No new compilation target needed. And in regards to ad-blocking: what? Ad-blocking works by not running (or loading) content from specific, known advertising networks. That would work regardless of whether the content was written in WASM or asm.js or regular JS or anything else. Just block the network requests and you're done.
tantalor 11y ago
Here are some examples of the text/debug format, 1. factorial in S-expressions: https://github.com/WebAssembly/spec/blob/master/ml-proto/test/fac.wast https://github.com/WebAssembly/spec/blob/master/ml-proto/tes... 2. ray tracing in a C style: https://github.com/ncbray/wassembler/blob/master/demos/raytrace.wasm https://github.com/ncbray/wassembler/blob/master/demos/raytr...
z3t4 11y ago
Why can't virtualization and containing of the app be done on a OS level? Why do we need the browser to run "web" apps?
- nikbackm 11y ago
  Which OS?

135 points by Siecje 11y ago

Been checking in on this since the initial hubbub a few months ago... It would be great if it started to swing into high gear. I'm still in love with the idea of a language-agnostic, web-centric compilation target, but I think we should all emotionally prepare for 10+ years before it's feasible to use in production, let alone well-integrated with our favorite languages.

s3th 11y ago
Things are definitely picking up speed! There are already a bunch of awesome community implementations of the MVP WebAssembly spec [0][1][2]. Meanwhile, the V8 [3], SpiderMonkey [4], Chakra [5], and JSC [6] teams have all started work on implementing wasm in actual browser engines. We've still got a long ways to go, but it's much nearer than 10+ years! [0]: https://github.com/WebAssembly/wasm-jit-prototype https://github.com/WebAssembly/wasm-jit-prototype [1]: https://github.com/WebAssembly/wasmint https://github.com/WebAssembly/wasmint [2]: https://github.com/WebAssembly/wasm-aot-prototype https://github.com/WebAssembly/wasm-aot-prototype [3]: https://github.com/WebAssembly/v8-native-prototype https://github.com/WebAssembly/v8-native-prototype [4]: http://hg.mozilla.org/mozilla-central/file/ca086f9ef8bc/js/src/asmjs/AsmJSValidate.cpp#l2510 http://hg.mozilla.org/mozilla-central/file/ca086f9ef8bc/js/s... [5]: http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/working-on-the-future-of-compile-to-web-applications.aspx http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/workin... [6]: https://bugs.webkit.org/show_bug.cgi?id=146064 https://bugs.webkit.org/show_bug.cgi?id=146064 (Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
- biggestbob 11y ago
  Very good news! It is exciting. I am looking forward to this.
- ilaksh 11y ago
  What about Servo?
  - jmhain 11y ago
    Servo uses SpiderMonkey.
- purplerabbit 11y ago
  Very happy to hear this! I greatly appreciate an update from the inside
tracker1 11y ago
I'd guess 3-5 if you look at most penetration once an initial implementation takes hold in browsers... now, you may have upwards of 30-40% of people not covered by a feature, but that doesn't mean you can't target it... it comes down to your audience... If MS actually keeps its' promise of rolling releases, or closer to it this time, it could be much sooner than later.
- fulafel 11y ago
  This doesn't require browser support though. https://github.com/WebAssembly/design/blob/master/FAQ.md#can-the-polyfill-really-be-efficient https://github.com/WebAssembly/design/blob/master/FAQ.md#can...

TranquilMarmot 11y ago

I imagine a future where instead of the DOM, everything is driven by WebGL with logic being in Web Assembly. So, basically... a standardized game engine, running across all platforms. Almost feels like a throwback to the days of entirely flash-based websites......

nathancahill 11y ago
It feels exactly like a throwback to the days of entirely flash-based websites. Not entirely sure how I feel about that.
- ino 11y ago
  Big regression in accessibility, copy/paste, automatic translation, everything that makes the web uniquely great.
  - jacobolus 11y ago
    The #1 thing that makes the web uniquely great is that all you need to do to access a program is to paste a short string into a box, and your browser takes care of the rest. Anyone can slap a website onto a server they control, and anyone in the world can then access it. Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s not without reason that Photoshop, ProTools, Maya, Excel, Final Cut, SolidWorks, ArcGIS, Sibelius, Mathematica, Visual Studio, and thousands of other serious tools don’t have credible web alternatives.) They’re slower. They aren’t persistent. They change all the time with no ability for the user to prevent it, sometimes spontaneously breaking when the developer stops supporting the user’s browser or goes out of business. They make it hard for users to load/save local data, and instead they store personal data on a faraway server. Accidentally pressing the back button can destroy hours of user work. They usually have terrible accessibility. They don’t interoperate with other applications on the system. They flagrantly violate UI design conventions on every platform. They can’t access most local hardware devices. They have an extremely limited user input device model. Their UI layout tools are limited, inflexible, and incredibly hard to work with. They throw out decades of implementation effort on various standard solutions to problems and force complete reimplementation from scratch. They are difficult or impossible to build proper cryptographic primitives on top of. In short, web applications are inherently second-class citizens on every platform. BUT! Web applications are also amazing. Dropping the barrier to entry – URLs and HTTP and fairly reliable code sandboxing – makes all the difference, and makes the web an extremely attractive platform despite its many flaws.

cauterize 11y ago

As someone who works in the web space, albeit on the back-end, can anyone explain why a project like this is desired over a better language / run-time?

jfb 11y ago
I guess the argument boils down to "path dependence". We're highly unlikely to get any language environment other than Javascript, so mutate Javascript to try and strong-arm it into something better.
richdougherty 11y ago
wasm and asm.js are perfect examples of incremental improvements rather than building something from scratch. The benefit of this is that incremental improvements can be built slowly on top of existing deployed JavaScript engines, whereas writing something from scratch has a serious bootstrapping problem. The wasm/asm.js story goes like this so far: 1. emscripten, a JavaScript backend for LLVM, demonstrates that you can "compile" C/C++ code into JavaScript. 2. Some vendors start writing specific optimisations for emscripten-style JavaScript code. 3. This is formalised into a subset of JavaScript called asm.js. 4. More browser vendors get onboard with asm.js optimisations. 5. wasm is proposed. Initially it is a compact binary format that is equivalent to asm.js and that can be trivially translated into asm.js at runtime using a polyfill. The future might look like this: 6. Browsers adopt wasm natively, so the asm.js shim can be dropped, giving more performance benefits. 7. Further enhancements to wasm follow and wasm perhaps begins to diverge from its underlying JavaScript runtime. 8. ???
- cpeterso 11y ago
  How long until someone implements WebAssembly instructions in hardware? ARM's "Jazelle" supported some JVM instructions in hardware.
  - h1282227 11y ago
    Hardware support only makes sense if the optimisations are already included in the compiler output. The JVM does all the optimisations which makes Java Bytecode not suitable for that purpose.

dccoolgai 11y ago

With the adoption of wasm, won't the web become inherently less hackable? Right now i can pretty-print some minified js and at least have a basic idea of what APIs are getting called. Difficult to see how one could do the same with wasm. Not saying wasm is a bad idea (i think it's good), I'm just concerned about what this will look like in terms of keeping the nuts and bolts of the web semi-readable.

s3th 11y ago
It's definitely a goal to make sure that wasm is as readable as possible. The binary format will be able to be "pretty-printed" into a textual format [0]. We haven't finalized the exact format yet, but it will be much more readable than current asm.js javascript [1]. [0]: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152 https://twitter.com/BrendanEich/status/643828456631857152 (Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
- pdkl95 11y ago
  The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case). WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will introduce the Halting Problem in to a lot more areas. The concern isn't asm.js - it's frameworks like angular (no-content-without-js websites are already a problem). The availability of a parse tree doesn't help if I have to run it to access the structure that is current available in the DOM. With the current drama over adblopcking, I expect advertisers will jump at a technology that lets them treat clients as something they control. (compile an obfuscated version of freetype into small WebAssembly download will be be the key features).
  - reissbaker 11y ago
    This is uneducated FUD. WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to run, it's killed. There's no reason that would be any different with a faster-to-parse and smaller-in-bytesize compilation target, which is all that WASM is. If "the concern isn't asm.js — it's frameworks like angular," then — what? Angular already exists, and is written in regular JS. No new compilation target needed. And in regards to ad-blocking: what? Ad-blocking works by not running (or loading) content from specific, known advertising networks. That would work regardless of whether the content was written in WASM or asm.js or regular JS or anything else. Just block the network requests and you're done.

tantalor 11y ago

Here are some examples of the text/debug format, 1. factorial in S-expressions: https://github.com/WebAssembly/spec/blob/master/ml-proto/test/fac.wast https://github.com/WebAssembly/spec/blob/master/ml-proto/tes... 2. ray tracing in a C style: https://github.com/ncbray/wassembler/blob/master/demos/raytrace.wasm https://github.com/ncbray/wassembler/blob/master/demos/raytr...

z3t4 11y ago

Why can't virtualization and containing of the app be done on a OS level? Why do we need the browser to run "web" apps?

nikbackm 11y ago
Which OS?