24 ms·

Experimental support for WebAssembly in V8

394 points by AndrewDucker 11y ago

amelius 11y ago
Will WebAssembly allow us to create custom video codecs? Or is there still a bottleneck somewhere that makes this unrealistic?
- espadrine 11y ago
  You could already make video codecs in JS, or in C using asm.js. It is absolutely realistic; see for instance the jsmpeg project: https://github.com/phoboslab/jsmpeg https://github.com/phoboslab/jsmpeg. It is unlikely to ever compete battery-wise with hardware support for a codec, however.
  - jfbastien 11y ago
    Right: direct hardware support can't be beat. Once WebAssembly has solid SIMD support and memory management that allows zero-copy then it should be* as good as it gets without direct hardware support. * Assuming we're smart about security check elimination and SIMD codegen, which are both hard to do right.
    - chrisseaton 11y ago
      I don't think WebAssembly is likely to be any faster than JavaScript is it? It's literally the same compiler in V8.
      - Cthulhu_ 11y ago
        Oh but it is; see also asm.js, which is a subset of JS that removes a lot of the potential performance bottlenecks by removing those features from JS (mostly having to do with JS' dynamic nature, iirc). Or in other words: javascript is an interpreted script language, webassembly is a compiled binary format.
        chrisseaton 11y ago
        > Or in other words: javascript is an interpreted script language, webassembly is a compiled binary format. They're both just-in-time compiled. It doesn't matter if your program comes in as source code or a binary format if you're compiling it dynamically. But I didn't know that WebAssembly ran under asm.js semantics. I guess that's the difference.
        jfbastien 11y ago
        WebAssembly has its own semantics, similar to asm.js (statically typed) but much cleaner because it doesn't need to map onto JavaScript.
      - espadrine 11y ago
        Unoptimized JS compared to unoptimized C compiled to wasm is likely to be slower, although if you only care about hitting 60fps, it doesn't matter if the unoptimized JS already hits that consistently. If you care about GC pauses, wasm is much less likely to be affected. Finally, if you compare asm.js to wasm, wasm will have a speedier load time, especially for large projects. > It's literally the same compiler in V8. AFAIK, V8 has bailouts for JS code, while wasm code cannot bail out. It uses the same compiler as when JS code gets JITted, but it is AOT.
      - deleted 11y ago
        [deleted]
    - CyberDildonics 11y ago
      Are you guys taking a look at Intel's ISPC language? I haven't seen anything even come close as far as SIMD speed goes. It is open and compiles to LLVM -> .o + .h files.
      - eggy 11y ago
        Is the ISPC language what they used to help Edge via the Chakra engine per this [1], and the other browser engines would have to do the same, or am I misunderstanding your reference? [1] https://blogs.windows.com/msedgedev/2015/05/21/intel-and-microsoft-partnering-for-an-improved-web-experience/ https://blogs.windows.com/msedgedev/2015/05/21/intel-and-mic...
        CyberDildonics 11y ago
        I don't know, but I doubt it. Maybe there is knowledge transfer there, but ISPC is a separate language that uses a 'varying' keyword to control whether a variable represents a SIMD 'gang' or not.
  - TD-Linux 11y ago
    Here's another example, using more modern codecs: https://brionv.com/misc/ogv.js/demo/ https://brionv.com/misc/ogv.js/demo/ It's used in production on Wikipedia: https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/ogv.js https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/o...
batmansmk 11y ago
It is a wonderful news. Firefox version is ready too.
sunfish 11y ago
The big news here is coordinated announcements from multiple browsers: https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-experiments/ https://blogs.windows.com/msedgedev/2016/03/15/previewing-we... https://v8project.blogspot.com/2016/03/experimental-support-for-webassembly.html https://v8project.blogspot.com/2016/03/experimental-support-... https://hacks.mozilla.org/2016/03/a-webassembly-milestone/ https://hacks.mozilla.org/2016/03/a-webassembly-milestone/ introducing support for the live demo: https://webassembly.github.io/demo/ https://webassembly.github.io/demo/
- espadrine 11y ago
  A WebKit announcement is notably missing, unfortunately. However, it is great to see Edge, even though it is not a surprise, as they have been pushing for WebAssembly from the start.
  - jfbastien 11y ago
    "In development": https://webkit.org/status/#specification-webassembly https://webkit.org/status/#specification-webassembly
  - sunfish 11y ago
    WebAssembly is "In Development" on WebKit's status page: https://webkit.org/status/#specification-webassembly https://webkit.org/status/#specification-webassembly
    - jacobolus 11y ago
      Also cf. https://bugs.webkit.org/show_bug.cgi?id=146064 https://bugs.webkit.org/show_bug.cgi?id=146064
- s3th 11y ago
  Yes! It's the compatibility of more than one implementation, each running the same WebAssembly binary that makes me so excited about this milestone.
- 11y ago
sp332 11y ago
Are there any plans to run WebAssembly outside of a browser? Would it be difficult (once the binary format is nailed down) to distribute a standalone program?
- sunfish 11y ago
  Yes; the WebAssembly project has some ideas on this here: https://github.com/WebAssembly/design/blob/master/NonWeb.md https://github.com/WebAssembly/design/blob/master/NonWeb.md
- deleted 11y ago
  [deleted]
- CyberDildonics 11y ago
  I think if it really takes off and the shared memory parallelism works well it could end up being a pretty potent part of software delivery.
- tracker1 11y ago
  Given that node.js uses v8, and there are a few options for stand-alone distribution of node-based apps [1], I'm sure there will be many options (by the end of the year most likely)... Though, I'm not sure why you wouldn't take a more direct approach to building your code to different platform targets directly if you're using a compile language already... though if you're building web and want a standalone, I can see that. [1] http://stackoverflow.com/a/12486874/43906 http://stackoverflow.com/a/12486874/43906
  - sp332 11y ago
    But you only have to compile once for all platforms (famous last words, I know). Including future platforms, platforms you don't know about, and platforms you don't care about but your users do.
moron4hire 11y ago
This is going to be huge for the WebVR community. The demo actually ran great on my janky laptop, whereas the ASM.js version at a lower resolution ran at the considerably crappy level I had come to expect of Unity HTML5-built apps on an Intel integrated GPU. Faster = more efficient, also, so equivalent demos should burn less battery power on my smartphone as well, which means less heat build up, which means a longer time before the GPU throttles down.
titzer 11y ago
Standard caveats apply here. It's experimental: a couple bugfixes are already in flight and we're working hard on improving the startup time. Overall a huge thanks to our friends at Mozilla and Microsoft and Apple, with whom we've worked closely with over the past year to make this a reality.
Illniyar 11y ago
This is moving fast. Does anyone know if theres a webassembly to js compiler to support legacy browsers?
- s3th 11y ago
  The Emscripten toolchain can be used to produce both WebAssembly and asm.js from the same codebase [0]. There are also the nascent beginnings of a translation tool from WebAssembly to asm.js here [1] (look for wasm2asm). Ultimately, it should be possible to write a streaming polyfill for WebAssembly, but no one has gotten around to making anything suitable for production yet. You're better off producing a separate fallback asm.js bundle for now. [0]: https://github.com/kripken/emscripten/wiki/WebAssembly https://github.com/kripken/emscripten/wiki/WebAssembly [1]: https://github.com/webassembly/binaryen https://github.com/webassembly/binaryen
- alimbada 11y ago
  Yes, you should have a read of the FAQ: https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
systems 11y ago
does this mean i wont have to learn javascript, css, d3, svg, typescript, jquery, etc ... to make webistes and web apps
- benjoffe 11y ago
  You don't need any of those to make websites and web apps already (or to be less pednantic, you don't need most of those) so I'm not sure what your question is.
  - megalodon 11y ago
    No idea why this was downvoted, you are correct. Furthermore d3, typescript and jquery is javascript so the question is more like "do I need to learn how to use tools to make websites?" at which point it is kind of silly.
    - iLoch 11y ago
      They're being downvoted because show me useful website that doesn't have any of those things. Yes, it's technically correct to say that you don't need any of those things, but totally pedantic because you WILL use any number of them for ANY real website.
      - megalodon 11y ago
        Here you go: http://arxiv.org http://arxiv.org No javascript needed to make a perfectly functional, efficient and useful website. Maybe it doesn't fit into your description of a "real" website?
        iLoch 11y ago
        Uses CSS, though. Which is also on that list.
      - tomjen3 11y ago
        Most if not all use CSS and javascript, but he mentioned a ton of techniques in such a way as to imply that most websites use all of them or that you needed to know all of them to do web development. That is just not true. I am sure that most web developers don't know d3, svg (other than exporting it from a drawing program) or typescript.
