25 ms·

From Asm.js to WebAssembly

897 points by fabrice_d 11y ago

rhaps0dy 11y ago
Finally. IMO this is what the web has been calling for since AJAX went mainstream. They are doing great work. The client's operating system matters little now, but it will not matter at all soon.
bhouston 11y ago
I guess this is in the spirit of NaCL and its bytecode, and the Java VM/Java bytecode, and the .NET runtime/.NET IR. It makes a lot of sense and I get it then sort of gets competitive with those efforts as well.
- kevingadd 11y ago
  It does compete with those efforts in a sense, but ideally it is going to learn from those efforts and provide a powerful cross-browser equivalent to them instead of just trying to replace them.
- TD-Linux 11y ago
  >NaCL and its bytecode Specifically PNaCL's bytecode. NaCL is a separate product that is native code.
thomasfoster96 11y ago
This is pretty awesome, and is a pretty good use of all the effort that's been going into asm.js One question though - I found a proposal somewhere on a Mozilla run wiki about a web API for registering script transpiling/interpreter engines. I've lost the web address, but if anyone know any more about this is love to see it rekindled.
- thomasfoster96 11y ago
  Found the page: https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Rosetta https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Ro...
- arcatek 11y ago
  I think you're talking about module loaders[1]. I remember seeing on es-discuss that they have been postponed to ES7. [1] https://github.com/lukehoban/es6features#module-loaders https://github.com/lukehoban/es6features#module-loaders
  - thomasfoster96 11y ago
    Functionally that's it (didn't realise it'd been rolled into es6 modules though). Looks like what I was referring to was a third party library: https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Rosetta https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Ro...
rockdoe 11y ago
So this is like PNaCl but targeting the web API and by making it collaborative, hopefully a real standard allowing independent reimplementation? Ironic that Eich is the one to pull the trigger on JS.
- pcwalton 11y ago
  It's not "pulling the trigger" on JS—per the FAQ, it's fully polyfillable and typically implemented inside the JS engine, as essentially a separate interface to all the implementation work that's already there. This is a crucial difference from everything that's been tried before (including PNaCl). JS isn't going anywhere and continues to be improved.
  - JoshTriplett 11y ago
    > JS isn't going anywhere Sure it is. Step 1: get all browsers to support WebAssembly, so that sites can drop the polyfills. Step 2 (specifically noted in the article): make WebAssembly more full-featured than JavaScript, ignoring the ability to polyfill it because browsers have native support. Step 3 (potentially doable before 2): implement JavaScript in WebAssembly, so it becomes just one of many possible languages, and its implementation is no longer beholden to browser quirks. That'll make JavaScript a better language for its proponents (latest ECMAScript features everywhere), and entirely avoidable for people who prefer other languages.
    - trbent 11y ago
      There are a lot of web coders who seem to believe in the most outlandish ideas and who act as if coding ever more rickety stacks is progress.
    - BrendanEich 11y ago
      Dream on. JS is "obligate, not facultative", as biologists say, for browser implementors. It lives in source form on the web and must load super-fast. We can wager about when it might actually die (I said it might given something like wasm, at Strange Loop 2012), but that's beyond the horizon by years if not decades. Gary Bernhardt knows!
jewel 11y ago
I hope that someone ports mruby to this. I've come to terms with javascript's syntax (via coffeescript), but I'd still rather not deal with javascript's semantics.
- azakai 11y ago
  There is already an mruby port to the web using emscripten. When emscripten targets wasm, that port will get that for free.
pcwalton 11y ago
Having been on one side of the perpetual (and tiresome) PNaCl-versus-asm.js debate, I'm thrilled to see a resolution. I really think this is a strategy that combines the best of both worlds. The crucial aspect is that this is polyfillable via JIT compilation to asm.js, so it's still just JavaScript, but it has plenty of room for extensibility to support threads, SIMD, and so forth.
- JoshTriplett 11y ago
  > The crucial aspect is that this is polyfillable via JIT compilation to asm.js So is PNaCl, with pepper.js. The difference there is that PNaCl also provided a more full-featured API, which nonetheless was harder for other browsers to support. Personally, I would have been happy to see NaCl-minus-Pepper standardized, since the sandbox would have been much easier to support than the APIs; browsers could then choose what superset of APIs to expose to that sandbox.
  - kevingadd 11y ago
    pepper.js is ahead-of-time offline compilation, which means it can't adapt to individual target runtimes.
    - JoshTriplett 11y ago
      So is WebAssembly: you'd compile your code to a .wasm file "offline". In both cases, you compile your code to a bytecode format, which the browser then compiles (directly or via JS polyfill) to native code.
      - kevingadd 11y ago
        A key part of WebAssembly's strategy is a polyfill that runs on the client and generates appropriate JS (asm.js or otherwise).
        JoshTriplett 11y ago
kodablah 11y ago
I think the biggest win is https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat.... Now instead of asm.js being only for emscripten-compiled code (or other non-GC code) WebAssembly can be used for higher level, GC'd languages. And even better, https://github.com/WebAssembly/design/blob/master/NonWeb.md https://github.com/WebAssembly/design/blob/master/NonWeb.md, means we may get a new, generic, standalone VM out of this which is always good (I hope I'm not reading in to the details too much). As someone who likes to write compilers/transpilers, I look forward to targetting this.
- JoshTriplett 11y ago
  I'm really hoping that WebAssembly doesn't bake-in higher-level features like garbage collection. That would preclude replacing GC with something better, such as Rust-style memory management. Hopefully this will take more inspiration from actual assembly language and virtual machines, rather than from bytecode languages.
  - kevingadd 11y ago
    it's a virtual machine, but it needs to interop with the rest of the web. at some point this probably means support for garbage collected heaps, but it doesn't mean it's a pervasively-GCd VM like Java. Think more like how WebKit, Gecko and Blink have lots of GC infrastructure in their native, un-GCd code.
    - JoshTriplett 11y ago
      Right, it has to interoperate with DOM objects; however, those can be treated as "foreign" object handles owned by the browser and just referenced by WebAssembly. Those objects can't be directly in the WebAssembly "address space"; that would be unsafe. So since they have to be managed separately anyway, they can use whatever memory model the browser uses.
  - jlongster 11y ago
    I highly doubt it would ever bake in GC semantics. High-perf stuff like games are the biggest push for this kind of thing, where nobody wants a GC. One of the biggest advantages to asm.js right now is predictable performance because of no GC. Most likely an API will be provided for interacting with a garbage collector, but it's completely optional.
JoshTriplett 11y ago
I'm interested to see what the API side of WebAssembly looks like in browsers; hopefully this will make it easier to expose more full-featured sandboxed APIs to languages targeting the web, without having to tailor those APIs to JavaScript. For instance, API calls that actually accept integers and data structures rather than floating-point and objects. For that matter, though in the short-term this will be polyfilled via JavaScript in browsers, it'll be fun to see the first JavaScript-to-WebAssembly compiler that allows you to use the latest ECMAScript features in every browser.
- azakai 11y ago
  The API story for wasm on the web is the set of existing web APIs. That provides the same security model and capabilities as the web has right now. Currently wasm can't access web APIs except by calling out to JS, which would then call the API, but in the future, direct calling paths are intended.
  - JoshTriplett 11y ago
    My hope is that WebAssembly will start motivating a set of lower-level APIs, with higher-level APIs being provided on top of those by WebAssembly "libraries". JavaScript tends to motivate much higher-level APIs, and you can't turn high-level APIs into low-level APIs, only the other way around.
    - tedmielczarek 11y ago
      This seems orthogonal to WebAssembly. This is already a goal for its own sake--see the Extensible Web Manifesto.
M8 11y ago
If I could just use my favourite language and not feel like a second class citizen, then I am not sure there would be anything else to complain about as a developer, really. A mark-up bytecode so that we could forget about the nightmare of HTML and CSS as well?
- angersock 11y ago
  Oh, goody, so now we all get to worry about a more fragmented development ecosystem.