anthk 11y ago
The day WebAssembly is pushed into mainstream I'd use a web browser with no support for it at all.
- pohl 11y ago
  And, should that come to pass, what would your rationale be for going out of your way to avoid it?
- 83457 11y ago
  Lynx?
  - swiley 11y ago
    I always use elinks when I'm trying to get work done as anything worth reading (documentation etc) works just fine in it but you don't have all the distracting "web stuff".
- coldtea 11y ago
  And nobody really cares. Especially without a reasoning given...
- trose 11y ago
  Do you have reasoning behind that or do you just enjoy grandstanding with pedantic statements?
- koder2016 11y ago
  Developed by free-roaming coders fed on organic-certified food.
  - matt4077 11y ago
    Hey – as a self-declared food-nerd I resent you comparing me with this self-important JS-luddite.
- BuckRogers 11y ago
  > The day WebAssembly is pushed into mainstream I'd use a web browser with no support for it at all. I'm guessing you're a JS diehard that doesn't want to see other languages hit the web? I'm not aware of any other reasons why you'd fight this otherwise.
tadlan 11y ago
Question please: Even though there is stated desire to support python etc vm, this will be hampered by the need for the client to download the large VM vs native code that can be distributed itself, correct?
- jfbastien 11y ago
  Correct, though we're working on dynamic linking to ease the pain, and improving compilers such as LLVM so that the generated code is smaller.
  - tadlan 11y ago
    Thanks. I'm not familiar with dynamic linking. What will that do?
    - deleted 11y ago
      [deleted]
    - binji 11y ago
      There's a response above this one from titzer describing it, or you can read more here: https://github.com/WebAssembly/design/blob/master/DynamicLinking.md https://github.com/WebAssembly/design/blob/master/DynamicLin...
xigency 11y ago
Finally, a reason to go into JavaScript development with a background in compilers! I can see the need for cross-compiling tools and certain special skills for performant web development in the future, especially since even with complete adoption of WebAssembly this will still create a split between browsers that support it and browsers that don't. From glossing over the wasm spec, it seems it's designed for C++ compilation, which in the environment I do development, is totally impractical. It sounds like a TypeScript to WebAssembly compiler isn't on Microsoft's radar. In that case, it might be time to work on some tools for analyzing syntax and start annotating types, because compiling from ECMAScript to WebAssembly would be a great boon in production.
- geon 11y ago
  Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm?
  - tomjen3 11y ago
    Game dev here. Speed. Oh and memory - if I could optimize it so that all our vectors, matrices and logic code did only stack allocations I would be a happy camper.
    - anthk 11y ago
      Even Pascal from FreePascal + Lazarus gets better speed than JS with a JIT :S Why don't you compile into native platforms?
  - nfriedly 11y ago
    If nothing else, it results in a smaller download than minified js. (I believe that's true even today.) And, in theory, it should be able to run a bit faster also. Not sure if that one's true yet. Update: Here's a quote from the Microsoft announcement: "Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case." https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-experiments/ https://blogs.windows.com/msedgedev/2016/03/15/previewing-we...
Touche 11y ago
So when is Google going to deprecate Native Client?
- jfbastien 11y ago
  When WebAssembly is further along the capabilities of PNaCl should be polyfillable to WebAssembly, and it would then make sense to ship one fewer VM. Otherwise NaCl and PNaCl have a solid track record of running code near native speed in an extremely secure sandbox. It's under Chrome's Vulnerability Reward Program, you're welcome to look for payoffs ;-)
crudbug 11y ago
Giant Leap for Web Platform. How is the mapping from wasm to asm done, at all? Are they directly mapping from web world to native world in a sandbox ?
- sbierwagen 11y ago
  https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
  - crudbug 11y ago
    {Any Language} => WASM => {OPTIMIZATION/COMPILATION} => NATIVE CODE
gregwtmtno 11y ago
I see the comments here are overwhelmingly positive, so I will keep an open mind. That said, someone please correct me if I'm wrong, but this runs binary code loaded over the internet in your browser? As a free-software advocate, this concerns me.
- deleted 11y ago
  [deleted]
- jfbastien 11y ago
  Software isn't free because you can see its source. JavaScript is no free-er, and no more view-source-able when minified, than WebAssembly is. View-source is an explicit goal of WebAssembly's first launch: https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
- s3th 11y ago
  WebAssembly is an open source runtime developed under the governance of a W3C Community Group [0]. The binaries that get sent over the wire are simply more efficient ways to pack existing types of code. We will soon have a textual encoding that makes modules easy to introspect [1] and we have a long list of tooling plans to make sure that the web stays open and debuggable [2]. [0]: https://www.w3.org/community/webassembly/ https://www.w3.org/community/webassembly/ [1]: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... [2]: https://github.com/WebAssembly/design/blob/master/Tooling.md https://github.com/WebAssembly/design/blob/master/Tooling.md
  - kuschku 11y ago
    Great! We should make sure that browsers refuse to run any code in the future that isn’t available in its full source. Yes, that includes ReCaptcha /me looks angrily at Google
    - dlubarov 11y ago
noiv 11y ago
That three major browser teams implement and publish a new standard/technology at the same time is exciting. OTOH I can't believe we start over again with Assembler (a machine language).
- dlubarov 11y ago
  Well it's not really machine code, since no hardware uses wasm as its native instruction set; it's just low level bytecode. And it's really intended as a compilation target; I don't think anyone wants or expects average web developers to code in wasm.
  - noiv 11y ago
    Well, it runs on a virtual machine, not that much different. And the design doc states "writing by hand", but the s-expressions look interesting. Finally Lisp for browsers :)
z3t4 11y ago
It might sound like a stupid question, but is it faster then vanilla JavaScript!?
- spriggan3 11y ago
  Yes since it's lower level, and No since you'll still be limited to Web APIs like Javascript. The code isn't being executed outside the browser like a Java applet or Flash.
xhrpost 11y ago
I know programmers sometimes write directly in assembly for certain performance enhancements and certain hardware access. Is there a foreseeable reason someone would program directly in WebAssembly though? I realize that's not the reason this technology exists, just curious.
- hutzlibu 11y ago
  As far as I understands, this should be doable. But it would probably be much easier to use another (static) language for the parts you want to optimize, compile to wasm and then access them in your js code.
- abecedarius 11y ago
  When asm.js came out I ported http://wry.me/hacking/Turing-Drawings http://wry.me/hacking/Turing-Drawings to use it. It would've made as much performance sense to do the same for WebAssembly. This is not quite the same as hand-coding WebAssembly -- it's making a custom code generator for a little language.