- thomasfoster96 11y ago
  Just start loading a single script tag and ignore HTML and CSS completely. Will severely impact usability and SEO though.
  - wereHamster 11y ago
    The Google Bot executes JavaScript and indexes the result, I don't see why it couldn't run wasm.
    - wodenokoto 11y ago
      While it may very well run the WASM it'll need to interpret the output. How do you rank a running game of candycrush vs. the candycrush website in google results?
    - thomasfoster96 11y ago
      Well, unless you produce HTML dynamically Googlbot supporting JavaScript doesn't really matter.
    - kuschku 11y ago
      The Google Bot. Again, this makes it harder for competitors to ever enter the market.
  - sixdimensional 11y ago
    Actually, I think this might be a great opportunity to separate applications/datum that don't need to be indexed by search engines from those that do. Of course, we have to be careful that we don't get walled off content in applications which can and already does easily happen, but I don't think that is truly in the spirit of the sharing web that we have all come to know and love. There are at least two distinct types of content - structured/unstructured content that should be exposed and can be indexed via some known mechanism by external visitors, and application content that perhaps need not be indexed. This might be a time to evolve/establish what those mechanisms are for the betterment of both application development and content development/sharing.
toomim 11y ago
This new file extension gives me an org.wasm
sixdimensional 11y ago
I think this quote speaks volumes - "WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks." Sometimes I think maybe, just maybe the W3C and other web standards groups finally have some wind behind their sails. It may have taken a while, but with all these individuals and organizations cooperating in an open space, we may finally advance yet again into another new era of innovation for the web. I am really excited about this, much like others in these comments. We have been beating around the bush to have a true assembly/development layer in the browser for a long time: Java applets, Flash, Silverlight, you name it - but no true standard that was open like Javascript is open. This component has the possibility of being the neutral ground that everyone can build on top of. To the creators (Brendan Eich et. al) & supporters, well done and best of luck in this endeavor. It's already started on the right foot (asm.js was what lead the way to this I think) - let's hope they can keep it cooperative and open as much as possible for the benefit of everyone!
- walterbell 11y ago
  > WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks Is Apple participating?
  - andhow 11y ago
    https://bugs.webkit.org/show_bug.cgi?id=146064 https://bugs.webkit.org/show_bug.cgi?id=146064
  - bryanlarsen 11y ago
    Yes: "I’m happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers " https://blog.mozilla.org/luke/2015/06/17/webassembly/ https://blog.mozilla.org/luke/2015/06/17/webassembly/
    - michaelmior 11y ago
      This doesn't seem to necessarily imply that Apple is directly involved. But it's good to know that Safari should be included in this effort.
mhd 11y ago
Combined with something like e.g. Flipboard's react-canvas, this means we could bypass and re-implement most of the browser stack...
deleted 11y ago
[deleted]
ncw33 11y ago
Nice, but I'm still waiting for 64-bit integer arithmetic! For our use case, what I like about this is that we can continue to use emscripten and the technology will come to us, rather than requiring app developers to invest in yet another technology (our switchover from NaCl to emscripten was very time consuming!)
- BrendanEich 11y ago
  64-bit ints coming along with SIMD in ES7^H2016.
amyjess 11y ago
This is probably the best thing that can happen to web development. For quite a while, I've been thinking about how instead of hacks like asm.js, we should be pushing an actual "Web IR" which would actually be designed from the ground up as an IR language. Something similar to PNaCl (a subset of LLVM IR), except divorced from the Chrome sandbox, really.
- mnemonik 11y ago
  asm.js made wasm possible by creating a solid compatibility story and evolutionary path.
- MichaelGG 11y ago
  I think that's what lots of people have thought since the 90s with Java applets. Despite ES6 and "it's not that bad", there's a lot of people that would really like to not have to deal with JS. Edit: Really, it's annoying this didn't happen sooner. If Microsoft would have thought of this early on and pushed it, they could have gained a lead in compilers and developer tools, for instance.
wora 11y ago
Oberon language had a similar system called Juice back in 1997. It does exactly the same thing, e.g. using binary format to store a compressed abstract syntax tree as intermediate format which can be compiled efficiently and quickly. I think it even has a browser plugin much as Java applet. Life has interesting cycles. I don't have the best link to the Juice. [1] https://github.com/berkus/Juice/blob/master/intro.htm https://github.com/berkus/Juice/blob/master/intro.htm [2] ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf
- gecko 11y ago
  Honestly, everything we're doing recently feels like rediscovering Oberon. Oberon had name-based public/private methods, like Go. It had ahead-of-time compilation of bytecode, as you pointed out. It had CSP-style concurrency, again like Go. The web for the last two years feels like we're rediscovering Smalltalk and Oberon and acting like we've just invented everything anew.
  - wora 11y ago
    I originally designed the name-based public/private methods for Go. I didn't know Oberon had the same design.
  - BrendanEich 11y ago
    We didn't acknowledge a debt to Oberon (did Java? It owes one too, Bill Joy evaluated Oberon closely). My pal Michael Franz at UCI studied under Wirth. Michael and a PhD student, Chris Storck, did an AST encoder years back that influenced me and that I referenced re: wasm. Oberon's great. JS was in the right place and right time. What can I say? I've been taking all the best ideas from the best projects and trying to get them incorporated, ever since 1995.
    - gecko 11y ago
      Sorry, just to be clear, I don't see anything wrong at all with raiding the best ideas from older languages. It's actually awesome: it means those ideas get used. I'm genuinely just amused at the cycle.
moron4hire 11y ago
So for now, the idea is to write C++, compile it to ASM.js, translate it into WebAssembly, GZIP it, transmit it, unGZIP it, then run a polyfill to translate the WebAssembly into ASM.js? This sounds absurd. I can't even get through getting Clang, LLVM, and Emscripten built from source as it is, it's such a house-of-cards with configuration and dependency settings. Have any of you tried building Chromium from scratch? I have, on three separate occasions, as I'd like to try to contribute to WebVR. End result: fewer gigs of free space on my hard drive and no Chromium from source. Part of that is my impatience: I'm used to C# and Java, where dependencies are always dynamically linked, the namespacing keeps everything from colliding, and the semantics are very easy to follow. But even Node's braindead NPM dependency manager would be better than the hoops they make you jump through to build open-source C++ projects. I mean, I just don't get how someone could have at any point said "yes, this is a good path, we should continue with this" for all these custom build systems in the wild on these projects. I could be way off. I'm only just reading the FAQ now and I'm not entirely sure I understand what has actually been made versus what has been planned. There seems to be a lot of talk about supporting other languages than C++, but that's what they said about ASM.js, and where did that go? Is anyone using ASM.js in production who is not Archive.org and their arcade emulator? I don't know... I really, really want to like the web browser as a platform. It has its flaws, but it's the least painful solution of all of the completely-cross-platform options. But it's hard. Getting harder. Hard enough I'm starting to wonder if it'd be smarter to develop better deployment strategies for an existing, better programming language than to try to develop better programming languages for the browser's existing, better deployment strategy. This telephone game being played by translator tools and configuration management tools and polyfills and frameworks and... the list goes on! This thing we consider "modern" web development is getting way out of hand. JS's strength used to be that all you needed was a text editor. Everyone--both users and developers--can already use it and run it. If it's just one tool, I'll get over it. But stringing these rickety, half-implemented tools together into a chain of codependent systems is unacceptable. It just feels like they're foisting their inability to finish and properly deploy their work on us. Vagrant recipes are nice, but they should be a convenience, not a necessity. Sorry. Good for them. Just finish something already.
- BrendanEich 11y ago
addisonj 11y ago
Prepare for the onslaught of new (and old) languages targeting the web. While this is welcome news, I am also torn. The possibilities are pretty amazing. Think seamless isomorphic apps in any language that can target WebAssembly and has a virtual dom implementation. However, it finally seems like JS is getting some of its core problems solved and is getting usable. I wonder if it might have short term productivity loss as the churn ramps up to new levels with a million different choices of language/platform. Either way, it will be an interesting time... and a time to keep up or risk being left behind.
- angersock 11y ago
  Eh, the problem with JS is that it's starting to suffer the language feature bloat that, say, C++ has. I think the party will end in like 5 years, mostly after introduction of shared memory objects and traits. Meanwhile, this is going to allow people to port really dumb things into the browser and expose all sorts of new crazy. Still neat, I agree, if you prefer native code. That said, it's not an unalloyed good.