BinaryIdiot 11y ago
Oh man I'm very excited about this! Great job all around! Web Assembly should make code more portable and faster on the web. No more transpiling to JavaScript (which honestly is a hack; going from one language to another language which is then compiled). If you want to use CoffeeScript, even though I dislike it, you'll be able to compile directly to WebAssembly instead. I can't wait until this is fully baked with DOM access, etc.
- jfbastien 11y ago
  Transpiling some dynamic languages to JS is still sensible. WebAssembly is initially for static languages, and eventually (with JIT and GC support) it'll be usable as a building block to host dynamic language VMs.
  - BinaryIdiot 11y ago
    > Transpiling some dynamic languages to JS is still sensible. It's still practical, today, should you want to use something other than JS but I don't think it's that sensible. You take one language's syntax and idiosyncrasies, convert it to another language with its own, sometimes differing, idiosyncrasies and now you have to debug it, sometimes in a different language than it was written it. I don't mind TypeScript or any of the others but I think WebAssembly is what makes those language great; transpiling to JavaScript is a hack. Just imagine ECMAScript 7 then ECMAScript 8 support coming in very quickly after announcement because your JavaScript now compiles to WebAssembly. You won't have to wait or deal with browsers that are lacking the necessary APIs; it'll "just work" because it's all compiled to WebAssembly.
    - ZenoArrow 11y ago
      That's not what jfbastien is saying. The point is, until the time when WebAssembly has a GC and a JIT, many dynamic languages simply won't be able to target WebAssembly (unless the dynamic language developers create their own bespoke JIT/GC), so you may as well stick to targeting JS. At the point at which WebAssembly gets a JIT and GC, then the situation changes.
kin 11y ago
Is there any news for WebAssembly on mobile browsers?
- jfbastien 11y ago
  It should "just work", but we're still at the experimental stage right now so it may break randomly. It's not production quality yet, but mobile is a first-class platform for launch.
iLoch 11y ago
Hmm, I wonder if and what people will switch to when they're not forced to use Javascript. Now any language could become a server side + client side language like JS is now. Will I have the ability to write a library in one language and use it in another as long as they both compile to wasm?
- netghost 11y ago
  Finally I can write in HyperTalk!
  - pekk 11y ago
    The point being that nobody uses or has any good reason to use HyperTalk these days. But the same is not true of many other languages. Javascript is not the last language anyone will ever need.
  - xigency 11y ago
    HyperCard predates the world wide web. It was pretty awesome, too.
- tracker1 11y ago
  WASM can't talk to the DOM directly, you'll still need JS, or a compile-to binding layer. That said, modern JS, aside from getting all the tooling bootstrapped, is pretty nice to work with imho. There are also a lot of compile-to-js options, and with better sourcemap support, it's pretty clean to use. wasm will lean heavily towards code that needs to be more secure, as well as code that needs absolute performance (gaming mostly)... As to security, using a redux-like workflow, where all action creators use message calls to a websocket connected server-side redux store, then the updates dispatched to the client's store to the UI, so that all logic is at the server would probably be a cleaner and more secure abstraction than wasm though.
  - michaelwww 11y ago
    > WASM can't talk to the DOM directly It will according to multiple sources: "In fact, not only will the JavaScript engine be exposed to WebAssembly modules, but so will the DOM. This means you could, in theory, write whole web applications in C and/or C++ and/or other languages that compile into WebAssembly" [1] "Beyond the MVP (Minimum Viable Product), another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects." [2] [1] http://moduscreate.com/webassembly-explained/ http://moduscreate.com/webassembly-explained/ [2] https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
hutzlibu 11y ago
This is great news! And a nice working demo ... And a general question about wasm - since typescript can be strictly typed, would it benefit much, if it would be compiled to wasm?
- CyberDildonics 11y ago
  I think you would want to see how it does when compiled to LLVM IR to answer that question. Also keep in mind that webasm doesn't include a garbage collector. If typescript relies on one, it will need to be compiled to webasm as well.
  - hutzlibu 11y ago
    Ah right, the gc. I doubt you will see much benefit, if you will have to compile him as well. But maybe it is possible to code without ... and free memory yourself with "delete x" or "x=null"
- constexpr 11y ago
  I currently write compilers that target JavaScript and have looked a TypeScript a lot for something like this. In practice, TypeScript isn't actually strictly typed. There is a ton of TypeScript code out there that does stuff like run-time prototype manipulation (mixins, for example), using arbitrary objects as hash tables, and liberal use of the "any" type. So either you cross-compile a JavaScript VM to be able to handle everything (super slow and bloated, especially without the ability to JIT compile executable code) or you pick a small subset of TypeScript to compile, in which case it wouldn't really be TypeScript at all. Plus TypeScript doesn't have integer types (only doubles) so it would generate pretty inefficient code. JavaScript JITs do a lot of work to turn usage of doubles into integers based on run-time behavior that is unknowable at compile-time.
  - hutzlibu 11y ago
    I think I would be happy with the subset and the add of Integers ... Dynamic languages are great for rapid prototyping and debugging, but once the programming is done and everything is clear, I don't realy need stuff like window["foo" + someString](1,2,3) or the "any" type anymore ... I don't think it will be too hard, to "strongtype" your ts or js if there will be such a subset and you have a smart IDE.
fizzbatter 11y ago
Anyone know how difficult Rust -> WebAssembly will be, compared to C++ -> WebAssembly? I'm hoping to switch some of my Go code to Rust, as i imagine Go -> WebAssembly will be much further out _(GC and all)_, so i'm hoping Rust is much sooner in the pipeline.
- jfbastien 11y ago
  "ridiculously easy": https://github.com/rust-lang/rfcs/issues/604 https://github.com/rust-lang/rfcs/issues/604
- grayrest 11y ago
  Should just be replacing Emscripten in the toolchain with Binaryen [1]. [1] https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen
  - brson 11y ago
    This is actually unlikely to be Rust's solution (at least in the long term), because it requires running LLVM IR through emscripten to generate asm.js to generate wasm. Making Rust and emscripten use the same LLVM IR is difficult because emscripten has a large out-of-tree LLVM patch that Rust would need to share. The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.
- brson 11y ago
  Ridiculously easy. It's all but done already via the emscripten port [1]. The emscripten port though is hampered by needing a large out-of-tree patch to LLVM. Once the LLVM wasm backend is ready upstream there will be little left but to just turn it on. [1]: https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154 https://internals.rust-lang.org/t/need-help-with-emscripten-...
- tracker1 11y ago
  It's worth noting that there are llvm compiler options for go. So as soon as llvm supports a wasm target, you should be able to keep your go code in tact, or at least minimal changes...
iagooar 11y ago
When I read news like this, I think: this is the cool stuff you should be doing, not maintaining a lousy e-commerce shop...
- cududa 11y ago
  I work on OS level stuff myself, but I find this comment insulting. What are you even working on?
bobajeff 11y ago
I wonder if Google has any plans on using C++ in any of their web applications now. Might help them improve Google Docs a lot if they could utilize some mature C++ libraries from a desktop word processor.
- nly 11y ago
  Google can already run whatever code they want on your docs server side.
formula1 11y ago
More importantly, will rust compile to wasm one day?
- sp332 11y ago
  It's already an LLVM backend, so yes?
- rbalicki 11y ago
  https://users.rust-lang.org/t/rust-to-js-with-emscripten/587 https://users.rust-lang.org/t/rust-to-js-with-emscripten/587 There's been interest in compiling to JS for a while. I don't follow Rust closely, so I'm not sure how much progress there has been.
  - steveklabnik 11y ago
    Lots! We're getting really close, actually.
- stuaxo 11y ago
  Run Servo in Servo
legutierr 11y ago
Does anyone who is familiar with WebAssembly development know what kinds of things Dynamic Linking (mentioned among the future features) will enable? For instance, would it permit the creation of optimized WebAssembly libraries written in C++ that could be called by a JavasSript program (say, for things like image processing)? Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser? Because that would pretty cool.
- tyingq 11y ago
  >>Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser? The hard part there is the "eventually". They do state that the missing pieces will come some time after the "Minimum Viable Product", but none of it sounds high priority. - The current course omits features that would be needed for any dynamically typed language (including Python) to work. (garbage collectors, polymorphic inline cache, etc) - The current course also prevents anything running in the WebAssembly space from accessing the DOM. You can call your WebAssembly from javascript, but that's it. I suspect it will be quite a while before there's more available than "call LLVM created libraries from javascript". Technically, you could, I suppose put the entire cpython codebase into webassembly, but that seems like more of parlor trick than something useful.
- titzer 11y ago
  You can already do some of that without the dynamic linking feature. There is a JS API to instantiate a WebAssembly module, providing JS functions that are callable as external functions from within the WASM module. Conversely the WASM module exports functions that are callable directly from JS. This allows rudimentary interop between JS and WASM, and dynamic linking will make it possible to deliver your WASM application in separate pieces, e.g. a large, rarely-changing library that is cached, precompiled, by the browser, and a small, often-changing application piece.
megaman821 11y ago
Would there be any benefit to compiling dynamic languages with GCs (like Python or Ruby) to WASM? It is cool that is technically possible, but this looks like a target for C, C++, and Rust code.
- jfbastien 11y ago
  C Python and Ruby should "just work" because you can compile their GC into you wasm module. More general-purpose GC will be supported, but not in the initial release: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
- abhianet 11y ago
  It is more attractive to look at WASM as a way to bring a lot of other languages into the web. We are already transpiling a lot of code, ES7, TypeScript, ClojureScript, Dart, and so on. I would say WASM makes a lot better target than JS will ever be.
tracker1 11y ago
I can't help but to think that this could be a huge win for binary modules in node.js, as it could finally allow for cross-platform, prebuilt binary modules without the tight coupling and build dependencies that are currently needed.
spriggan3 11y ago
Great news, this is the beginning of the "Javascript Less" movement.
- ludamad 11y ago
  It'll be really interesting if people think of JavaScript more as a highly available scripting language, rather than a necessity.
spriggan3 11y ago
So who's going to be first to recreate an entire Flash runtime for WASM? ;)
- bobajeff 11y ago
  Well hopefully Adobe does this. No one else has really been able to make a full flash implementation. It probably won't be as fast though but for legacy Flash content that would be fine.
- ludamad 11y ago
  I don't see enough about Shumway given the recognized security impetus
- al2o3cr 11y ago
  Even better, port the JVM and the applet infrastructure for maximum "remember the last time we did this exact thing" retro-lulz.
  - spriggan3 11y ago
    > Even better, port the JVM and the applet infrastructure for maximum "remember the last time we did this exact thing" retro-lulz. You cant port the entire applet infrastructure since WASM is limited to the same API as Javascript. If WASM doesn't support multithreading, languages targetting WASM wont.
    - ant6n 11y ago
      You can always support multi-threading by not doing multi-threading.
    - daurnimator 11y ago
      But it does support multithreading. Things missing are usually specific external protocols. e.g. being able to make a TCP socket; (or higher level things like ignoring CORS).
  - mobiuscog 11y ago
shurcooL 11y ago
This is really exciting, because it's going on a great path and it's a matter of time before all this is available out of the box! Is anyone working on a Go to WebAssembly compiler yet?
- ZenoArrow 11y ago
  > "Is anyone working on a Go to WebAssembly compiler yet?" I don't think that'll work until WebAssembly has GC, which isn't likely to be ready for a while.
  - nulltype 11y ago
    Go has it's own GC, so why would it need WebAssembly's? Does web assembly disallow programs from doing their own GC?
    - ZenoArrow 11y ago
      Go has a GC that runs on top of an OS. The virtual machines that run WebAssembly are highly likely to have different mechanisms to manage memory compared to an OS that Go runs on, so Go's GC will not work 'out of the box'. This leaves two options: 1. Go developers could write a GC especially designed to enable Go on WebAssembly. 2. Go developers could wait until WebAssembly gets its own GC implementation, and make use of that. Considering option 2 is less work, and that a GC for WebAssembly is on the WebAssembly roadmap (check the GitHib page for details), I'd suggest option 2 is what will end up happening.
neals 11y ago
Is this in a state where I can go and try making experiments in webassembly?
- azakai 11y ago
  It's a little early, so things are not easy to use yet. Spec still changes, tools still change and break, nothing is optimized for convenience yet, etc. But here is how to use emscripten to emit WebAssembly currently, https://github.com/kripken/emscripten/wiki/WebAssembly https://github.com/kripken/emscripten/wiki/WebAssembly
dccoolgai 11y ago
For all the complaining about it, I think I will actually be a little sad to see Javascript go. It wasn't perfect, but it had a powerful unifying effect on the Web Community when we could write, share and learn about our code in a higher-level scripting language that we could all read. (Even if there were some surprising little quirks that took a while to get used to.) Despite the stated intention from WASM - there is just something fundamental about AST trees - no matter how well you pretty-print them - that doesn't allow sharing and shared learning the same way. As a run-of-the-mill guy who makes my bread maintaining websites as much as greenfield-developing them, I feel like I'm in for a bit of a rough ride trying to decipher and debug binary/AST code compiled from Perl (or whatever). Guess I'll have to suck it up and learn to do it, though.
- jfbastien 11y ago
  JS isn't going anywhere. wasm and JS are a dynamic duo, complement each other.
  - kelvin0 11y ago
    Yeah, the VM is the same but allows low-level JS instructions to run. So next step, is to build a <your favorite language> to webasm transpiler and not have to use JS again ... :) I believe emscriptem is already doing this for C/C++
  - dccoolgai 11y ago
    It seems like they "could" complement each other, but that's not a defining characteristic of WASM. WASM, as I understand it, essentially allows me to take my higher-level language like Python/Haskell/Perl/(Maybe also JS) and compile an AST that can be interpreted by the engine on the client-side. Which is great for Python/Haskell/Perl developers that they no longer have to pay the toll of learning/sharing/contributing to JS - they are Haskell devs, maybe they shouldn't have to contribute to JS. We can call that a good thing, but let's not pretend that doesn't marginalize JS (which - again!! - maybe it should). "But they still don't have access to the DOM" is not much of an impediment to that Perl dev, and means as your run-of-the-mill guy I now have to debug the Perl-produced WASM AST (Maybe pretty-printing will let me read it in 5 hours instead of 12, but I'm still reading binary/AST which does not seem like an awesome time) and the cruft from whatever Perl-WASM binding library they forked from Github. Again - I know this makes life better for that Perl dev, and maybe he/she deserves it. But unless I'm missing something, I don't see how allowing that dev to (basically) skip JS in their path from whatever IDE Perl devs use to the Web makes WASM "chummy" with Javascript. In fact, it seems like now that dev will start making/contributing to libraries that conform to their stack (Perl-specific web libraries that compile to WASM). Now if I want to contribute to that library - which is now a part of the web - I have to learn Perl. Before, that Perl dev would have had to learn Javascript - which I know sucks for them - but it was good for me and good for Javascript... and I would say "good for the web". We were all speaking the same language, which led to an explosion of learning and collaboration. Sure, .3 != .1 + .2 But it was that way for all of us. Now everyone is going to go back to their own little feifdoms and just tipping their hat to JS along the way with a lightweight DOM binding port.
ilaksh 11y ago
Nim, which is objectively the best programming language, is perfect for Web Assembly.
randyrand 11y ago
Anyone gonna write an LLVM backend for this? =D mouth waters
- jfbastien 11y ago
  Done https://github.com/llvm-mirror/llvm/tree/master/lib/Target/WebAssembly https://github.com/llvm-mirror/llvm/tree/master/lib/Target/W...
- sunfish 11y ago
  Already on it :-). https://github.com/llvm-mirror/llvm/tree/master/lib/Target/WebAssembly https://github.com/llvm-mirror/llvm/tree/master/lib/Target/W... (linked to the Github mirror because the LLVM viewvc is currently down)

394 points by AndrewDucker 11y ago

Will WebAssembly allow us to create custom video codecs? Or is there still a bottleneck somewhere that makes this unrealistic?