- JoshTriplett 11y ago
  > However, it finally seems like JS is getting some of its core problems solved and is getting usable. I wonder if it might have short term productivity loss as the churn ramps up to new levels with a million different choices of language/platform. This announcement means JavaScript can no longer rely on "you must target JavaScript to work on the web" as a motivating factor. The set of people who like JavaScript as a language in its own right can keep using it, and will have the advantage of new JavaScript engines and extensions implemented on top of WebAssembly. However, the set of people who would rather write in another language will no longer be constrained by waiting for JavaScript to catch up. Personally, I think this will be a good thing for both JavaScript and other languages.
  - smrtinsert 11y ago
    I'm 100% ready to jump ship there. I would rather work at a shop that does any other language besides Javascript for web guis even with more than a decade of js dev under my belt. The problem is they are impossible to find.
dankohn1 11y ago
This is enormous news. I could see a scenario where, in ~5 years, WebAssembly could provide an alternative to having to develop apps with HTML for the web, Swift for iOS, and Java for Android. Instead, you could build browser-based apps that actually delivered native performance, even for CPU- and GPU-intensive tasks. Of course, there would still be UI differences required between the 3 platforms, but you would no longer need 3 separate development teams.
- BrendanEich 11y ago
  Why not Swift for the Web? Better yet, Rust.
  - 13years 11y ago
    Rust would really be exciting to see it supported.
- billiam 11y ago
  That is exactly what some of us are excited about and what others (like the creators of Swift?) are terrified of.
  - JeremyBanks 11y ago
    The creator of Swift was a creator of LLVM. Once the language has been open-sourced, it won't be long before people are compiling it to WebAssembly and trying to use it to replace JavaScript. He might not be too upset.
- muglug 11y ago
  This was also what Java applets were meant to deliver – I remember running some pretty great Java Applet-based games back in the day. But Java ran as an embed, not a browser-level feature, and was much slower to load than Flash (which came to offer much of the same functionality in an easy-to-use IDE).
  - the8472 11y ago
AndrewDucker 11y ago
Interestingly, about five years ago, he said he couldn't see this ever happening: https://news.ycombinator.com/item?id=1905291 https://news.ycombinator.com/item?id=1905291
- BrendanEich 11y ago
  In that comment, I wrote "A binary encoding of JS ASTs, maybe (arithmetic coders can achieve good compression; see Ben Livshits' JSZap from MSR, and earlier work by Michael Franz and Christian Stork at UCI). But this too is just a gleam in my eye, not on TC39's radar." And WebAssembly is indeed a compressed AST encoding, not a stack bytecode. Shhh, don't tell anyone. You can still call it bytecode if you like.
  - AndrewDucker 11y ago
    Your secret is safe with me! (And thanks for the info!)
  - stcredzero 11y ago
    With an AST representation, one can do interesting things. Everyone could have their own custom code formatting rules, and it wouldn't have to affect anyone else. Comments would have to be included in the AST for this to work sanely. This might even go as far as languages, though for this to work well, the code would have to cover an intersection of the functionality in all the languages "rendered" to. (Haven't watched the presentation yet. I'm in public without headphones.)
  - icefox 11y ago
    Anyone published a webassembly hello world somewhere?
Murkin 11y ago
Can someone explain why not just go the JVM or .NET CLR path ? Both well tested, well executed, great tooling, supported on many platforms, compilation targets of many existing languages. Serious question.. is it licensing ?
- mkozlows 11y ago
  You can't easily integrate the CLR/JVM into browsers. As the FAQ notes, this can be built within existing JS engines relatively straightforwardly, rather than requiring a new giant runtime engine (as NaCl would have, and the JVM/CLR would).