espadrine 11y ago
You could already make video codecs in JS, or in C using asm.js. It is absolutely realistic; see for instance the jsmpeg project: https://github.com/phoboslab/jsmpeg https://github.com/phoboslab/jsmpeg. It is unlikely to ever compete battery-wise with hardware support for a codec, however.
- jfbastien 11y ago
  Right: direct hardware support can't be beat. Once WebAssembly has solid SIMD support and memory management that allows zero-copy then it should be* as good as it gets without direct hardware support. * Assuming we're smart about security check elimination and SIMD codegen, which are both hard to do right.
  - chrisseaton 11y ago
    I don't think WebAssembly is likely to be any faster than JavaScript is it? It's literally the same compiler in V8.
    - Cthulhu_ 11y ago
      Oh but it is; see also asm.js, which is a subset of JS that removes a lot of the potential performance bottlenecks by removing those features from JS (mostly having to do with JS' dynamic nature, iirc). Or in other words: javascript is an interpreted script language, webassembly is a compiled binary format.
      - chrisseaton 11y ago
        > Or in other words: javascript is an interpreted script language, webassembly is a compiled binary format. They're both just-in-time compiled. It doesn't matter if your program comes in as source code or a binary format if you're compiling it dynamically. But I didn't know that WebAssembly ran under asm.js semantics. I guess that's the difference.
        jfbastien 11y ago
        WebAssembly has its own semantics, similar to asm.js (statically typed) but much cleaner because it doesn't need to map onto JavaScript.
    - espadrine 11y ago
      Unoptimized JS compared to unoptimized C compiled to wasm is likely to be slower, although if you only care about hitting 60fps, it doesn't matter if the unoptimized JS already hits that consistently. If you care about GC pauses, wasm is much less likely to be affected. Finally, if you compare asm.js to wasm, wasm will have a speedier load time, especially for large projects. > It's literally the same compiler in V8. AFAIK, V8 has bailouts for JS code, while wasm code cannot bail out. It uses the same compiler as when JS code gets JITted, but it is AOT.
    - deleted 11y ago
      [deleted]
  - CyberDildonics 11y ago
    Are you guys taking a look at Intel's ISPC language? I haven't seen anything even come close as far as SIMD speed goes. It is open and compiles to LLVM -> .o + .h files.
    - eggy 11y ago
      Is the ISPC language what they used to help Edge via the Chakra engine per this [1], and the other browser engines would have to do the same, or am I misunderstanding your reference? [1] https://blogs.windows.com/msedgedev/2015/05/21/intel-and-microsoft-partnering-for-an-improved-web-experience/ https://blogs.windows.com/msedgedev/2015/05/21/intel-and-mic...
      - CyberDildonics 11y ago
        I don't know, but I doubt it. Maybe there is knowledge transfer there, but ISPC is a separate language that uses a 'varying' keyword to control whether a variable represents a SIMD 'gang' or not.
- TD-Linux 11y ago
  Here's another example, using more modern codecs: https://brionv.com/misc/ogv.js/demo/ https://brionv.com/misc/ogv.js/demo/ It's used in production on Wikipedia: https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/ogv.js https://www.mediawiki.org/wiki/Extension:TimedMediaHandler/o...

batmansmk 11y ago

It is a wonderful news. Firefox version is ready too.

sunfish 11y ago

The big news here is coordinated announcements from multiple browsers: https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-experiments/ https://blogs.windows.com/msedgedev/2016/03/15/previewing-we... https://v8project.blogspot.com/2016/03/experimental-support-for-webassembly.html https://v8project.blogspot.com/2016/03/experimental-support-... https://hacks.mozilla.org/2016/03/a-webassembly-milestone/ https://hacks.mozilla.org/2016/03/a-webassembly-milestone/ introducing support for the live demo: https://webassembly.github.io/demo/ https://webassembly.github.io/demo/

espadrine 11y ago
A WebKit announcement is notably missing, unfortunately. However, it is great to see Edge, even though it is not a surprise, as they have been pushing for WebAssembly from the start.
- jfbastien 11y ago
  "In development": https://webkit.org/status/#specification-webassembly https://webkit.org/status/#specification-webassembly
- sunfish 11y ago
  WebAssembly is "In Development" on WebKit's status page: https://webkit.org/status/#specification-webassembly https://webkit.org/status/#specification-webassembly
  - jacobolus 11y ago
    Also cf. https://bugs.webkit.org/show_bug.cgi?id=146064 https://bugs.webkit.org/show_bug.cgi?id=146064
s3th 11y ago
Yes! It's the compatibility of more than one implementation, each running the same WebAssembly binary that makes me so excited about this milestone.
11y ago

sp332 11y ago

Are there any plans to run WebAssembly outside of a browser? Would it be difficult (once the binary format is nailed down) to distribute a standalone program?

sunfish 11y ago
Yes; the WebAssembly project has some ideas on this here: https://github.com/WebAssembly/design/blob/master/NonWeb.md https://github.com/WebAssembly/design/blob/master/NonWeb.md
deleted 11y ago
[deleted]
CyberDildonics 11y ago
I think if it really takes off and the shared memory parallelism works well it could end up being a pretty potent part of software delivery.
tracker1 11y ago
Given that node.js uses v8, and there are a few options for stand-alone distribution of node-based apps [1], I'm sure there will be many options (by the end of the year most likely)... Though, I'm not sure why you wouldn't take a more direct approach to building your code to different platform targets directly if you're using a compile language already... though if you're building web and want a standalone, I can see that. [1] http://stackoverflow.com/a/12486874/43906 http://stackoverflow.com/a/12486874/43906
- sp332 11y ago
  But you only have to compile once for all platforms (famous last words, I know). Including future platforms, platforms you don't know about, and platforms you don't care about but your users do.

moron4hire 11y ago

This is going to be huge for the WebVR community. The demo actually ran great on my janky laptop, whereas the ASM.js version at a lower resolution ran at the considerably crappy level I had come to expect of Unity HTML5-built apps on an Intel integrated GPU. Faster = more efficient, also, so equivalent demos should burn less battery power on my smartphone as well, which means less heat build up, which means a longer time before the GPU throttles down.

titzer 11y ago

Standard caveats apply here. It's experimental: a couple bugfixes are already in flight and we're working hard on improving the startup time. Overall a huge thanks to our friends at Mozilla and Microsoft and Apple, with whom we've worked closely with over the past year to make this a reality.

Illniyar 11y ago

This is moving fast. Does anyone know if theres a webassembly to js compiler to support legacy browsers?

s3th 11y ago
The Emscripten toolchain can be used to produce both WebAssembly and asm.js from the same codebase [0]. There are also the nascent beginnings of a translation tool from WebAssembly to asm.js here [1] (look for wasm2asm). Ultimately, it should be possible to write a streaming polyfill for WebAssembly, but no one has gotten around to making anything suitable for production yet. You're better off producing a separate fallback asm.js bundle for now. [0]: https://github.com/kripken/emscripten/wiki/WebAssembly https://github.com/kripken/emscripten/wiki/WebAssembly [1]: https://github.com/webassembly/binaryen https://github.com/webassembly/binaryen
alimbada 11y ago
Yes, you should have a read of the FAQ: https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md

systems 11y ago

does this mean i wont have to learn javascript, css, d3, svg, typescript, jquery, etc ... to make webistes and web apps

benjoffe 11y ago
You don't need any of those to make websites and web apps already (or to be less pednantic, you don't need most of those) so I'm not sure what your question is.
- megalodon 11y ago
  No idea why this was downvoted, you are correct. Furthermore d3, typescript and jquery is javascript so the question is more like "do I need to learn how to use tools to make websites?" at which point it is kind of silly.
  - iLoch 11y ago
    They're being downvoted because show me useful website that doesn't have any of those things. Yes, it's technically correct to say that you don't need any of those things, but totally pedantic because you WILL use any number of them for ANY real website.
    - megalodon 11y ago
      Here you go: http://arxiv.org http://arxiv.org No javascript needed to make a perfectly functional, efficient and useful website. Maybe it doesn't fit into your description of a "real" website?
      - iLoch 11y ago
        Uses CSS, though. Which is also on that list.
    - tomjen3 11y ago
      Most if not all use CSS and javascript, but he mentioned a ton of techniques in such a way as to imply that most websites use all of them or that you needed to know all of them to do web development. That is just not true. I am sure that most web developers don't know d3, svg (other than exporting it from a drawing program) or typescript.

anthk 11y ago

The day WebAssembly is pushed into mainstream I'd use a web browser with no support for it at all.

pohl 11y ago
And, should that come to pass, what would your rationale be for going out of your way to avoid it?
83457 11y ago
Lynx?
- swiley 11y ago
  I always use elinks when I'm trying to get work done as anything worth reading (documentation etc) works just fine in it but you don't have all the distracting "web stuff".
coldtea 11y ago
And nobody really cares. Especially without a reasoning given...
trose 11y ago
Do you have reasoning behind that or do you just enjoy grandstanding with pedantic statements?
koder2016 11y ago
Developed by free-roaming coders fed on organic-certified food.
- matt4077 11y ago
  Hey – as a self-declared food-nerd I resent you comparing me with this self-important JS-luddite.
BuckRogers 11y ago
> The day WebAssembly is pushed into mainstream I'd use a web browser with no support for it at all. I'm guessing you're a JS diehard that doesn't want to see other languages hit the web? I'm not aware of any other reasons why you'd fight this otherwise.

tadlan 11y ago

Question please: Even though there is stated desire to support python etc vm, this will be hampered by the need for the client to download the large VM vs native code that can be distributed itself, correct?

jfbastien 11y ago
Correct, though we're working on dynamic linking to ease the pain, and improving compilers such as LLVM so that the generated code is smaller.
- tadlan 11y ago
  Thanks. I'm not familiar with dynamic linking. What will that do?
  - deleted 11y ago
    [deleted]
  - binji 11y ago
    There's a response above this one from titzer describing it, or you can read more here: https://github.com/WebAssembly/design/blob/master/DynamicLinking.md https://github.com/WebAssembly/design/blob/master/DynamicLin...

xigency 11y ago

Finally, a reason to go into JavaScript development with a background in compilers! I can see the need for cross-compiling tools and certain special skills for performant web development in the future, especially since even with complete adoption of WebAssembly this will still create a split between browsers that support it and browsers that don't. From glossing over the wasm spec, it seems it's designed for C++ compilation, which in the environment I do development, is totally impractical. It sounds like a TypeScript to WebAssembly compiler isn't on Microsoft's radar. In that case, it might be time to work on some tools for analyzing syntax and start annotating types, because compiling from ECMAScript to WebAssembly would be a great boon in production.

geon 11y ago
Why on earth would you want to compile javascript (which is what typescript essentially is) to wasm?
- tomjen3 11y ago
  Game dev here. Speed. Oh and memory - if I could optimize it so that all our vectors, matrices and logic code did only stack allocations I would be a happy camper.
  - anthk 11y ago
    Even Pascal from FreePascal + Lazarus gets better speed than JS with a JIT :S Why don't you compile into native platforms?
- nfriedly 11y ago
  If nothing else, it results in a smaller download than minified js. (I believe that's true even today.) And, in theory, it should be able to run a bit faster also. Not sure if that one's true yet. Update: Here's a quote from the Microsoft announcement: "Despite being an early implementation, the demo starts-up significantly faster than just using asm.js as the WebAssembly binaries have a smaller file size and parse more quickly than plain JavaScript that needs to be parsed in the asm.js case." https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-experiments/ https://blogs.windows.com/msedgedev/2016/03/15/previewing-we...

Touche 11y ago

So when is Google going to deprecate Native Client?

jfbastien 11y ago
When WebAssembly is further along the capabilities of PNaCl should be polyfillable to WebAssembly, and it would then make sense to ship one fewer VM. Otherwise NaCl and PNaCl have a solid track record of running code near native speed in an extremely secure sandbox. It's under Chrome's Vulnerability Reward Program, you're welcome to look for payoffs ;-)

crudbug 11y ago

Giant Leap for Web Platform. How is the mapping from wasm to asm done, at all? Are they directly mapping from web world to native world in a sandbox ?

sbierwagen 11y ago
https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
- crudbug 11y ago
  {Any Language} => WASM => {OPTIMIZATION/COMPILATION} => NATIVE CODE

gregwtmtno 11y ago

I see the comments here are overwhelmingly positive, so I will keep an open mind. That said, someone please correct me if I'm wrong, but this runs binary code loaded over the internet in your browser? As a free-software advocate, this concerns me.

deleted 11y ago
[deleted]
jfbastien 11y ago
Software isn't free because you can see its source. JavaScript is no free-er, and no more view-source-able when minified, than WebAssembly is. View-source is an explicit goal of WebAssembly's first launch: https://github.com/WebAssembly/design/blob/master/FAQ.md#will-webassembly-support-view-source-on-the-web https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
s3th 11y ago
WebAssembly is an open source runtime developed under the governance of a W3C Community Group [0]. The binaries that get sent over the wire are simply more efficient ways to pack existing types of code. We will soon have a textual encoding that makes modules easy to introspect [1] and we have a long list of tooling plans to make sure that the web stays open and debuggable [2]. [0]: https://www.w3.org/community/webassembly/ https://www.w3.org/community/webassembly/ [1]: https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat... [2]: https://github.com/WebAssembly/design/blob/master/Tooling.md https://github.com/WebAssembly/design/blob/master/Tooling.md
- kuschku 11y ago
  Great! We should make sure that browsers refuse to run any code in the future that isn’t available in its full source. Yes, that includes ReCaptcha /me looks angrily at Google
  - dlubarov 11y ago

noiv 11y ago

That three major browser teams implement and publish a new standard/technology at the same time is exciting. OTOH I can't believe we start over again with Assembler (a machine language).

dlubarov 11y ago
Well it's not really machine code, since no hardware uses wasm as its native instruction set; it's just low level bytecode. And it's really intended as a compilation target; I don't think anyone wants or expects average web developers to code in wasm.
- noiv 11y ago
  Well, it runs on a virtual machine, not that much different. And the design doc states "writing by hand", but the s-expressions look interesting. Finally Lisp for browsers :)

z3t4 11y ago

It might sound like a stupid question, but is it faster then vanilla JavaScript!?

spriggan3 11y ago
Yes since it's lower level, and No since you'll still be limited to Web APIs like Javascript. The code isn't being executed outside the browser like a Java applet or Flash.

xhrpost 11y ago

I know programmers sometimes write directly in assembly for certain performance enhancements and certain hardware access. Is there a foreseeable reason someone would program directly in WebAssembly though? I realize that's not the reason this technology exists, just curious.

hutzlibu 11y ago
As far as I understands, this should be doable. But it would probably be much easier to use another (static) language for the parts you want to optimize, compile to wasm and then access them in your js code.
abecedarius 11y ago
When asm.js came out I ported http://wry.me/hacking/Turing-Drawings http://wry.me/hacking/Turing-Drawings to use it. It would've made as much performance sense to do the same for WebAssembly. This is not quite the same as hand-coding WebAssembly -- it's making a custom code generator for a little language.

BinaryIdiot 11y ago

Oh man I'm very excited about this! Great job all around! Web Assembly should make code more portable and faster on the web. No more transpiling to JavaScript (which honestly is a hack; going from one language to another language which is then compiled). If you want to use CoffeeScript, even though I dislike it, you'll be able to compile directly to WebAssembly instead. I can't wait until this is fully baked with DOM access, etc.