- javajosh 11y ago
  >Can someone explain why not just go the JVM or .NET CLR path ? I was about to ask the same question. Because once you require browsers to support something other than JavaScript, that's equivalent to requiring browsers to come with a Java plugin or CLR plugin or Flash or Silverlight installed. It seems to me the only difference is that the web.asm plugin's inventor is the influential inventor of JavaScript, and can harness the support required to add a plugin to all browsers going forward. (unless of course i don't understand this proposal, which is entirely possible).
- pcwalton 11y ago
  There was an attempt to do this with the JVM a long time ago, called LiveConnect. It failed.
- kevingadd 11y ago
  The fundamental models of the JVM and CLR don't meet the needs of web browsers. You could probably really aggressively alter them to do so, but in the end you've still got to run in a browser and integrate with existing javascript code.
- azakai 11y ago
  1. Both the JVM and CLR have different focuses in terms of startup speed, which matters more on the web than anywhere else (this is one reason Java failed on the web). JavaScript and WebAssembly are designed to start up quickly. 2. If you have both the CLR and a JS engine in the same browser, you have problems with cross-VM GC cycles and the overhead that causes. That is one reason why WebKit opposed adding Dart bindings, for example. WebAssembly is designed to integrate with existing JS VMs. 3. Both Java and the CLR are open source, but both are patented. Both have licenses for those patents, but this has been the cause of much debate, as there are corner cases in those licenses (e.g. if you do not fully implement all of the VM per the license, you may not fall under its protection). This could be resolved - all existing patents could be offered up to the public domain - but I don't see Microsoft or Oracle (and there may be others with patents) doing so.
aikah 11y ago
So it's basically bytecode for the web without compiling to javascript right ? Any language can now target that specific bytecode without the need for javascript transpilation. For instance Flash can target this format in place of the Flash player, making swf files future proof since backed by standard web techs. So it's basically the return of Flash,Java applets and co on the web. And web developers won't have to use Javascript anymore. The only constraint is obviously the fact that the bytecode has only access to web apis and cant talk directly to the OS like with classic browser plugin architectures.
andybak 11y ago
Isomorphic Python here I come...
garfij 11y ago
I'm curious what the debugging story for this is going to be? Source maps?
- corysama 11y ago
  Yep https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#source-maps-integration https://github.com/WebAssembly/design/blob/master/FutureFeat...
McElroy 11y ago
This page makes Firefox on Android crash.
- crazysim 11y ago
  It crashes in iOS Safari on an iPad Air 2 for me.
McElroy 11y ago
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... makes me happy as that was the first concern I had when reading these news :)
AriaMinaei 11y ago
Does everyone think this is good news? I'm all for making the web faster/safer/better and all that. But I am worried about losing the web's "open by design" nature. Much of what I've learned and am learning comes from me going to websites, opening the inspector and stepping through their code. It's educational. You learn things you may never read about in tutorials or books. And it's great because the author may have never intended for their code to be studied. But whether they like it or not, other people will learn from their code, and perhaps come up with [occasionally] better versions of it on their own. This has helped the web development to evolve faster, and it's obvious how democratizing this "open-by-design" property is, and I think we should be concerned that it's being traded away for another (also essential) property. Human beings cannot read asm.js code. And a bytecode format will be more or less the same. So, no matter how much faster and more flexible this format/standard is, it will still turn web apps into black boxes that no one can look into and learn from.
- aquilaFiera 11y ago
  WebAssembly isn't going to kill that notion; uglify already did. Nearly all codebases on big sites get run through a build process these days. The open web continues to live on through the open and free software movements.
  - AriaMinaei 11y ago
    I agree that the web is far from the full ideal of "open-by-design", but it's still the most significant platform providing it to some extent. The problem of uglify can be mitigated if someone invented a binary format for JS that was interchangeable with the current text format. The format would reduce the code's size, while keeping it readable (you'd just have to run it through a binary-to-text decompressor). I should also say that you can read uglified/obfuscated code. It just takes more patience. Example: if PS was written in JS and then obfuscated, how hard do you think it would be to find out how their color transformation algorithms are implemented? You can't say the same thing for asm.js code though.
    - derefr 11y ago
comex 11y ago
Has any consideration been given to using a subset or derivation of LLVM bitcode a la PNaCl? I know there are significant potential downsides (e.g. according to [1], it's not actually very space efficient despite/because of being bit-oriented and having fancy abbreviation features), but it already has a canonical text encoding, it has been 'battle-tested' and has semantics by definition well suited for compilers, and using it as a base would generally avoid reinventing the wheel. [1] https://aaltodoc.aalto.fi/handle/123456789/13468 https://aaltodoc.aalto.fi/handle/123456789/13468
- azakai 11y ago
  Of course, several of the people working on WebAssembly are actually from the PNaCl team. And others, like the Emscripten people, have lots of LLVM experience as well. WebAssembly is being designed while taking into account previous approaches in this field, including of course using LLVM bitcode for it. LLVM bitcode is simply not a good fit for this: * It is not portable. * It is not designed to be compact. * It is not designed to be quick to decode and start up * It has undefined behavior * It is not sandboxed. * It is a moving target (see recent big changes to LLVM IR on geps and loads/stores) Each of those can be tackled with a lot of effort. But overall, better results are possible using other approaches.
jacquesm 11y ago
So, is this the long way around to get us Java Applets all over again?
amelius 11y ago
Without support for proper threads, web assembly programming feels the same as programming a Z80 or 6502 back in the 80s. And no, webworkers don't cut it, because they don't support structural sharing of immutable data structures in an efficient and flexible way.
- BrendanEich 11y ago
  Tedious to read out-of-date objections. Please do a bit of research and find out the latest. JS is getting shared memory thread support: https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p... This means the MVP wasm likely includes threads (same timeframe, later this year), and post-MVP wasm can go for full-strength pthreads.
haberman 11y ago
Very very happy to see this. Politically it appears to be a fantastic collaboration. Technically it looks like they have really thought through this hard -- if you look through the post-MVP plans (https://github.com/WebAssembly/design/blob/master/FutureFeatures.md https://github.com/WebAssembly/design/blob/master/FutureFeat...) there are a lot of exciting ideas there. But it's not just pie-in-the-sky speculation, the amount of detail makes it clear that they have some really top compiler people who are really rigorously exploring the boundaries of what can be accomplished inside the web platform (SIMD, threading, GC integration, tail calls, multiprocess support, etc).
protomyth 11y ago
Didn't WMLScript (a subset of Javascript used for WML) have a required byte code representation?
vmorgulis 11y ago
This is awesome. We will probably need a package manager after that (like apt or npm). A use case could be with ImageMagick, OpenCV, OpenSceneGraph or qemu inside the browser. All of them are huge and useful projects with many common dependencies.
spullara 11y ago
It is really too bad that at some point in the last 18 years of Java VMs being in browsers that they didn't formalize the connection between the DOM and Java so that you could write code that interacted directly with the DOM and vice/versa in a mature VM that was already included. Would have been way better than applets, way faster than Javascript and relatively easy to implement. The browsers actually have (had?) APIs for this but they were never really stabilized.
- hello_there 11y ago
  I find it interesting that Java didn't become the standard for this as it seems like it has everything and is both fast and mature. What might be the reason?
  - BrendanEich 11y ago
    See https://news.ycombinator.com/item?id=1894374 https://news.ycombinator.com/item?id=1894374 from @nix.
  - reagency 11y ago
    Back when Java Applets were a thing, Sun wasn't friendly with browser makers. JavaScript was a gimmicky alternative that was created by a browser manufacturer. It had the foothold, and it grew. Nos Oracle isn't interested in Web.
  - titzer 11y ago
    There are several important lessons to learn from the Java bytecode format and members of the WebAssembly (including myself) do have experience here. In particular, JVM class files would be a poor fit for WebAssembly because: 1. They impose Java's class and primitive type model. 2. They allow irreducible control flow. 3. They aren't very compact. Lots of redundancy in constant pools across classes and still a lot of possibility for compression. 4. Verification of JVM class files is an expensive operation requiring control and dataflow analysis (see stackmaps added in the Java 7 class file format for rationale). 5. No notion of low-level memory access. WebAssembly specifically addresses this, exposing the notion of a native heap that can be bit-banged directly by applications.
lorddoig 11y ago
Praise the lord, that was sooner than I expected. Next up: the DOM. Then there will be peace on Earth. Does anyone know when all this started? I ask because only 83 days ago Brendan was on here telling us pretty emphatically that this was a bad idea and would never happen.
- BrendanEich 11y ago
  Please cite my post from 83 days ago. I think you're misreading it (perhaps "bytecode" is overloaded). I have good reason to, since I was in on wasm from the start, which was longer ago than 83 days.
  - lorddoig 11y ago
    I didn't intend to ruffle anyone's feathers with that comment. Yes I suppose I am misreading it, but I don't think I can be blamed for walking away from that exchange thinking transpilation to JS was the last word on the subject. Anyway great work man. It's a happy day.
    - BrendanEich 11y ago
      Thanks. Here's Tim Sweeney on diff between "bytecode" and wasm: https://twitter.com/TimSweeneyEpic/status/611237145857138688 https://twitter.com/TimSweeneyEpic/status/611237145857138688
      - elwell 11y ago
        Hi Brendan, just hopping on the end of this thread to tell you that I think it was just disgusting the way that you were boycotted for your donation. It seemed really hypocritical for them to mistreat you for your opinions.
        bryanlarsen 11y ago
        Maybe we won in the end. If Brendan was spending all his time doing CEO type stuff, he'd be spending less time giving us awesomeness like this.
leoc 11y ago
w00t w00t. This is pretty great overall.
joosters 11y ago
To an end user, how is this a different experience from flash? You browse to a website and must execute binary blobs in order to view the site. Even worse, it's like Flash but where the flash 'plugin' has been written from scratch by each web browser, giving us endless possibilities of incompatibilities which are a nightmare to fix.
daurnimator 11y ago
This still doesn't fix the biggest issue with running non-javascript code in the browser: browsers still offer no way to know when a value is collected. e.g. if I allocate a callback function, and hand it to setTimeout, I have no way to know when to collect it. Sure, you can encode rules about some of the common functions; but as soon as you get to e.g. attaching an 'onreadystatechange' to an XHR: you can't follow all the different code paths. Every time a proposal comes up to fix this: - GC callbacks - Weak valued maps - Proxy with collection trap The proposal gets squashed. Unless this is attended to Javascript remains the required language on the web.
- BrendanEich 11y ago
  Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to notify in next event loop turn. Note turn-based notification. No way will exact GC schedule be leaked via callbacks from the GC. Ditto anything like Java's post-mortem finalization. But your "e.g." is unclear, though. Why do you need to manually deallocate a callback function passed to setTimeout?
  - daurnimator 11y ago
    > Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to notify in next event loop turn. Got a link to the memo? I haven't heard about this one. > Why do you need to manually deallocate a callback function passed to setTimeout? One of my use cases is running lua in the browser. see lua.vm.js: https://kripken.github.io/lua.vm.js/repl.html https://kripken.github.io/lua.vm.js/repl.html When you pass a lua function to a javascript function, I create a 'proxy' object that holds a reference to the function in the lua VM. Only if javascript tells me it's "done" with it can I drop the ref inside the lua VM.
    - chadaustin 11y ago
      FWIW, this is exactly the same problem we had with making it possible for Embind to allow passing C++ functions into setTimeout. We'd need to synthesize a JavaScript function that holds a wrapper object for the C++ function, and that wrapper object would need to be deallocated when the timer is done. For general callbacks, this is a hard problem, and finalizers would provide a clean way to solve it.
paulojreis 11y ago
> "MS seems to get the modern Web". This made me laugh, sadly. They get the modern Web because they aren't winning at native app development.
- tonyedgecombe 11y ago
  I think it's more that native app development isn't winning (except in a few niches).
UserRights 11y ago
Is there already a plugin out there that blocks this crap?
jklontz 11y ago
WebAssembly Backend RFC on the LLVM mailing list: http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend-td82554.html http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend-td...

897 points by fabrice_d 11y ago

Finally. IMO this is what the web has been calling for since AJAX went mainstream. They are doing great work. The client's operating system matters little now, but it will not matter at all soon.

bhouston 11y ago

I guess this is in the spirit of NaCL and its bytecode, and the Java VM/Java bytecode, and the .NET runtime/.NET IR. It makes a lot of sense and I get it then sort of gets competitive with those efforts as well.

kevingadd 11y ago
It does compete with those efforts in a sense, but ideally it is going to learn from those efforts and provide a powerful cross-browser equivalent to them instead of just trying to replace them.
TD-Linux 11y ago
>NaCL and its bytecode Specifically PNaCL's bytecode. NaCL is a separate product that is native code.

thomasfoster96 11y ago

This is pretty awesome, and is a pretty good use of all the effort that's been going into asm.js One question though - I found a proposal somewhere on a Mozilla run wiki about a web API for registering script transpiling/interpreter engines. I've lost the web address, but if anyone know any more about this is love to see it rekindled.

thomasfoster96 11y ago
Found the page: https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Rosetta https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Ro...
arcatek 11y ago
I think you're talking about module loaders[1]. I remember seeing on es-discuss that they have been postponed to ES7. [1] https://github.com/lukehoban/es6features#module-loaders https://github.com/lukehoban/es6features#module-loaders
- thomasfoster96 11y ago
  Functionally that's it (didn't realise it'd been rolled into es6 modules though). Looks like what I was referring to was a third party library: https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Rosetta https://developer.mozilla.org/en-US/Add-ons/Code_snippets/Ro...

rockdoe 11y ago

So this is like PNaCl but targeting the web API and by making it collaborative, hopefully a real standard allowing independent reimplementation? Ironic that Eich is the one to pull the trigger on JS.

pcwalton 11y ago
It's not "pulling the trigger" on JS—per the FAQ, it's fully polyfillable and typically implemented inside the JS engine, as essentially a separate interface to all the implementation work that's already there. This is a crucial difference from everything that's been tried before (including PNaCl). JS isn't going anywhere and continues to be improved.
- JoshTriplett 11y ago
  > JS isn't going anywhere Sure it is. Step 1: get all browsers to support WebAssembly, so that sites can drop the polyfills. Step 2 (specifically noted in the article): make WebAssembly more full-featured than JavaScript, ignoring the ability to polyfill it because browsers have native support. Step 3 (potentially doable before 2): implement JavaScript in WebAssembly, so it becomes just one of many possible languages, and its implementation is no longer beholden to browser quirks. That'll make JavaScript a better language for its proponents (latest ECMAScript features everywhere), and entirely avoidable for people who prefer other languages.
  - trbent 11y ago
    There are a lot of web coders who seem to believe in the most outlandish ideas and who act as if coding ever more rickety stacks is progress.
  - BrendanEich 11y ago
    Dream on. JS is "obligate, not facultative", as biologists say, for browser implementors. It lives in source form on the web and must load super-fast. We can wager about when it might actually die (I said it might given something like wasm, at Strange Loop 2012), but that's beyond the horizon by years if not decades. Gary Bernhardt knows!

jewel 11y ago

I hope that someone ports mruby to this. I've come to terms with javascript's syntax (via coffeescript), but I'd still rather not deal with javascript's semantics.

azakai 11y ago
There is already an mruby port to the web using emscripten. When emscripten targets wasm, that port will get that for free.

pcwalton 11y ago

Having been on one side of the perpetual (and tiresome) PNaCl-versus-asm.js debate, I'm thrilled to see a resolution. I really think this is a strategy that combines the best of both worlds. The crucial aspect is that this is polyfillable via JIT compilation to asm.js, so it's still just JavaScript, but it has plenty of room for extensibility to support threads, SIMD, and so forth.

JoshTriplett 11y ago
> The crucial aspect is that this is polyfillable via JIT compilation to asm.js So is PNaCl, with pepper.js. The difference there is that PNaCl also provided a more full-featured API, which nonetheless was harder for other browsers to support. Personally, I would have been happy to see NaCl-minus-Pepper standardized, since the sandbox would have been much easier to support than the APIs; browsers could then choose what superset of APIs to expose to that sandbox.
- kevingadd 11y ago
  pepper.js is ahead-of-time offline compilation, which means it can't adapt to individual target runtimes.
  - JoshTriplett 11y ago
    So is WebAssembly: you'd compile your code to a .wasm file "offline". In both cases, you compile your code to a bytecode format, which the browser then compiles (directly or via JS polyfill) to native code.
    - kevingadd 11y ago
      A key part of WebAssembly's strategy is a polyfill that runs on the client and generates appropriate JS (asm.js or otherwise).
      - JoshTriplett 11y ago

kodablah 11y ago

I think the biggest win is https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-integration https://github.com/WebAssembly/design/blob/master/FutureFeat.... Now instead of asm.js being only for emscripten-compiled code (or other non-GC code) WebAssembly can be used for higher level, GC'd languages. And even better, https://github.com/WebAssembly/design/blob/master/NonWeb.md https://github.com/WebAssembly/design/blob/master/NonWeb.md, means we may get a new, generic, standalone VM out of this which is always good (I hope I'm not reading in to the details too much). As someone who likes to write compilers/transpilers, I look forward to targetting this.

JoshTriplett 11y ago
I'm really hoping that WebAssembly doesn't bake-in higher-level features like garbage collection. That would preclude replacing GC with something better, such as Rust-style memory management. Hopefully this will take more inspiration from actual assembly language and virtual machines, rather than from bytecode languages.
- kevingadd 11y ago
  it's a virtual machine, but it needs to interop with the rest of the web. at some point this probably means support for garbage collected heaps, but it doesn't mean it's a pervasively-GCd VM like Java. Think more like how WebKit, Gecko and Blink have lots of GC infrastructure in their native, un-GCd code.
  - JoshTriplett 11y ago
    Right, it has to interoperate with DOM objects; however, those can be treated as "foreign" object handles owned by the browser and just referenced by WebAssembly. Those objects can't be directly in the WebAssembly "address space"; that would be unsafe. So since they have to be managed separately anyway, they can use whatever memory model the browser uses.
- jlongster 11y ago
  I highly doubt it would ever bake in GC semantics. High-perf stuff like games are the biggest push for this kind of thing, where nobody wants a GC. One of the biggest advantages to asm.js right now is predictable performance because of no GC. Most likely an API will be provided for interacting with a garbage collector, but it's completely optional.

JoshTriplett 11y ago

I'm interested to see what the API side of WebAssembly looks like in browsers; hopefully this will make it easier to expose more full-featured sandboxed APIs to languages targeting the web, without having to tailor those APIs to JavaScript. For instance, API calls that actually accept integers and data structures rather than floating-point and objects. For that matter, though in the short-term this will be polyfilled via JavaScript in browsers, it'll be fun to see the first JavaScript-to-WebAssembly compiler that allows you to use the latest ECMAScript features in every browser.

azakai 11y ago
The API story for wasm on the web is the set of existing web APIs. That provides the same security model and capabilities as the web has right now. Currently wasm can't access web APIs except by calling out to JS, which would then call the API, but in the future, direct calling paths are intended.
- JoshTriplett 11y ago
  My hope is that WebAssembly will start motivating a set of lower-level APIs, with higher-level APIs being provided on top of those by WebAssembly "libraries". JavaScript tends to motivate much higher-level APIs, and you can't turn high-level APIs into low-level APIs, only the other way around.
  - tedmielczarek 11y ago
    This seems orthogonal to WebAssembly. This is already a goal for its own sake--see the Extensible Web Manifesto.

M8 11y ago

If I could just use my favourite language and not feel like a second class citizen, then I am not sure there would be anything else to complain about as a developer, really. A mark-up bytecode so that we could forget about the nightmare of HTML and CSS as well?

angersock 11y ago
Oh, goody, so now we all get to worry about a more fragmented development ecosystem.
thomasfoster96 11y ago
Just start loading a single script tag and ignore HTML and CSS completely. Will severely impact usability and SEO though.
- wereHamster 11y ago
  The Google Bot executes JavaScript and indexes the result, I don't see why it couldn't run wasm.
  - wodenokoto 11y ago
    While it may very well run the WASM it'll need to interpret the output. How do you rank a running game of candycrush vs. the candycrush website in google results?
  - thomasfoster96 11y ago
    Well, unless you produce HTML dynamically Googlbot supporting JavaScript doesn't really matter.
  - kuschku 11y ago
    The Google Bot. Again, this makes it harder for competitors to ever enter the market.
- sixdimensional 11y ago
  Actually, I think this might be a great opportunity to separate applications/datum that don't need to be indexed by search engines from those that do. Of course, we have to be careful that we don't get walled off content in applications which can and already does easily happen, but I don't think that is truly in the spirit of the sharing web that we have all come to know and love. There are at least two distinct types of content - structured/unstructured content that should be exposed and can be indexed via some known mechanism by external visitors, and application content that perhaps need not be indexed. This might be a time to evolve/establish what those mechanisms are for the betterment of both application development and content development/sharing.

toomim 11y ago

This new file extension gives me an org.wasm

sixdimensional 11y ago

I think this quote speaks volumes - "WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks." Sometimes I think maybe, just maybe the W3C and other web standards groups finally have some wind behind their sails. It may have taken a while, but with all these individuals and organizations cooperating in an open space, we may finally advance yet again into another new era of innovation for the web. I am really excited about this, much like others in these comments. We have been beating around the bush to have a true assembly/development layer in the browser for a long time: Java applets, Flash, Silverlight, you name it - but no true standard that was open like Javascript is open. This component has the possibility of being the neutral ground that everyone can build on top of. To the creators (Brendan Eich et. al) & supporters, well done and best of luck in this endeavor. It's already started on the right foot (asm.js was what lead the way to this I think) - let's hope they can keep it cooperative and open as much as possible for the benefit of everyone!

walterbell 11y ago
> WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla, and a few other folks Is Apple participating?
- andhow 11y ago
  https://bugs.webkit.org/show_bug.cgi?id=146064 https://bugs.webkit.org/show_bug.cgi?id=146064
- bryanlarsen 11y ago
  Yes: "I’m happy to report that we at Mozilla have started working with Chromium, Edge and WebKit engineers " https://blog.mozilla.org/luke/2015/06/17/webassembly/ https://blog.mozilla.org/luke/2015/06/17/webassembly/
  - michaelmior 11y ago
    This doesn't seem to necessarily imply that Apple is directly involved. But it's good to know that Safari should be included in this effort.

mhd 11y ago

Combined with something like e.g. Flipboard's react-canvas, this means we could bypass and re-implement most of the browser stack...

deleted 11y ago

[deleted]

ncw33 11y ago

Nice, but I'm still waiting for 64-bit integer arithmetic! For our use case, what I like about this is that we can continue to use emscripten and the technology will come to us, rather than requiring app developers to invest in yet another technology (our switchover from NaCl to emscripten was very time consuming!)

BrendanEich 11y ago
64-bit ints coming along with SIMD in ES7^H2016.

amyjess 11y ago

This is probably the best thing that can happen to web development. For quite a while, I've been thinking about how instead of hacks like asm.js, we should be pushing an actual "Web IR" which would actually be designed from the ground up as an IR language. Something similar to PNaCl (a subset of LLVM IR), except divorced from the Chrome sandbox, really.

mnemonik 11y ago
asm.js made wasm possible by creating a solid compatibility story and evolutionary path.
MichaelGG 11y ago
I think that's what lots of people have thought since the 90s with Java applets. Despite ES6 and "it's not that bad", there's a lot of people that would really like to not have to deal with JS. Edit: Really, it's annoying this didn't happen sooner. If Microsoft would have thought of this early on and pushed it, they could have gained a lead in compilers and developer tools, for instance.

wora 11y ago

Oberon language had a similar system called Juice back in 1997. It does exactly the same thing, e.g. using binary format to store a compressed abstract syntax tree as intermediate format which can be compiled efficiently and quickly. I think it even has a browser plugin much as Java applet. Life has interesting cycles. I don't have the best link to the Juice. [1] https://github.com/berkus/Juice/blob/master/intro.htm https://github.com/berkus/Juice/blob/master/intro.htm [2] ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf

gecko 11y ago
Honestly, everything we're doing recently feels like rediscovering Oberon. Oberon had name-based public/private methods, like Go. It had ahead-of-time compilation of bytecode, as you pointed out. It had CSP-style concurrency, again like Go. The web for the last two years feels like we're rediscovering Smalltalk and Oberon and acting like we've just invented everything anew.
- wora 11y ago
  I originally designed the name-based public/private methods for Go. I didn't know Oberon had the same design.
- BrendanEich 11y ago
  We didn't acknowledge a debt to Oberon (did Java? It owes one too, Bill Joy evaluated Oberon closely). My pal Michael Franz at UCI studied under Wirth. Michael and a PhD student, Chris Storck, did an AST encoder years back that influenced me and that I referenced re: wasm. Oberon's great. JS was in the right place and right time. What can I say? I've been taking all the best ideas from the best projects and trying to get them incorporated, ever since 1995.
  - gecko 11y ago
    Sorry, just to be clear, I don't see anything wrong at all with raiding the best ideas from older languages. It's actually awesome: it means those ideas get used. I'm genuinely just amused at the cycle.

moron4hire 11y ago

So for now, the idea is to write C++, compile it to ASM.js, translate it into WebAssembly, GZIP it, transmit it, unGZIP it, then run a polyfill to translate the WebAssembly into ASM.js? This sounds absurd. I can't even get through getting Clang, LLVM, and Emscripten built from source as it is, it's such a house-of-cards with configuration and dependency settings. Have any of you tried building Chromium from scratch? I have, on three separate occasions, as I'd like to try to contribute to WebVR. End result: fewer gigs of free space on my hard drive and no Chromium from source. Part of that is my impatience: I'm used to C# and Java, where dependencies are always dynamically linked, the namespacing keeps everything from colliding, and the semantics are very easy to follow. But even Node's braindead NPM dependency manager would be better than the hoops they make you jump through to build open-source C++ projects. I mean, I just don't get how someone could have at any point said "yes, this is a good path, we should continue with this" for all these custom build systems in the wild on these projects. I could be way off. I'm only just reading the FAQ now and I'm not entirely sure I understand what has actually been made versus what has been planned. There seems to be a lot of talk about supporting other languages than C++, but that's what they said about ASM.js, and where did that go? Is anyone using ASM.js in production who is not Archive.org and their arcade emulator? I don't know... I really, really want to like the web browser as a platform. It has its flaws, but it's the least painful solution of all of the completely-cross-platform options. But it's hard. Getting harder. Hard enough I'm starting to wonder if it'd be smarter to develop better deployment strategies for an existing, better programming language than to try to develop better programming languages for the browser's existing, better deployment strategy. This telephone game being played by translator tools and configuration management tools and polyfills and frameworks and... the list goes on! This thing we consider "modern" web development is getting way out of hand. JS's strength used to be that all you needed was a text editor. Everyone--both users and developers--can already use it and run it. If it's just one tool, I'll get over it. But stringing these rickety, half-implemented tools together into a chain of codependent systems is unacceptable. It just feels like they're foisting their inability to finish and properly deploy their work on us. Vagrant recipes are nice, but they should be a convenience, not a necessity. Sorry. Good for them. Just finish something already.

BrendanEich 11y ago

addisonj 11y ago

Prepare for the onslaught of new (and old) languages targeting the web. While this is welcome news, I am also torn. The possibilities are pretty amazing. Think seamless isomorphic apps in any language that can target WebAssembly and has a virtual dom implementation. However, it finally seems like JS is getting some of its core problems solved and is getting usable. I wonder if it might have short term productivity loss as the churn ramps up to new levels with a million different choices of language/platform. Either way, it will be an interesting time... and a time to keep up or risk being left behind.

angersock 11y ago
Eh, the problem with JS is that it's starting to suffer the language feature bloat that, say, C++ has. I think the party will end in like 5 years, mostly after introduction of shared memory objects and traits. Meanwhile, this is going to allow people to port really dumb things into the browser and expose all sorts of new crazy. Still neat, I agree, if you prefer native code. That said, it's not an unalloyed good.
JoshTriplett 11y ago
> However, it finally seems like JS is getting some of its core problems solved and is getting usable. I wonder if it might have short term productivity loss as the churn ramps up to new levels with a million different choices of language/platform. This announcement means JavaScript can no longer rely on "you must target JavaScript to work on the web" as a motivating factor. The set of people who like JavaScript as a language in its own right can keep using it, and will have the advantage of new JavaScript engines and extensions implemented on top of WebAssembly. However, the set of people who would rather write in another language will no longer be constrained by waiting for JavaScript to catch up. Personally, I think this will be a good thing for both JavaScript and other languages.
- smrtinsert 11y ago
  I'm 100% ready to jump ship there. I would rather work at a shop that does any other language besides Javascript for web guis even with more than a decade of js dev under my belt. The problem is they are impossible to find.

dankohn1 11y ago

This is enormous news. I could see a scenario where, in ~5 years, WebAssembly could provide an alternative to having to develop apps with HTML for the web, Swift for iOS, and Java for Android. Instead, you could build browser-based apps that actually delivered native performance, even for CPU- and GPU-intensive tasks. Of course, there would still be UI differences required between the 3 platforms, but you would no longer need 3 separate development teams.

BrendanEich 11y ago
Why not Swift for the Web? Better yet, Rust.
- 13years 11y ago
  Rust would really be exciting to see it supported.
billiam 11y ago
That is exactly what some of us are excited about and what others (like the creators of Swift?) are terrified of.
- JeremyBanks 11y ago
  The creator of Swift was a creator of LLVM. Once the language has been open-sourced, it won't be long before people are compiling it to WebAssembly and trying to use it to replace JavaScript. He might not be too upset.
muglug 11y ago
This was also what Java applets were meant to deliver – I remember running some pretty great Java Applet-based games back in the day. But Java ran as an embed, not a browser-level feature, and was much slower to load than Flash (which came to offer much of the same functionality in an easy-to-use IDE).
- the8472 11y ago

AndrewDucker 11y ago

Interestingly, about five years ago, he said he couldn't see this ever happening: https://news.ycombinator.com/item?id=1905291 https://news.ycombinator.com/item?id=1905291

BrendanEich 11y ago
In that comment, I wrote "A binary encoding of JS ASTs, maybe (arithmetic coders can achieve good compression; see Ben Livshits' JSZap from MSR, and earlier work by Michael Franz and Christian Stork at UCI). But this too is just a gleam in my eye, not on TC39's radar." And WebAssembly is indeed a compressed AST encoding, not a stack bytecode. Shhh, don't tell anyone. You can still call it bytecode if you like.
- AndrewDucker 11y ago
  Your secret is safe with me! (And thanks for the info!)
- stcredzero 11y ago
  With an AST representation, one can do interesting things. Everyone could have their own custom code formatting rules, and it wouldn't have to affect anyone else. Comments would have to be included in the AST for this to work sanely. This might even go as far as languages, though for this to work well, the code would have to cover an intersection of the functionality in all the languages "rendered" to. (Haven't watched the presentation yet. I'm in public without headphones.)
- icefox 11y ago
  Anyone published a webassembly hello world somewhere?

Murkin 11y ago

Can someone explain why not just go the JVM or .NET CLR path ? Both well tested, well executed, great tooling, supported on many platforms, compilation targets of many existing languages. Serious question.. is it licensing ?

mkozlows 11y ago
You can't easily integrate the CLR/JVM into browsers. As the FAQ notes, this can be built within existing JS engines relatively straightforwardly, rather than requiring a new giant runtime engine (as NaCl would have, and the JVM/CLR would).
javajosh 11y ago
>Can someone explain why not just go the JVM or .NET CLR path ? I was about to ask the same question. Because once you require browsers to support something other than JavaScript, that's equivalent to requiring browsers to come with a Java plugin or CLR plugin or Flash or Silverlight installed. It seems to me the only difference is that the web.asm plugin's inventor is the influential inventor of JavaScript, and can harness the support required to add a plugin to all browsers going forward. (unless of course i don't understand this proposal, which is entirely possible).
pcwalton 11y ago
There was an attempt to do this with the JVM a long time ago, called LiveConnect. It failed.
kevingadd 11y ago
The fundamental models of the JVM and CLR don't meet the needs of web browsers. You could probably really aggressively alter them to do so, but in the end you've still got to run in a browser and integrate with existing javascript code.
azakai 11y ago
1. Both the JVM and CLR have different focuses in terms of startup speed, which matters more on the web than anywhere else (this is one reason Java failed on the web). JavaScript and WebAssembly are designed to start up quickly. 2. If you have both the CLR and a JS engine in the same browser, you have problems with cross-VM GC cycles and the overhead that causes. That is one reason why WebKit opposed adding Dart bindings, for example. WebAssembly is designed to integrate with existing JS VMs. 3. Both Java and the CLR are open source, but both are patented. Both have licenses for those patents, but this has been the cause of much debate, as there are corner cases in those licenses (e.g. if you do not fully implement all of the VM per the license, you may not fall under its protection). This could be resolved - all existing patents could be offered up to the public domain - but I don't see Microsoft or Oracle (and there may be others with patents) doing so.

aikah 11y ago

So it's basically bytecode for the web without compiling to javascript right ? Any language can now target that specific bytecode without the need for javascript transpilation. For instance Flash can target this format in place of the Flash player, making swf files future proof since backed by standard web techs. So it's basically the return of Flash,Java applets and co on the web. And web developers won't have to use Javascript anymore. The only constraint is obviously the fact that the bytecode has only access to web apis and cant talk directly to the OS like with classic browser plugin architectures.

andybak 11y ago

Isomorphic Python here I come...

garfij 11y ago

I'm curious what the debugging story for this is going to be? Source maps?

corysama 11y ago
Yep https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#source-maps-integration https://github.com/WebAssembly/design/blob/master/FutureFeat...

McElroy 11y ago

This page makes Firefox on Android crash.

crazysim 11y ago
It crashes in iOS Safari on an iPad Air 2 for me.

McElroy 11y ago

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... makes me happy as that was the first concern I had when reading these news :)

AriaMinaei 11y ago

Does everyone think this is good news? I'm all for making the web faster/safer/better and all that. But I am worried about losing the web's "open by design" nature. Much of what I've learned and am learning comes from me going to websites, opening the inspector and stepping through their code. It's educational. You learn things you may never read about in tutorials or books. And it's great because the author may have never intended for their code to be studied. But whether they like it or not, other people will learn from their code, and perhaps come up with [occasionally] better versions of it on their own. This has helped the web development to evolve faster, and it's obvious how democratizing this "open-by-design" property is, and I think we should be concerned that it's being traded away for another (also essential) property. Human beings cannot read asm.js code. And a bytecode format will be more or less the same. So, no matter how much faster and more flexible this format/standard is, it will still turn web apps into black boxes that no one can look into and learn from.

aquilaFiera 11y ago
WebAssembly isn't going to kill that notion; uglify already did. Nearly all codebases on big sites get run through a build process these days. The open web continues to live on through the open and free software movements.
- AriaMinaei 11y ago
  I agree that the web is far from the full ideal of "open-by-design", but it's still the most significant platform providing it to some extent. The problem of uglify can be mitigated if someone invented a binary format for JS that was interchangeable with the current text format. The format would reduce the code's size, while keeping it readable (you'd just have to run it through a binary-to-text decompressor). I should also say that you can read uglified/obfuscated code. It just takes more patience. Example: if PS was written in JS and then obfuscated, how hard do you think it would be to find out how their color transformation algorithms are implemented? You can't say the same thing for asm.js code though.
  - derefr 11y ago

comex 11y ago

Has any consideration been given to using a subset or derivation of LLVM bitcode a la PNaCl? I know there are significant potential downsides (e.g. according to [1], it's not actually very space efficient despite/because of being bit-oriented and having fancy abbreviation features), but it already has a canonical text encoding, it has been 'battle-tested' and has semantics by definition well suited for compilers, and using it as a base would generally avoid reinventing the wheel. [1] https://aaltodoc.aalto.fi/handle/123456789/13468 https://aaltodoc.aalto.fi/handle/123456789/13468

azakai 11y ago
Of course, several of the people working on WebAssembly are actually from the PNaCl team. And others, like the Emscripten people, have lots of LLVM experience as well. WebAssembly is being designed while taking into account previous approaches in this field, including of course using LLVM bitcode for it. LLVM bitcode is simply not a good fit for this: * It is not portable. * It is not designed to be compact. * It is not designed to be quick to decode and start up * It has undefined behavior * It is not sandboxed. * It is a moving target (see recent big changes to LLVM IR on geps and loads/stores) Each of those can be tackled with a lot of effort. But overall, better results are possible using other approaches.

jacquesm 11y ago

So, is this the long way around to get us Java Applets all over again?

amelius 11y ago

Without support for proper threads, web assembly programming feels the same as programming a Z80 or 6502 back in the 80s. And no, webworkers don't cut it, because they don't support structural sharing of immutable data structures in an efficient and flexible way.

BrendanEich 11y ago
Tedious to read out-of-date objections. Please do a bit of research and find out the latest. JS is getting shared memory thread support: https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p... This means the MVP wasm likely includes threads (same timeframe, later this year), and post-MVP wasm can go for full-strength pthreads.

haberman 11y ago

Very very happy to see this. Politically it appears to be a fantastic collaboration. Technically it looks like they have really thought through this hard -- if you look through the post-MVP plans (https://github.com/WebAssembly/design/blob/master/FutureFeatures.md https://github.com/WebAssembly/design/blob/master/FutureFeat...) there are a lot of exciting ideas there. But it's not just pie-in-the-sky speculation, the amount of detail makes it clear that they have some really top compiler people who are really rigorously exploring the boundaries of what can be accomplished inside the web platform (SIMD, threading, GC integration, tail calls, multiprocess support, etc).

protomyth 11y ago

Didn't WMLScript (a subset of Javascript used for WML) have a required byte code representation?

vmorgulis 11y ago

This is awesome. We will probably need a package manager after that (like apt or npm). A use case could be with ImageMagick, OpenCV, OpenSceneGraph or qemu inside the browser. All of them are huge and useful projects with many common dependencies.

spullara 11y ago

It is really too bad that at some point in the last 18 years of Java VMs being in browsers that they didn't formalize the connection between the DOM and Java so that you could write code that interacted directly with the DOM and vice/versa in a mature VM that was already included. Would have been way better than applets, way faster than Javascript and relatively easy to implement. The browsers actually have (had?) APIs for this but they were never really stabilized.

hello_there 11y ago
I find it interesting that Java didn't become the standard for this as it seems like it has everything and is both fast and mature. What might be the reason?
- BrendanEich 11y ago
  See https://news.ycombinator.com/item?id=1894374 https://news.ycombinator.com/item?id=1894374 from @nix.
- reagency 11y ago
  Back when Java Applets were a thing, Sun wasn't friendly with browser makers. JavaScript was a gimmicky alternative that was created by a browser manufacturer. It had the foothold, and it grew. Nos Oracle isn't interested in Web.
- titzer 11y ago
  There are several important lessons to learn from the Java bytecode format and members of the WebAssembly (including myself) do have experience here. In particular, JVM class files would be a poor fit for WebAssembly because: 1. They impose Java's class and primitive type model. 2. They allow irreducible control flow. 3. They aren't very compact. Lots of redundancy in constant pools across classes and still a lot of possibility for compression. 4. Verification of JVM class files is an expensive operation requiring control and dataflow analysis (see stackmaps added in the Java 7 class file format for rationale). 5. No notion of low-level memory access. WebAssembly specifically addresses this, exposing the notion of a native heap that can be bit-banged directly by applications.

lorddoig 11y ago

Praise the lord, that was sooner than I expected. Next up: the DOM. Then there will be peace on Earth. Does anyone know when all this started? I ask because only 83 days ago Brendan was on here telling us pretty emphatically that this was a bad idea and would never happen.

BrendanEich 11y ago
Please cite my post from 83 days ago. I think you're misreading it (perhaps "bytecode" is overloaded). I have good reason to, since I was in on wasm from the start, which was longer ago than 83 days.
- lorddoig 11y ago
  I didn't intend to ruffle anyone's feathers with that comment. Yes I suppose I am misreading it, but I don't think I can be blamed for walking away from that exchange thinking transpilation to JS was the last word on the subject. Anyway great work man. It's a happy day.
  - BrendanEich 11y ago
    Thanks. Here's Tim Sweeney on diff between "bytecode" and wasm: https://twitter.com/TimSweeneyEpic/status/611237145857138688 https://twitter.com/TimSweeneyEpic/status/611237145857138688
    - elwell 11y ago
      Hi Brendan, just hopping on the end of this thread to tell you that I think it was just disgusting the way that you were boycotted for your donation. It seemed really hypocritical for them to mistreat you for your opinions.
      - bryanlarsen 11y ago
        Maybe we won in the end. If Brendan was spending all his time doing CEO type stuff, he'd be spending less time giving us awesomeness like this.

leoc 11y ago

w00t w00t. This is pretty great overall.

joosters 11y ago

To an end user, how is this a different experience from flash? You browse to a website and must execute binary blobs in order to view the site. Even worse, it's like Flash but where the flash 'plugin' has been written from scratch by each web browser, giving us endless possibilities of incompatibilities which are a nightmare to fix.

daurnimator 11y ago

This still doesn't fix the biggest issue with running non-javascript code in the browser: browsers still offer no way to know when a value is collected. e.g. if I allocate a callback function, and hand it to setTimeout, I have no way to know when to collect it. Sure, you can encode rules about some of the common functions; but as soon as you get to e.g. attaching an 'onreadystatechange' to an XHR: you can't follow all the different code paths. Every time a proposal comes up to fix this: - GC callbacks - Weak valued maps - Proxy with collection trap The proposal gets squashed. Unless this is attended to Javascript remains the required language on the web.

BrendanEich 11y ago
Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to notify in next event loop turn. Note turn-based notification. No way will exact GC schedule be leaked via callbacks from the GC. Ditto anything like Java's post-mortem finalization. But your "e.g." is unclear, though. Why do you need to manually deallocate a callback function passed to setTimeout?
- daurnimator 11y ago
  > Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to notify in next event loop turn. Got a link to the memo? I haven't heard about this one. > Why do you need to manually deallocate a callback function passed to setTimeout? One of my use cases is running lua in the browser. see lua.vm.js: https://kripken.github.io/lua.vm.js/repl.html https://kripken.github.io/lua.vm.js/repl.html When you pass a lua function to a javascript function, I create a 'proxy' object that holds a reference to the function in the lua VM. Only if javascript tells me it's "done" with it can I drop the ref inside the lua VM.
  - chadaustin 11y ago
    FWIW, this is exactly the same problem we had with making it possible for Embind to allow passing C++ functions into setTimeout. We'd need to synthesize a JavaScript function that holds a wrapper object for the C++ function, and that wrapper object would need to be deallocated when the timer is done. For general callbacks, this is a hard problem, and finalizers would provide a clean way to solve it.

paulojreis 11y ago

> "MS seems to get the modern Web". This made me laugh, sadly. They get the modern Web because they aren't winning at native app development.

tonyedgecombe 11y ago
I think it's more that native app development isn't winning (except in a few niches).

UserRights 11y ago

Is there already a plugin out there that blocks this crap?

jklontz 11y ago

WebAssembly Backend RFC on the LLVM mailing list: http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend-td82554.html http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend-td...