jfbastien 11y ago
Transpiling some dynamic languages to JS is still sensible. WebAssembly is initially for static languages, and eventually (with JIT and GC support) it'll be usable as a building block to host dynamic language VMs.
- BinaryIdiot 11y ago
  > Transpiling some dynamic languages to JS is still sensible. It's still practical, today, should you want to use something other than JS but I don't think it's that sensible. You take one language's syntax and idiosyncrasies, convert it to another language with its own, sometimes differing, idiosyncrasies and now you have to debug it, sometimes in a different language than it was written it. I don't mind TypeScript or any of the others but I think WebAssembly is what makes those language great; transpiling to JavaScript is a hack. Just imagine ECMAScript 7 then ECMAScript 8 support coming in very quickly after announcement because your JavaScript now compiles to WebAssembly. You won't have to wait or deal with browsers that are lacking the necessary APIs; it'll "just work" because it's all compiled to WebAssembly.
  - ZenoArrow 11y ago
    That's not what jfbastien is saying. The point is, until the time when WebAssembly has a GC and a JIT, many dynamic languages simply won't be able to target WebAssembly (unless the dynamic language developers create their own bespoke JIT/GC), so you may as well stick to targeting JS. At the point at which WebAssembly gets a JIT and GC, then the situation changes.

kin 11y ago

Is there any news for WebAssembly on mobile browsers?

jfbastien 11y ago
It should "just work", but we're still at the experimental stage right now so it may break randomly. It's not production quality yet, but mobile is a first-class platform for launch.

iLoch 11y ago

Hmm, I wonder if and what people will switch to when they're not forced to use Javascript. Now any language could become a server side + client side language like JS is now. Will I have the ability to write a library in one language and use it in another as long as they both compile to wasm?

netghost 11y ago
Finally I can write in HyperTalk!
- pekk 11y ago
  The point being that nobody uses or has any good reason to use HyperTalk these days. But the same is not true of many other languages. Javascript is not the last language anyone will ever need.
- xigency 11y ago
  HyperCard predates the world wide web. It was pretty awesome, too.
tracker1 11y ago
WASM can't talk to the DOM directly, you'll still need JS, or a compile-to binding layer. That said, modern JS, aside from getting all the tooling bootstrapped, is pretty nice to work with imho. There are also a lot of compile-to-js options, and with better sourcemap support, it's pretty clean to use. wasm will lean heavily towards code that needs to be more secure, as well as code that needs absolute performance (gaming mostly)... As to security, using a redux-like workflow, where all action creators use message calls to a websocket connected server-side redux store, then the updates dispatched to the client's store to the UI, so that all logic is at the server would probably be a cleaner and more secure abstraction than wasm though.
- michaelwww 11y ago
  > WASM can't talk to the DOM directly It will according to multiple sources: "In fact, not only will the JavaScript engine be exposed to WebAssembly modules, but so will the DOM. This means you could, in theory, write whole web applications in C and/or C++ and/or other languages that compile into WebAssembly" [1] "Beyond the MVP (Minimum Viable Product), another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects." [2] [1] http://moduscreate.com/webassembly-explained/ http://moduscreate.com/webassembly-explained/ [2] https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md

hutzlibu 11y ago

This is great news! And a nice working demo ... And a general question about wasm - since typescript can be strictly typed, would it benefit much, if it would be compiled to wasm?

CyberDildonics 11y ago
I think you would want to see how it does when compiled to LLVM IR to answer that question. Also keep in mind that webasm doesn't include a garbage collector. If typescript relies on one, it will need to be compiled to webasm as well.
- hutzlibu 11y ago
  Ah right, the gc. I doubt you will see much benefit, if you will have to compile him as well. But maybe it is possible to code without ... and free memory yourself with "delete x" or "x=null"
constexpr 11y ago
I currently write compilers that target JavaScript and have looked a TypeScript a lot for something like this. In practice, TypeScript isn't actually strictly typed. There is a ton of TypeScript code out there that does stuff like run-time prototype manipulation (mixins, for example), using arbitrary objects as hash tables, and liberal use of the "any" type. So either you cross-compile a JavaScript VM to be able to handle everything (super slow and bloated, especially without the ability to JIT compile executable code) or you pick a small subset of TypeScript to compile, in which case it wouldn't really be TypeScript at all. Plus TypeScript doesn't have integer types (only doubles) so it would generate pretty inefficient code. JavaScript JITs do a lot of work to turn usage of doubles into integers based on run-time behavior that is unknowable at compile-time.
- hutzlibu 11y ago
  I think I would be happy with the subset and the add of Integers ... Dynamic languages are great for rapid prototyping and debugging, but once the programming is done and everything is clear, I don't realy need stuff like window["foo" + someString](1,2,3) or the "any" type anymore ... I don't think it will be too hard, to "strongtype" your ts or js if there will be such a subset and you have a smart IDE.

fizzbatter 11y ago

Anyone know how difficult Rust -> WebAssembly will be, compared to C++ -> WebAssembly? I'm hoping to switch some of my Go code to Rust, as i imagine Go -> WebAssembly will be much further out _(GC and all)_, so i'm hoping Rust is much sooner in the pipeline.

jfbastien 11y ago
"ridiculously easy": https://github.com/rust-lang/rfcs/issues/604 https://github.com/rust-lang/rfcs/issues/604
grayrest 11y ago
Should just be replacing Emscripten in the toolchain with Binaryen [1]. [1] https://github.com/WebAssembly/binaryen https://github.com/WebAssembly/binaryen
- brson 11y ago
  This is actually unlikely to be Rust's solution (at least in the long term), because it requires running LLVM IR through emscripten to generate asm.js to generate wasm. Making Rust and emscripten use the same LLVM IR is difficult because emscripten has a large out-of-tree LLVM patch that Rust would need to share. The wasm backend though is in upstream LLVM, so rustc can use it directly, bypassing emscripten for translation of Rust.
brson 11y ago
Ridiculously easy. It's all but done already via the emscripten port [1]. The emscripten port though is hampered by needing a large out-of-tree patch to LLVM. Once the LLVM wasm backend is ready upstream there will be little left but to just turn it on. [1]: https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154 https://internals.rust-lang.org/t/need-help-with-emscripten-...
tracker1 11y ago
It's worth noting that there are llvm compiler options for go. So as soon as llvm supports a wasm target, you should be able to keep your go code in tact, or at least minimal changes...

iagooar 11y ago

When I read news like this, I think: this is the cool stuff you should be doing, not maintaining a lousy e-commerce shop...

cududa 11y ago
I work on OS level stuff myself, but I find this comment insulting. What are you even working on?

bobajeff 11y ago

I wonder if Google has any plans on using C++ in any of their web applications now. Might help them improve Google Docs a lot if they could utilize some mature C++ libraries from a desktop word processor.

nly 11y ago
Google can already run whatever code they want on your docs server side.

formula1 11y ago

More importantly, will rust compile to wasm one day?

sp332 11y ago
It's already an LLVM backend, so yes?
rbalicki 11y ago
https://users.rust-lang.org/t/rust-to-js-with-emscripten/587 https://users.rust-lang.org/t/rust-to-js-with-emscripten/587 There's been interest in compiling to JS for a while. I don't follow Rust closely, so I'm not sure how much progress there has been.
- steveklabnik 11y ago
  Lots! We're getting really close, actually.
stuaxo 11y ago
Run Servo in Servo

legutierr 11y ago

Does anyone who is familiar with WebAssembly development know what kinds of things Dynamic Linking (mentioned among the future features) will enable? For instance, would it permit the creation of optimized WebAssembly libraries written in C++ that could be called by a JavasSript program (say, for things like image processing)? Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser? Because that would pretty cool.

tyingq 11y ago
>>Would it eventually permit library sharing between, say, a Python runtime compiled to WebAsembly and JavaScript in the browser? The hard part there is the "eventually". They do state that the missing pieces will come some time after the "Minimum Viable Product", but none of it sounds high priority. - The current course omits features that would be needed for any dynamically typed language (including Python) to work. (garbage collectors, polymorphic inline cache, etc) - The current course also prevents anything running in the WebAssembly space from accessing the DOM. You can call your WebAssembly from javascript, but that's it. I suspect it will be quite a while before there's more available than "call LLVM created libraries from javascript". Technically, you could, I suppose put the entire cpython codebase into webassembly, but that seems like more of parlor trick than something useful.
titzer 11y ago
You can already do some of that without the dynamic linking feature. There is a JS API to instantiate a WebAssembly module, providing JS functions that are callable as external functions from within the WASM module. Conversely the WASM module exports functions that are callable directly from JS. This allows rudimentary interop between JS and WASM, and dynamic linking will make it possible to deliver your WASM application in separate pieces, e.g. a large, rarely-changing library that is cached, precompiled, by the browser, and a small, often-changing application piece.

megaman821 11y ago

Would there be any benefit to compiling dynamic languages with GCs (like Python or Ruby) to WASM? It is cool that is technically possible, but this looks like a target for C, C++, and Rust code.

jfbastien 11y ago
C Python and Ruby should "just work" because you can compile their GC into you wasm module. More general-purpose GC will be supported, but not in the initial release: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
abhianet 11y ago
It is more attractive to look at WASM as a way to bring a lot of other languages into the web. We are already transpiling a lot of code, ES7, TypeScript, ClojureScript, Dart, and so on. I would say WASM makes a lot better target than JS will ever be.

tracker1 11y ago

I can't help but to think that this could be a huge win for binary modules in node.js, as it could finally allow for cross-platform, prebuilt binary modules without the tight coupling and build dependencies that are currently needed.

spriggan3 11y ago

Great news, this is the beginning of the "Javascript Less" movement.

ludamad 11y ago
It'll be really interesting if people think of JavaScript more as a highly available scripting language, rather than a necessity.

spriggan3 11y ago

So who's going to be first to recreate an entire Flash runtime for WASM? ;)

bobajeff 11y ago
Well hopefully Adobe does this. No one else has really been able to make a full flash implementation. It probably won't be as fast though but for legacy Flash content that would be fine.
ludamad 11y ago
I don't see enough about Shumway given the recognized security impetus
al2o3cr 11y ago
Even better, port the JVM and the applet infrastructure for maximum "remember the last time we did this exact thing" retro-lulz.
- spriggan3 11y ago
  > Even better, port the JVM and the applet infrastructure for maximum "remember the last time we did this exact thing" retro-lulz. You cant port the entire applet infrastructure since WASM is limited to the same API as Javascript. If WASM doesn't support multithreading, languages targetting WASM wont.
  - ant6n 11y ago
    You can always support multi-threading by not doing multi-threading.
  - daurnimator 11y ago
    But it does support multithreading. Things missing are usually specific external protocols. e.g. being able to make a TCP socket; (or higher level things like ignoring CORS).
- mobiuscog 11y ago

shurcooL 11y ago

This is really exciting, because it's going on a great path and it's a matter of time before all this is available out of the box! Is anyone working on a Go to WebAssembly compiler yet?

ZenoArrow 11y ago
> "Is anyone working on a Go to WebAssembly compiler yet?" I don't think that'll work until WebAssembly has GC, which isn't likely to be ready for a while.
- nulltype 11y ago
  Go has it's own GC, so why would it need WebAssembly's? Does web assembly disallow programs from doing their own GC?
  - ZenoArrow 11y ago
    Go has a GC that runs on top of an OS. The virtual machines that run WebAssembly are highly likely to have different mechanisms to manage memory compared to an OS that Go runs on, so Go's GC will not work 'out of the box'. This leaves two options: 1. Go developers could write a GC especially designed to enable Go on WebAssembly. 2. Go developers could wait until WebAssembly gets its own GC implementation, and make use of that. Considering option 2 is less work, and that a GC for WebAssembly is on the WebAssembly roadmap (check the GitHib page for details), I'd suggest option 2 is what will end up happening.

neals 11y ago

Is this in a state where I can go and try making experiments in webassembly?

azakai 11y ago
It's a little early, so things are not easy to use yet. Spec still changes, tools still change and break, nothing is optimized for convenience yet, etc. But here is how to use emscripten to emit WebAssembly currently, https://github.com/kripken/emscripten/wiki/WebAssembly https://github.com/kripken/emscripten/wiki/WebAssembly

dccoolgai 11y ago

For all the complaining about it, I think I will actually be a little sad to see Javascript go. It wasn't perfect, but it had a powerful unifying effect on the Web Community when we could write, share and learn about our code in a higher-level scripting language that we could all read. (Even if there were some surprising little quirks that took a while to get used to.) Despite the stated intention from WASM - there is just something fundamental about AST trees - no matter how well you pretty-print them - that doesn't allow sharing and shared learning the same way. As a run-of-the-mill guy who makes my bread maintaining websites as much as greenfield-developing them, I feel like I'm in for a bit of a rough ride trying to decipher and debug binary/AST code compiled from Perl (or whatever). Guess I'll have to suck it up and learn to do it, though.

jfbastien 11y ago
JS isn't going anywhere. wasm and JS are a dynamic duo, complement each other.
- kelvin0 11y ago
  Yeah, the VM is the same but allows low-level JS instructions to run. So next step, is to build a <your favorite language> to webasm transpiler and not have to use JS again ... :) I believe emscriptem is already doing this for C/C++
- dccoolgai 11y ago
  It seems like they "could" complement each other, but that's not a defining characteristic of WASM. WASM, as I understand it, essentially allows me to take my higher-level language like Python/Haskell/Perl/(Maybe also JS) and compile an AST that can be interpreted by the engine on the client-side. Which is great for Python/Haskell/Perl developers that they no longer have to pay the toll of learning/sharing/contributing to JS - they are Haskell devs, maybe they shouldn't have to contribute to JS. We can call that a good thing, but let's not pretend that doesn't marginalize JS (which - again!! - maybe it should). "But they still don't have access to the DOM" is not much of an impediment to that Perl dev, and means as your run-of-the-mill guy I now have to debug the Perl-produced WASM AST (Maybe pretty-printing will let me read it in 5 hours instead of 12, but I'm still reading binary/AST which does not seem like an awesome time) and the cruft from whatever Perl-WASM binding library they forked from Github. Again - I know this makes life better for that Perl dev, and maybe he/she deserves it. But unless I'm missing something, I don't see how allowing that dev to (basically) skip JS in their path from whatever IDE Perl devs use to the Web makes WASM "chummy" with Javascript. In fact, it seems like now that dev will start making/contributing to libraries that conform to their stack (Perl-specific web libraries that compile to WASM). Now if I want to contribute to that library - which is now a part of the web - I have to learn Perl. Before, that Perl dev would have had to learn Javascript - which I know sucks for them - but it was good for me and good for Javascript... and I would say "good for the web". We were all speaking the same language, which led to an explosion of learning and collaboration. Sure, .3 != .1 + .2 But it was that way for all of us. Now everyone is going to go back to their own little feifdoms and just tipping their hat to JS along the way with a lightweight DOM binding port.

ilaksh 11y ago

Nim, which is objectively the best programming language, is perfect for Web Assembly.

randyrand 11y ago

Anyone gonna write an LLVM backend for this? =D mouth waters

jfbastien 11y ago
Done https://github.com/llvm-mirror/llvm/tree/master/lib/Target/WebAssembly https://github.com/llvm-mirror/llvm/tree/master/lib/Target/W...
sunfish 11y ago
Already on it :-). https://github.com/llvm-mirror/llvm/tree/master/lib/Target/WebAssembly https://github.com/llvm-mirror/llvm/tree/master/lib/Target/W... (linked to the Github mirror because the LLVM viewvc is currently down)