25 ms·

WebAssembly Browser Preview

759 points by zmodem 10y ago

mevile 10y ago
I thought web assembly compiled to JavaScript, but it doesn't look like that's so. It looks like a binary format. I think that's great if so. Finally we can expand beyond JavaScript on front-end development.
- RussianCow 10y ago
  I think you're thinking of asm.js, which is a subset of JavaScript that can compile to native code directly. WebAssembly is more or less a binary representation of asm.js. Edit: Looks like WebAssembly is more low level than asm.js, and is actually closer to real assembly, whereas asm.js is more akin to C.
  - crooked-v 10y ago
    asm.js is a strict subset of JS, designed to be valid JS for preexisting browser engines while at the same time containing what's effectively a lot of primitive types hinting for an optimized engine. For a simple example... i = i|0; This is valid JS, but a JS engine designed to use asm.js optimizations can look at the bitwise OR with 0 before the script even runs and realize that i must be an integer in that block of code, so it can use more-efficient integer operations instead of float ones.
  - TazeTSchnitzel 10y ago
    WebAssembly is also akin to C, but it has a more efficient encoding and is not constrained by the set of operations that can be expressed in JavaScript.
- Ralfp 10y ago
  > Finally we can expand beyond JavaScript on front-end development. Yup! Thats the plan for web assembly! Write in what you want, compile to browser-supported format, deploy.
  - bobajeff 10y ago
    That is not the plan. WebAssembly is not some holy grail universal bitecode intended for every language. It is intended for C and C++ developers to be able run their code in a performant way on the web.
    - k__ 10y ago
      So it's not suitable for Python, Java, or C#?
      - tyoverby 10y ago
        Not unless you want to compile the JVM to webassembly and load a it on every pageview.
        binji 10y ago
        TeaVM[1] has an experimental WebAssembly backend that does something like this. Here's the recent Reddit thread[2]. [1] http://teavm.org/ http://teavm.org/ [2] https://www.reddit.com/r/programming/comments/5899ln/teavm_java_bytecode_to_js_adds_experimental/ https://www.reddit.com/r/programming/comments/5899ln/teavm_j...
        int_19h 10y ago
        You just need an AOT compiler that targets wasm directly. AOT compilers already exist for Java and C# for various target architectures; this is just another one.
      - kibwen 10y ago
        Eventually it should be, but trying to design a way to integrate multiple runtimes into a single webpage is going to take some work (e.g. imagine a page that imports code originally written in Python and Javascript and Ruby and Go, all with their own garbage collectors (and Go's custom concurrency model!)). The reason that C and C++ and Rust will work from the start is that they don't require invasive runtimes and so allow the browser vendors to punt on this problem until later.
- maga 10y ago
  Yes, you're right. This can allow to avoid JS in browser altogether one day. As a hardcore JavaScript developer I welcome this tech for a couple reasons. For one thing, it's undeniably a significant step forward for Web Platform as a whole. For another, now people can struggle with the peculiarities of the said Web Platform with their own languages. The legitimate grievances associated with JS over the years were due to the browser APIs and first of all DOM, which wasn't designed for JS to begin with and later just accumulated problems for the sake of backwards compatibility.
  - RussianCow 10y ago
    I don't think that will be feasible in the near future, because in order to run another language in the browser (say, Python) through wasm, you will need to bundle the entire runtime with your app, which is an unacceptable amount of overhead for most apps.
    - comex 10y ago
      I feel like this shouldn't be the end of the world. If everyone uses the same CDN for a given language's runtime (with subresource-integrity to ensure security), even a 1MB download should be... tolerable. Not great, but tolerable. Load time is also an issue, but WebAssembly is designed to greatly improve initial load time compared to asm.js.
      - hackcasual 10y ago
        I'm currently working on a large-ish code based designed primarily to run via Emscripten. Current optimized .js size is 3MB. While the WASM size is noticeably smaller <2MB, startup time is actually worse due to browsers compiling everything ahead of time.
        maga 10y ago
        > startup time is actually worse due to browsers compiling everything ahead of time. On an upside, with WASM browsers can potentially save a snapshot of the compiled code to speed up re-runs. I recall the idea was promoted back when Dart was expecting to get its own VM, and one of the things that it would be capable of was this snapshot using.
- angry-hacker 10y ago
  I wonder if ad networks try to fight back against adblockers using web assembly? In theory, it should be easier because you can avoid dom, but who knows what the future will bring.
votr 10y ago
Is there support for only C/C++ at this time?
- lambda 10y ago
  There is pretty bleeding-edge support for compiling to both asm.js and WebAssembly in Rust that recently landed: https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627 https://users.rust-lang.org/t/compiling-to-the-web-with-rust... So, at the very least there's support for C, C++, and Rust at the moment, though of course since the standards aren't yet finalized and the toolchains are evolving how well it works at any given moment may vary. I'm sure there's work going on for other languages to compile down to WASM, just not sure of the status of any other languages at the moment.
- seeekr 10y ago
  Rust can compile to wasm (and asm.js) as well via emscripten. More info here: https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627 https://users.rust-lang.org/t/compiling-to-the-web-with-rust...
- bobajeff 10y ago
  Yes. WebAssembly like asm.js is intended for porting C/C++ apps to the web. That said compiled languages should work if compilers add support for generating WebAssembly.
  - vmarsy 10y ago
    Yes, for instance Swift should be able to compile to web assembly? If Swift can be compiled with the clang/llvm toolchain, it should be able to target web assembly.
wvenable 10y ago
Is there any sort of open source non-browser interpreter for Webassembly?
- dubcanada 10y ago
  I don't know how useful that would be, it's still javascript (just a lower level version of it) after all. It's coupled pretty tightly with the browser.
  - Touche 10y ago
    I think you're confusing asm.js with wasm. wasm is not JavaScript.
  - aspirin 10y ago
    WASM isn't related to JavaScript in any way. Maybe you were thinking of asm.js? You cannot access the browser APIs from WASM so there is no tight coupling with the browser environment. I think non-browser use could make definately sense.
    - 0xdeadbeefbabe 10y ago
      > You cannot access the browser APIs from WASM Do you have a reference? I'm confused about why you wouldn't want to access browser APIs.
      - smitherfield 10y ago
        Right now it's more like Flash or Java applets, running in a sandbox within a sandbox.
        TazeTSchnitzel 10y ago
        Huh? WebAssembly, like asm.js before it, can access Web APIs (albeit via JS).
crudbug 10y ago
Is there a plan to support WASM in NodeJS anytime soon ? I see multiple optimization points on the server side as well.
- andreypopp 10y ago
  FWIW you can already use AOT compiled code in Node.js (native modules). Will WASM provide more benefits over that?
  - dragonwriter 10y ago
    Portability for the AOT compiled modules?
  - crudbug 10y ago
    I haven't seen any official solution for AOT from NodeJS foundation. Having "Official" WASM support drives/drags the community in a standard direction.
- nkassis 10y ago
  I might be missing what you are trying to do but can't you get that optimization today with using FFI to use native modules in your server side code?
  - s3th 10y ago
    The main benefit would be shipping a single WebAssembly module to target client and server (e.g. the same benefit of sharing JS between the browser and Node).
  - imtringued 10y ago
    You can't run it on an arbitrary OS or ISA without explicitly creating a build for that specific ISA or OS.
- singularity2001 10y ago
  You can now simply do node --expose-wasm > buffer=fs.readFileSync('test.wasm') > WebAssembly.compile(buffer)
deleted 10y ago
[deleted]
andrewmcwatters 10y ago
Here's a question: Who is going to use this besides the community of developers currently using emscripten, asm.js, and related technologies? Read: game developers. (Also game developers widely don't use these web technologies.) What I'm afraid of is developers who think they're clever working with WebAssembly to feel like "real developers" shitting up the ecosystem more than it's already polluted. Or some undergrads/Java developers from Google creating another Dartgular but this time claiming that using their new EdgeScript (a real compilable language that utilizes WebAssembly!) is better than just using straight up JavaScript bindings to the existing Web API. Another frankenframework that everyone has to put up with, and will eventually drop support for.
- this-dang-guy 10y ago
  This times a million. Addressed perfectly: https://xkcd.com/927/ https://xkcd.com/927/
- pier25 10y ago
  Games, yes, but this would probably also open the door to high performance web apps.
  - andrewmcwatters 10y ago
    The web will always chase after native unless you truly remove the web portions. WebGL might be the best example of getting close, but for the meat and potatoes of UI, there's very little comparison when looking at the DOM.
- bjt 10y ago
  Games are the first type of application to use this, but won't be the last. If you can run AAA games in a browser, you could run Photoshop, Maya, programming IDEs, and other professional tools. It's not just another framework.
  - andrewmcwatters 10y ago
    Those developers don't want to use web tech, it's too slow.
no1youknowz 10y ago
Is there support for GoLang to WebAssembly? Or will it be more of a GopherJS to WebAssembly? Thanks
- kibwen 10y ago
  The initial MVP of WASM won't have privileged support for any custom runtime services, so in order to run Go code in the browser (or any other GC'd language) you'd have to compile the entire runtime with it and ship it all over the wire to the client. Eventually they do hope to lift this restriction.
  - hackcasual 10y ago
    The other issue is that a lot of GC implementations do stuff that's incompatible with asm.js/WASM like inspecting function stacks.
    - couchand 10y ago
      Not entirely incompatible... an implementation could manage the stack explicitly.
      - hackcasual 10y ago
        Not sure what you mean? Libraries like libgc can't be directly ported over to Emscripten since they depend on platform specific behavior to inspect the execution stack and registers. In asm.js/WASM the execution stack is not inspectable from code.
        couchand 10y ago
        Rather than using the execution stack provided by the environment (by using the built-in calling conventions directly), you could manage your stack on the heap using the linear memory facilities. Function calls are a bit more expensive, since now you need a macro to convert calling conventions. But it's definitely not impossible, and it's not even really all that hard (just tedious).
diamondo25 10y ago
I haven't really looked into the implementation, but won't this be yet another possible way for getting out of the V8 sandbox and be able to execute code and thus be able to exploit? I recall exploits using typed arrays for code execution before, because they can contain raw assembly in a very low-level style (e.g a plain char array in C++)...
- littlegreenb18 10y ago
  This is not machine assembly. Its bytecode, everything still lives in the browser sandbox.
  - deleted 10y ago
    [deleted]
  - chillydawg 10y ago
    Where the sandbox now has a much larger attack surface as it has to implement a whole new virtual machine to run the webasm.
    - gsnedders 10y ago
      Nobody's writing a whole new VM to run it; everyone is just treating it as another input format to their JS VM.
      - icefox 10y ago
        https://github.com/AndrewScheidecker/WAVM https://github.com/AndrewScheidecker/WAVM
        gsnedders 10y ago
        Given the context, what browser is that going into? How is that relevant to browser sandboxing?
sunfish 10y ago
The big news here is coordinated announcements from multiple browsers: https://blogs.windows.com/msedgedev/2016/10/31/webassembly-browser-preview/ https://blogs.windows.com/msedgedev/2016/10/31/webassembly-b... https://hacks.mozilla.org/2016/10/webassembly-browser-preview https://hacks.mozilla.org/2016/10/webassembly-browser-previe... http://v8project.blogspot.com/2016/10/webassembly-browser-preview.html http://v8project.blogspot.com/2016/10/webassembly-browser-pr... [edited to make links clickable]
- kibwen 10y ago
  I've been incredibly impressed at the level of coordination that we've seen from browser vendors on WASM. I know that they've all been working together behind the scenes for decades now on various initiatives, but I can't remember the last time they've all been so publicly supportive of each other as they are here.
  - wlesieutre 10y ago
    WebKit is notably absent from the announcements. It's marked "In Development" though! https://webkit.org/status/#specification-webassembly https://webkit.org/status/#specification-webassembly
    - kibwen 10y ago
      I agree that Webkit is conspicuously absent here, but at least the announcement does mention Apple: "designed by collaborators from Google, Mozilla, Microsoft, Apple, and the W3C WebAssembly Community Group".
      - Ajedi32 10y ago
        The announcement also says: > compatible and stable implementations of WebAssembly behind a flag on trunk in V8 and SpiderMonkey, in development builds of Chakra, and in progress in JavaScriptCore [Emphasis Mine]
    - threeseed 10y ago
LeanderK 10y ago
i feel like one important piece thats missing is a standardised debugging-API. The introduction of WebAssembly will probably lead to a larger percentage of people compiling a (completely different) language to something running in the browser will rise. We need solid tooling for that.
- kibwen 10y ago
  IIRC Firefox already implements the Chrome Debugging Protocol (https://developer.chrome.com/devtools/docs/debugger-protocol https://developer.chrome.com/devtools/docs/debugger-protocol), which e.g. would mean that it should be possible to use Firefox's debug tools to debug web pages in Chrome (and vice-versa). Would be nice to have some clarification on this though. EDIT: Some more clarification, apparently this is enabled by an official add-on (called "Valence") which is shipped by default on Firefox Developer Edition: https://developer.mozilla.org/en-US/docs/Tools/Valence https://developer.mozilla.org/en-US/docs/Tools/Valence
  - LeanderK 10y ago
    i am not following this very closely and was not aware of this (Developed something in Chrome/Safari a few months ago and this bothered me. I needed a custom Webstorm-Extension). I think the push for Wasm would be perfect to sort this thing out and provide a real, standardised API.
  - auchenberg 10y ago
    Firefox doesn't implement the Chrome Debugging Protocol, but has it's own (FDP). Valence is an protocol adapter that adapts CDP to FDP, so Firefox DevTools (using FDP) can be used with iOS (which uses WDP)
- stcredzero 10y ago
  If there is some kind of advanced debugging platform, then this would also make the browser a premier platform as a development environment.
- s3th 10y ago
  We're very interested in exploring this space. It's possible that this capability is exposed through an extension of sourcemaps [0]. Definitely curious to hear more ideas and feedback in this space. [0]: http://webassembly.org/docs/future-features/#source-maps-integration http://webassembly.org/docs/future-features/#source-maps-int...
reitzensteinm 10y ago
Anyone know what the best way to compile and run the text format in the browser is? I'm working on a compiler for Clojure, which also runs in cljs, and would love to attempt to make a back end for it that runs in the browser.
- azakai 10y ago
  If you want to compile the code as-is, then wabt is the most straightforward tool for that (specifically wast2wasm). If you want to also optimize the code, then binaryen can do both (wasm-opt to optimize, wasm-as to convert to binary). Since this is for a compiler backend, then the optimizations are probably relevant for you.
  - reitzensteinm 10y ago
    Sorry, I wasn't clear, I mean run the entire thing in the browser, to make it interactive. Since Chrome apparently supports the text format as a way to view the binary, I was hoping that it would support a two way process. However, from searching around, it looks like I'll have to emit bytecode directly, at least for the near future. Which isn't the end of the world I guess!
    - azakai 10y ago
      Oh I see, sorry for misunderstanding. Yeah, I think it would have been nice to have text format input support in browsers, but the decision was against that. But you do have other options than emitting binary wasm yourself. You can use a compiled version of wabt or binaryen, here's an example of binaryen.js, https://github.com/WebAssembly/binaryen/blob/master/test/binaryen.js/test.js https://github.com/WebAssembly/binaryen/blob/master/test/bin... edit: actually it looks like the test doesn't cover WasmBinaryWriter, which is what would be needed for this, we should improve that
      - binji 10y ago
        Here's the emscripten-compiled wast2wasm (from wabt): https://cdn.rawgit.com/WebAssembly/wabt/2baa1ecb0b36bea6268c52ea49246aafbed05f02/demo/index.html https://cdn.rawgit.com/WebAssembly/wabt/2baa1ecb0b36bea6268c... It uses the code from here: https://github.com/WebAssembly/wabt/tree/master/demo https://github.com/WebAssembly/wabt/tree/master/demo
deleted 10y ago
[deleted]
BatFastard 10y ago
Does anyone know what approach they have taken to access the GPU? I saw some discussion last year, but nothing clear.
- deleted 10y ago
  [deleted]
- irq-1 10y ago
  Looks like the plan is to expand the JS access to WebGL. http://webassembly.org/docs/gc/#webidl-integration http://webassembly.org/docs/gc/#webidl-integration
  - BatFastard 10y ago
    So this is still in the planning stage. Sounds like it is a major part of what they want to deliver, hope it doesn't take TOO long.
mring33621 10y ago
Everybody hated Java applets. Terrible for security! Worst thing ever! Glad they're gone! Hmmmmmm...
- pcwalton 10y ago
  From a security perspective, how is this any different from what you can already do with asm.js? (Remember, SpiderMonkey has a separate JIT mode for it.)
- wmil 10y ago
  Java applets needed to interact with the OS in various ways and required browsers to have sub views controlled by plugins. They were a lot more complex and risk prone. Especially since Sun kept adding features. WASM is much simpler. It's just a standard bytecode format that the JS engine can handle. It's much easier to secure.
  - mring33621 10y ago
    We will see.
  - hackcasual 10y ago
    WASM feels like an evolution built on top of a lot of what's worked with Javascript.
- tomatsu 10y ago
  This isn't a plugin. It also doesn't have the same privileges as the browser itself.
kibwen 10y ago
Let's not let this announcement overshadow what's really important: bikeshedding over the official WebAssembly logo https://github.com/WebAssembly/design/issues/112 https://github.com/WebAssembly/design/issues/112 :)
- moron4hire 10y ago
  LOL, for how smart we like to think we are, we are incredibly stupid people. Who doesn't know about bikeshedding by now? Yet we still do it. Logos should never be created by the community. The community should always appoint a logo dictator and either accept their selection or overthrow them and appoint a new dictator.
  - pc2g4d 10y ago
    And maybe pool some money and hire a designer?
    - rch 10y ago
      We'll save the $$$ for emoji design.
  - ufmace 10y ago
    That's the thing about bikeshedding - it's easy to learn what it is. It's hard to actually stop contributing to it yourself, and often even harder to lead a team out of doing it.
    - jasonm23 10y ago
      Come my people! Let me lead you out of the darkness, away from your bike shedding ways! But first, I'd like to know what you all think about my choice of shoes. Are they the right shade of brown? We can have a round table meeting to discuss it next Friday.
    - deleted 10y ago
      [deleted]
  - 10y ago
msl09 10y ago
>From that point forward, the binary format will be reset to version 1 and WebAssembly will be versionless Why?
- CyberDildonics 10y ago
  The idea is that webasm won't have versions, it will have features that you query, which is the way javascript and in fact actual assembly language works today.
jim-greer 10y ago
I really wish Adobe would write a Flash runtime in WebAssembly. There are tens of thousands of great Flash games that are unplayable in modern browsers... Sure, you could rewrite them in js, but no one is going to.
- moron4hire 10y ago
  What happened to Mozilla Shumway? Looks like there haven't been any commits in over half a year.
  - steveklabnik 10y ago
    Its wikipedia page links to http://www.ghacks.net/2016/02/23/flash-replacement-shumway-is-as-good-as-dead/ http://www.ghacks.net/2016/02/23/flash-replacement-shumway-i...
- qwertyuiop924 10y ago
  Why would it have to be Adobe? Plenty of people could do that kind of work.
  - jim-greer 10y ago
    That's true. Would be nice if Adobe at least threw some resources at it though. It's a huge undertaking. There are just a ton of library calls to support. Here's the list of AS3.0 classes: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/class-summary.html http://help.adobe.com/en_US/FlashPlatform/reference/actionsc... And a whole lot of games are still in AS2 - game developers never really embraced AS3. It really isn't going to happen, I'm afraid. EDIT - Maybe it's possible to compile the C++ sources for the Flash Player to WebAssembly? Then you wouldn't have to re-implement the libraries. I don't know the state of these compilers, but there was a Mozilla post about it a while back: https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/ https://hacks.mozilla.org/2015/12/compiling-to-webassembly-i.... Adobe hasn't open sourced the Flash Player, so it would have to be them.
    - 10y ago
deleted 10y ago
[deleted]
rayalez 10y ago
What do you guys think is the best-case scenario for this project? Like if everything goes well, how do you imagine it will affect the web in 5-10 years? What are we going to be able to do with it?
- Ajedi32 10y ago
  Best-case scenario: in 5-10 years you can use any language you want for building apps on the front-end, just like you currently can for the back end. Existing, widely-used C libraries can be used in front-end applications if desired, and libraries in varying languages can all seamlessly interact with both each other and the DOM.
  - xigency 10y ago
    Really, that's all possible now using emscripten and it still doesn't sound productive.
    - raquo 10y ago
      Not sure how the integration with JS looks like in Emscripten. Scala.js is fabulous, with typed facades for the DOM, easy interaction with dynamic JS types, etc.
- Yuioup 10y ago
  Finally getting rid of Javascript and its spawn nodejs and npm.
- c-smile 10y ago
  As soon as this will be in place: 1. You will not see obfuscated (a.k.a.) uglified JavaScripts anymore. Everything will be compiled into bytecodes. 2. But don't worry, you will see bunch of webDisAssembly tools. 3. You will not see blog posts "How bad is that JavaScript" anymore. 4. But do expect to see "How bad is WebAssembly" though. 5. "Vanilla JavaScript" camp may have "Vanilla WebAssembly" banners on some tents. 6. You will not see anymore those ugly attempts to write Ray Tracer in JS. 7. Each framework will finally have its own programming language. Most advanced of them will change language on month basis, like Angular35 will use Rust build 3234.23.400. Moving asymptotically close to the Web Holy Grail. 8. Browser API will be decomposed to bare-bone state, 8.1 you will see immediate mode drawing a la WM_PAINT drawing style. Finally. 8.2 you will see CSS extendedable by custom layout managers and properties. 8.3 CSS modular system will reach its eternal ideal. Instead of them writing specs for us each our site will have its own CSS modules. At the end: each team will write their own browser - FF, GC, IE will just provide WebAssembly loader means. Everything else will be just loadable. So at the end you will get good Java Applet idea with User Agent exposing pure AWT alike primitives. With the browser as such a ClassLoader thing.
iamleppert 10y ago
Bye bye, native app developers...
- SadWebDeveloper 10y ago
  Unless you own an iPhone/iPad like half the kids in the world today.
  - equasar 10y ago
    Webkit won't support it?
- equasar 10y ago
  Why is that? Does this will provide full access to the phone hardware?
titzer 10y ago
Hello from the Chrome/V8 side of this announcement! We'd like to say that we're incredibly excited to keep moving WebAssembly forward, and that's in large part due to the amazingly collaborative model that all of the vendors have put together through interpersonal relationships and shared vision. Please scrutinize and comment on the design, bang on the tools, and give us feedback! Maybe try writing a codegen or tinkering with the existing tools. Try porting an app or a game. If all goes well, this is what the vendors have agreed to ship at the beginning of next year, so we want to be absolutely sure that it's something solid that others can build on top of. This is also not the end of the evolution for WebAssembly, since there is a pipeline of features planned that go beyond the MVP (minimal viable product), well into next year and after. The web and the working group is the place to experiment with and perfect those details going forward. It's an exciting time for the future of the web! Thanks, - TL on the V8 side
- bluejekyll 10y ago
  Thanks for all the hard work! This is really excellent. I know this is marked as "future", but is there any progress on exposing the DOM? That's something I'm personally really excited for.
  - titzer 10y ago
    It's something we've discussed on various occasions, usually after in-person meetings. So far it has not been the highest priority additional feature, since one can always FFI to JS in the mean time, so that gives us some breathing room to see how usage patterns develop before committing to a potentially large new API surface. A step along that path is just the ability to refer to JS and other objects directly through opaque typed references, and that is more likely to happen sooner rather than later.
- nickthemagicman 10y ago
  Thanks much for yalls work and vision on this!! Looking forward to the possibilities this opens up!
- siggypop 10y ago
Mack65 10y ago
Looking for ethical hCKING services , visit mackathack.com
dccoolgai 10y ago
And so ended the Age of Javascript. Many will say, "good riddance" but I wonder what we lose by making the Web less shareable and copyable...
- labrador 10y ago
  From what I've read, the architects of WebAssembly are committed to still be able to show source.
  - ilaksh 10y ago
    There will always be the S-expression format at least.
    - SquareWheel 10y ago
      The S-expression syntax will be temporary. https://www.youtube.com/watch?v=RByPdCN1RQ4&feature=youtu.be&t=1714 https://www.youtube.com/watch?v=RByPdCN1RQ4&feature=youtu.be...
      - ilaksh 10y ago
        Replaced with what?
        SquareWheel 10y ago
        Doesn't appear to be standardized yet, but some of the goals are outlined here. https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat...
  - wahern 10y ago
    WebAssembly doesn't permit unstructured branching. That is, the bytecode doesn't support "goto". All conditionals and loops use structured mechanisms. Reconstituting branches and loops is the hardest part of decompiling, which means WebAssembly decompilers will have the hardest part already solved for them. It doesn't matter what binary or text formats the WebAssembly team chooses, they'll all be equally easy to parse, and even generate, in this regard. The downside is that translating goto constructs in languages like C can be tricky and sometimes computationally very expensive. Even supporting multi-level "break" can be tricky. And constructs like "computed goto", which are often used in C, Fortran, etc to improve the readability (easier to read state machines) or performance (faster state machines for bytecode interpreters) cannot be supported by WebAssembly directly, which means instead of always being faster they'll always be slower. But the downside is mostly irrelevant for people concerned by decompiling WebAssembly to readable source code.
tmzt 10y ago
I guess this explains some things I heard last week ;)
partycoder 10y ago
This is great. I cannot wait for projects like Scala.js to compile to WebAssembly, to bring some more language diversity to the browser.
chx 10y ago
We have been watching people redoing computer software perhaps 20 years behind with JS (the original Doom was ported in 2011, if I remember correctly, please bikeshed the exact number of years) Let's hope WebAssembly will seriously cut this figure down.
pettou 10y ago
Please, does anyone know: - Why the chose stack-based VM, rather than register-based one? - I see the docs mention Float128 type, is this a real possibility? What it their opinion on having Float128? - there doesn't seem to be any support for ADC instruction ("add with carry") which would be very useful for implementing multi-precision numeric types. Are the plans to support ADC and the like or not? How to implement, say BigInt, with WebAssembly? - maybe I misunderstood but when adding two integers result in an overflow, does it trigger the "trap"? I mean, lot of time (e.g. modular arithmetic) one does what fast "wrap around" (i.e. modulo 2^INT_SIZE) in integer types. Is this behaviour (of C) going to stay in WebAssembly?
- wahern 10y ago
  Signed integers in C don't wrap around. That's undefined behavior. Unsigned integers behave modulo 2^n, so if you want wrap around in C you should be using unsigned integers. Any C compiler to WebAssembly would have to implement unsigned behavior regardless of the semantics of WebAssembly's native unsigned operations. For information on the semantics of WebAssembly arithmetic, see https://github.com/WebAssembly/design/blob/master/Semantics.md#32-bit-integer-operators https://github.com/WebAssembly/design/blob/master/Semantics.... For other information about WebAssembly start here https://github.com/WebAssembly/design/ https://github.com/WebAssembly/design/
deleted 10y ago
[deleted]
nickthemagicman 10y ago
SO EXCITED!! Cant wait to get a block scoped language in the browser!!
- atrilumen 10y ago
  You mean like JavaScript? http://caniuse.com/#search=const http://caniuse.com/#search=const http://caniuse.com/#search=let http://caniuse.com/#search=let
  - nickthemagicman 10y ago
    No I mean a REAL block scoped language! JS is cool but these are just bolted on features. Why does a function I pass into an Ajax query need a call statement? Why does 'this' have so many interpretations depending on its context? Other languages approach these in simpler ways. Functions inherit the scope in which they are executed and 'this' applies to its parent object. Also, whats up with nested asynchronous statements? I know ES6 and 7 are working on it but new languages would be ideal with new takes on solving some of the tough parts of web development.
st3fan 10y ago
Why speculate about what Apple is doing if you can just go look at the WebKit change history. Search for WebAssembly on https://trac.webkit.org https://trac.webkit.org and you can see that there is a lot of work happening. The most recent commit being "WebAssembly API: implement Instance" - https://trac.webkit.org/changeset/207929 https://trac.webkit.org/changeset/207929 So yeah it looks like it is not finished. But it also looks like they are investing a lot of engineering time in this feature as we speak.
awqrre 10y ago
Being a binary format is the worst part of WebAssembly... for the open web.
- ajnin 10y ago
  Why would that be a problem ? The open web needs standards that are well defined and used by everyone, and WebAssembly seems to bring just that with the simultaneous announcements by several browser vendors. PNG is binary too and it's arguably one of the assets of the open web.
- haberman 10y ago
  There is this weird belief that being a text format automatically means open, reusable, interoperable and being a binary format automatically means closed, proprietary, opaque. As counterexamples, here are several binary formats that are very open: ELF, DWARF, PNG, tar, gzip, Ogg and all its subformats, FLAC, JPEG2000. On the other hand, you have something like OOXML, which while technically open/standardized, is so incredibly complicated that it is extremely difficult to implement well. Just because something is text-based does not make it simple.
  - z3t4 10y ago
    I think Wasm will be more advanced then PNG. And if there are code execution exploits in PNG, I can only imagine how many exploits there will be in Wasm.
    - haberman 10y ago
      And how many have there been in HTML, JavaScript, and CSS? https://en.wikipedia.org/wiki/Pwn2Own https://en.wikipedia.org/wiki/Pwn2Own
  - awqrre 10y ago
    I was saying this because in many binary formats, lots of information is lost in the code to binary conversion (.c to binary, for example) ... and with current connection and processor speeds, I don't think that binary will help that much or be worth the trade-off. But I get your point and I know that html, js, etc can be highly obfuscated but I did extract some features from gmail before and it was not quite as bad as with ASM extracted from a binary...
wentoodeep 10y ago
Finally, time to create a programming language that run on top of wasm.
- nippur72 10y ago
  https://github.com/evanw/thinscript https://github.com/evanw/thinscript
Ericson2314 10y ago
I you think about it, a WASM "process" is a great middle ground between a conventional VM (ugly hardware skeoumorphism) and container (ugly Unix). I hope this becomes the standard interface for server hosting, not just the browser.
TheAceOfHearts 10y ago
Maybe someone that's more familiar with wasm can enlighten me, but isn't this still extremely limited in the capabilities it exposes? With so many limitations in place, what are some example use-cases that this helps with? Am I being too negative and unrealistic? I don't know what kind of expectations I should have. I'm not writing this to bait responses. It seems to be that until you get lower level network capabilities and some form of file system access, you're just too limited.
- dpacmittal 10y ago
  >It seems to be that until you get lower level network capabilities and some form of file system access, you're just too limited. JS doesn't give you those things either but would you call it limited? I think its a very early preview and we can expect a lot of limitations removed as the technology progresses.
  - TheAceOfHearts 10y ago
    I do think JS is very limited for non-networked applications. If most of what you're doing is hitting APIs and displaying that data, it's great. But if you're building an app that doesn't depend on the network, you find yourself way more limited in most cases. The solution for many people is to go for Electron, but that takes you completely out of the web sandbox. I understand that it's incredibly challenging to get multiple vendors to agree on anything, and I'm sure we'll get to a good place eventually, but I guess I'm just feeling a bit frustrated with the state of things. What does this initial release of wasm enable? I've heard that game developers are expected to be the initial target audience. Do we provide adequate APIs for storing game assets? As an example, I think the latest Doom game is 50GB. I guess I'm a bit concerned that all of this incredible work will get done and released, but nobody will be able to make use of it? Is this a legitimate concern or am I being irrational? I guess I'd have a bit more peace of mind if there were some examples of concrete use-cases that are expected to be solved by this work. Maybe these use-case examples already exist and I haven't seen em? I'll admit I haven't looked around much. This is a concern I've had with regular web APIs as well. Sometimes I'll read about a new spec that's being developed, but maybe due to my poor understanding or lack of knowledge, I'll end up confused as to the purpose of those APIs.
grondilu 10y ago
How reasonable is it to hope that WebAssembly becomes a compilation target for GCC?
z3t4 10y ago
My biggest worry is that everyone will turn this off due to security concerns.
mschuetz 10y ago
What about debugging? A useful debugging suite, like the current chrome developer tools for javascript, is a must have in my opinion.
jlebrech 10y ago
will this mean we can use gtk for websites in the future?
- imtringued 10y ago
  You can run Qt in the browser already. http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc... I wouldn't recommend it.
  - jlebrech 10y ago
    yep, i'm looking for a library that's in a state that you WOULD recommend it. :)
hitlin37 10y ago
so it compiles c++ to webassembly syntax using empscripten compiler. what js has to do with webassembly? Is the idea is same with js? i.e. compiler js code to webassembly. noob here on web assembly.
TbobbyZ 10y ago
Based on this tutorial http://webassembly.org/getting-started/developers-guide/ http://webassembly.org/getting-started/developers-guide/ web assembly lets youvwrite web apps in C?

759 points by zmodem 10y ago

I thought web assembly compiled to JavaScript, but it doesn't look like that's so. It looks like a binary format. I think that's great if so. Finally we can expand beyond JavaScript on front-end development.

RussianCow 10y ago
I think you're thinking of asm.js, which is a subset of JavaScript that can compile to native code directly. WebAssembly is more or less a binary representation of asm.js. Edit: Looks like WebAssembly is more low level than asm.js, and is actually closer to real assembly, whereas asm.js is more akin to C.
- crooked-v 10y ago
  asm.js is a strict subset of JS, designed to be valid JS for preexisting browser engines while at the same time containing what's effectively a lot of primitive types hinting for an optimized engine. For a simple example... i = i|0; This is valid JS, but a JS engine designed to use asm.js optimizations can look at the bitwise OR with 0 before the script even runs and realize that i must be an integer in that block of code, so it can use more-efficient integer operations instead of float ones.
- TazeTSchnitzel 10y ago
  WebAssembly is also akin to C, but it has a more efficient encoding and is not constrained by the set of operations that can be expressed in JavaScript.
Ralfp 10y ago
> Finally we can expand beyond JavaScript on front-end development. Yup! Thats the plan for web assembly! Write in what you want, compile to browser-supported format, deploy.
- bobajeff 10y ago
  That is not the plan. WebAssembly is not some holy grail universal bitecode intended for every language. It is intended for C and C++ developers to be able run their code in a performant way on the web.
  - k__ 10y ago
    So it's not suitable for Python, Java, or C#?
    - tyoverby 10y ago
      Not unless you want to compile the JVM to webassembly and load a it on every pageview.
      - binji 10y ago
        TeaVM[1] has an experimental WebAssembly backend that does something like this. Here's the recent Reddit thread[2]. [1] http://teavm.org/ http://teavm.org/ [2] https://www.reddit.com/r/programming/comments/5899ln/teavm_java_bytecode_to_js_adds_experimental/ https://www.reddit.com/r/programming/comments/5899ln/teavm_j...
      - int_19h 10y ago
        You just need an AOT compiler that targets wasm directly. AOT compilers already exist for Java and C# for various target architectures; this is just another one.
    - kibwen 10y ago
      Eventually it should be, but trying to design a way to integrate multiple runtimes into a single webpage is going to take some work (e.g. imagine a page that imports code originally written in Python and Javascript and Ruby and Go, all with their own garbage collectors (and Go's custom concurrency model!)). The reason that C and C++ and Rust will work from the start is that they don't require invasive runtimes and so allow the browser vendors to punt on this problem until later.
maga 10y ago
Yes, you're right. This can allow to avoid JS in browser altogether one day. As a hardcore JavaScript developer I welcome this tech for a couple reasons. For one thing, it's undeniably a significant step forward for Web Platform as a whole. For another, now people can struggle with the peculiarities of the said Web Platform with their own languages. The legitimate grievances associated with JS over the years were due to the browser APIs and first of all DOM, which wasn't designed for JS to begin with and later just accumulated problems for the sake of backwards compatibility.
- RussianCow 10y ago
  I don't think that will be feasible in the near future, because in order to run another language in the browser (say, Python) through wasm, you will need to bundle the entire runtime with your app, which is an unacceptable amount of overhead for most apps.
  - comex 10y ago
    I feel like this shouldn't be the end of the world. If everyone uses the same CDN for a given language's runtime (with subresource-integrity to ensure security), even a 1MB download should be... tolerable. Not great, but tolerable. Load time is also an issue, but WebAssembly is designed to greatly improve initial load time compared to asm.js.
    - hackcasual 10y ago
      I'm currently working on a large-ish code based designed primarily to run via Emscripten. Current optimized .js size is 3MB. While the WASM size is noticeably smaller <2MB, startup time is actually worse due to browsers compiling everything ahead of time.
      - maga 10y ago
        > startup time is actually worse due to browsers compiling everything ahead of time. On an upside, with WASM browsers can potentially save a snapshot of the compiled code to speed up re-runs. I recall the idea was promoted back when Dart was expecting to get its own VM, and one of the things that it would be capable of was this snapshot using.
angry-hacker 10y ago
I wonder if ad networks try to fight back against adblockers using web assembly? In theory, it should be easier because you can avoid dom, but who knows what the future will bring.

votr 10y ago

Is there support for only C/C++ at this time?

lambda 10y ago
There is pretty bleeding-edge support for compiling to both asm.js and WebAssembly in Rust that recently landed: https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627 https://users.rust-lang.org/t/compiling-to-the-web-with-rust... So, at the very least there's support for C, C++, and Rust at the moment, though of course since the standards aren't yet finalized and the toolchains are evolving how well it works at any given moment may vary. I'm sure there's work going on for other languages to compile down to WASM, just not sure of the status of any other languages at the moment.
seeekr 10y ago
Rust can compile to wasm (and asm.js) as well via emscripten. More info here: https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and-emscripten/7627 https://users.rust-lang.org/t/compiling-to-the-web-with-rust...
bobajeff 10y ago
Yes. WebAssembly like asm.js is intended for porting C/C++ apps to the web. That said compiled languages should work if compilers add support for generating WebAssembly.
- vmarsy 10y ago
  Yes, for instance Swift should be able to compile to web assembly? If Swift can be compiled with the clang/llvm toolchain, it should be able to target web assembly.

wvenable 10y ago

Is there any sort of open source non-browser interpreter for Webassembly?

dubcanada 10y ago
I don't know how useful that would be, it's still javascript (just a lower level version of it) after all. It's coupled pretty tightly with the browser.
- Touche 10y ago
  I think you're confusing asm.js with wasm. wasm is not JavaScript.
- aspirin 10y ago
  WASM isn't related to JavaScript in any way. Maybe you were thinking of asm.js? You cannot access the browser APIs from WASM so there is no tight coupling with the browser environment. I think non-browser use could make definately sense.
  - 0xdeadbeefbabe 10y ago
    > You cannot access the browser APIs from WASM Do you have a reference? I'm confused about why you wouldn't want to access browser APIs.
    - smitherfield 10y ago
      Right now it's more like Flash or Java applets, running in a sandbox within a sandbox.
      - TazeTSchnitzel 10y ago
        Huh? WebAssembly, like asm.js before it, can access Web APIs (albeit via JS).

crudbug 10y ago

Is there a plan to support WASM in NodeJS anytime soon ? I see multiple optimization points on the server side as well.

andreypopp 10y ago
FWIW you can already use AOT compiled code in Node.js (native modules). Will WASM provide more benefits over that?
- dragonwriter 10y ago
  Portability for the AOT compiled modules?
- crudbug 10y ago
  I haven't seen any official solution for AOT from NodeJS foundation. Having "Official" WASM support drives/drags the community in a standard direction.
nkassis 10y ago
I might be missing what you are trying to do but can't you get that optimization today with using FFI to use native modules in your server side code?
- s3th 10y ago
  The main benefit would be shipping a single WebAssembly module to target client and server (e.g. the same benefit of sharing JS between the browser and Node).
- imtringued 10y ago
  You can't run it on an arbitrary OS or ISA without explicitly creating a build for that specific ISA or OS.
singularity2001 10y ago
You can now simply do node --expose-wasm > buffer=fs.readFileSync('test.wasm') > WebAssembly.compile(buffer)

deleted 10y ago

[deleted]

andrewmcwatters 10y ago

Here's a question: Who is going to use this besides the community of developers currently using emscripten, asm.js, and related technologies? Read: game developers. (Also game developers widely don't use these web technologies.) What I'm afraid of is developers who think they're clever working with WebAssembly to feel like "real developers" shitting up the ecosystem more than it's already polluted. Or some undergrads/Java developers from Google creating another Dartgular but this time claiming that using their new EdgeScript (a real compilable language that utilizes WebAssembly!) is better than just using straight up JavaScript bindings to the existing Web API. Another frankenframework that everyone has to put up with, and will eventually drop support for.

this-dang-guy 10y ago
This times a million. Addressed perfectly: https://xkcd.com/927/ https://xkcd.com/927/
pier25 10y ago
Games, yes, but this would probably also open the door to high performance web apps.
- andrewmcwatters 10y ago
  The web will always chase after native unless you truly remove the web portions. WebGL might be the best example of getting close, but for the meat and potatoes of UI, there's very little comparison when looking at the DOM.
bjt 10y ago
Games are the first type of application to use this, but won't be the last. If you can run AAA games in a browser, you could run Photoshop, Maya, programming IDEs, and other professional tools. It's not just another framework.
- andrewmcwatters 10y ago
  Those developers don't want to use web tech, it's too slow.

no1youknowz 10y ago

Is there support for GoLang to WebAssembly? Or will it be more of a GopherJS to WebAssembly? Thanks

kibwen 10y ago
The initial MVP of WASM won't have privileged support for any custom runtime services, so in order to run Go code in the browser (or any other GC'd language) you'd have to compile the entire runtime with it and ship it all over the wire to the client. Eventually they do hope to lift this restriction.
- hackcasual 10y ago
  The other issue is that a lot of GC implementations do stuff that's incompatible with asm.js/WASM like inspecting function stacks.
  - couchand 10y ago
    Not entirely incompatible... an implementation could manage the stack explicitly.
    - hackcasual 10y ago
      Not sure what you mean? Libraries like libgc can't be directly ported over to Emscripten since they depend on platform specific behavior to inspect the execution stack and registers. In asm.js/WASM the execution stack is not inspectable from code.
      - couchand 10y ago
        Rather than using the execution stack provided by the environment (by using the built-in calling conventions directly), you could manage your stack on the heap using the linear memory facilities. Function calls are a bit more expensive, since now you need a macro to convert calling conventions. But it's definitely not impossible, and it's not even really all that hard (just tedious).

diamondo25 10y ago

I haven't really looked into the implementation, but won't this be yet another possible way for getting out of the V8 sandbox and be able to execute code and thus be able to exploit? I recall exploits using typed arrays for code execution before, because they can contain raw assembly in a very low-level style (e.g a plain char array in C++)...

littlegreenb18 10y ago
This is not machine assembly. Its bytecode, everything still lives in the browser sandbox.
- deleted 10y ago
  [deleted]
- chillydawg 10y ago
  Where the sandbox now has a much larger attack surface as it has to implement a whole new virtual machine to run the webasm.
  - gsnedders 10y ago
    Nobody's writing a whole new VM to run it; everyone is just treating it as another input format to their JS VM.
    - icefox 10y ago
      https://github.com/AndrewScheidecker/WAVM https://github.com/AndrewScheidecker/WAVM
      - gsnedders 10y ago
        Given the context, what browser is that going into? How is that relevant to browser sandboxing?

sunfish 10y ago

The big news here is coordinated announcements from multiple browsers: https://blogs.windows.com/msedgedev/2016/10/31/webassembly-browser-preview/ https://blogs.windows.com/msedgedev/2016/10/31/webassembly-b... https://hacks.mozilla.org/2016/10/webassembly-browser-preview https://hacks.mozilla.org/2016/10/webassembly-browser-previe... http://v8project.blogspot.com/2016/10/webassembly-browser-preview.html http://v8project.blogspot.com/2016/10/webassembly-browser-pr... [edited to make links clickable]

kibwen 10y ago
I've been incredibly impressed at the level of coordination that we've seen from browser vendors on WASM. I know that they've all been working together behind the scenes for decades now on various initiatives, but I can't remember the last time they've all been so publicly supportive of each other as they are here.
- wlesieutre 10y ago
  WebKit is notably absent from the announcements. It's marked "In Development" though! https://webkit.org/status/#specification-webassembly https://webkit.org/status/#specification-webassembly
  - kibwen 10y ago
    I agree that Webkit is conspicuously absent here, but at least the announcement does mention Apple: "designed by collaborators from Google, Mozilla, Microsoft, Apple, and the W3C WebAssembly Community Group".
    - Ajedi32 10y ago
      The announcement also says: > compatible and stable implementations of WebAssembly behind a flag on trunk in V8 and SpiderMonkey, in development builds of Chakra, and in progress in JavaScriptCore [Emphasis Mine]
  - threeseed 10y ago

LeanderK 10y ago

i feel like one important piece thats missing is a standardised debugging-API. The introduction of WebAssembly will probably lead to a larger percentage of people compiling a (completely different) language to something running in the browser will rise. We need solid tooling for that.

kibwen 10y ago
IIRC Firefox already implements the Chrome Debugging Protocol (https://developer.chrome.com/devtools/docs/debugger-protocol https://developer.chrome.com/devtools/docs/debugger-protocol), which e.g. would mean that it should be possible to use Firefox's debug tools to debug web pages in Chrome (and vice-versa). Would be nice to have some clarification on this though. EDIT: Some more clarification, apparently this is enabled by an official add-on (called "Valence") which is shipped by default on Firefox Developer Edition: https://developer.mozilla.org/en-US/docs/Tools/Valence https://developer.mozilla.org/en-US/docs/Tools/Valence
- LeanderK 10y ago
  i am not following this very closely and was not aware of this (Developed something in Chrome/Safari a few months ago and this bothered me. I needed a custom Webstorm-Extension). I think the push for Wasm would be perfect to sort this thing out and provide a real, standardised API.
- auchenberg 10y ago
  Firefox doesn't implement the Chrome Debugging Protocol, but has it's own (FDP). Valence is an protocol adapter that adapts CDP to FDP, so Firefox DevTools (using FDP) can be used with iOS (which uses WDP)
stcredzero 10y ago
If there is some kind of advanced debugging platform, then this would also make the browser a premier platform as a development environment.
s3th 10y ago
We're very interested in exploring this space. It's possible that this capability is exposed through an extension of sourcemaps [0]. Definitely curious to hear more ideas and feedback in this space. [0]: http://webassembly.org/docs/future-features/#source-maps-integration http://webassembly.org/docs/future-features/#source-maps-int...

reitzensteinm 10y ago

Anyone know what the best way to compile and run the text format in the browser is? I'm working on a compiler for Clojure, which also runs in cljs, and would love to attempt to make a back end for it that runs in the browser.

azakai 10y ago
If you want to compile the code as-is, then wabt is the most straightforward tool for that (specifically wast2wasm). If you want to also optimize the code, then binaryen can do both (wasm-opt to optimize, wasm-as to convert to binary). Since this is for a compiler backend, then the optimizations are probably relevant for you.
- reitzensteinm 10y ago
  Sorry, I wasn't clear, I mean run the entire thing in the browser, to make it interactive. Since Chrome apparently supports the text format as a way to view the binary, I was hoping that it would support a two way process. However, from searching around, it looks like I'll have to emit bytecode directly, at least for the near future. Which isn't the end of the world I guess!
  - azakai 10y ago
    Oh I see, sorry for misunderstanding. Yeah, I think it would have been nice to have text format input support in browsers, but the decision was against that. But you do have other options than emitting binary wasm yourself. You can use a compiled version of wabt or binaryen, here's an example of binaryen.js, https://github.com/WebAssembly/binaryen/blob/master/test/binaryen.js/test.js https://github.com/WebAssembly/binaryen/blob/master/test/bin... edit: actually it looks like the test doesn't cover WasmBinaryWriter, which is what would be needed for this, we should improve that
    - binji 10y ago
      Here's the emscripten-compiled wast2wasm (from wabt): https://cdn.rawgit.com/WebAssembly/wabt/2baa1ecb0b36bea6268c52ea49246aafbed05f02/demo/index.html https://cdn.rawgit.com/WebAssembly/wabt/2baa1ecb0b36bea6268c... It uses the code from here: https://github.com/WebAssembly/wabt/tree/master/demo https://github.com/WebAssembly/wabt/tree/master/demo

deleted 10y ago

[deleted]

BatFastard 10y ago

Does anyone know what approach they have taken to access the GPU? I saw some discussion last year, but nothing clear.

deleted 10y ago
[deleted]
irq-1 10y ago
Looks like the plan is to expand the JS access to WebGL. http://webassembly.org/docs/gc/#webidl-integration http://webassembly.org/docs/gc/#webidl-integration
- BatFastard 10y ago
  So this is still in the planning stage. Sounds like it is a major part of what they want to deliver, hope it doesn't take TOO long.

mring33621 10y ago

Everybody hated Java applets. Terrible for security! Worst thing ever! Glad they're gone! Hmmmmmm...

pcwalton 10y ago
From a security perspective, how is this any different from what you can already do with asm.js? (Remember, SpiderMonkey has a separate JIT mode for it.)
wmil 10y ago
Java applets needed to interact with the OS in various ways and required browsers to have sub views controlled by plugins. They were a lot more complex and risk prone. Especially since Sun kept adding features. WASM is much simpler. It's just a standard bytecode format that the JS engine can handle. It's much easier to secure.
- mring33621 10y ago
  We will see.
- hackcasual 10y ago
  WASM feels like an evolution built on top of a lot of what's worked with Javascript.
tomatsu 10y ago
This isn't a plugin. It also doesn't have the same privileges as the browser itself.

kibwen 10y ago

Let's not let this announcement overshadow what's really important: bikeshedding over the official WebAssembly logo https://github.com/WebAssembly/design/issues/112 https://github.com/WebAssembly/design/issues/112 :)

moron4hire 10y ago
LOL, for how smart we like to think we are, we are incredibly stupid people. Who doesn't know about bikeshedding by now? Yet we still do it. Logos should never be created by the community. The community should always appoint a logo dictator and either accept their selection or overthrow them and appoint a new dictator.
- pc2g4d 10y ago
  And maybe pool some money and hire a designer?
  - rch 10y ago
    We'll save the $$$ for emoji design.
- ufmace 10y ago
  That's the thing about bikeshedding - it's easy to learn what it is. It's hard to actually stop contributing to it yourself, and often even harder to lead a team out of doing it.
  - jasonm23 10y ago
    Come my people! Let me lead you out of the darkness, away from your bike shedding ways! But first, I'd like to know what you all think about my choice of shoes. Are they the right shade of brown? We can have a round table meeting to discuss it next Friday.
  - deleted 10y ago
    [deleted]
- 10y ago

msl09 10y ago

>From that point forward, the binary format will be reset to version 1 and WebAssembly will be versionless Why?

CyberDildonics 10y ago
The idea is that webasm won't have versions, it will have features that you query, which is the way javascript and in fact actual assembly language works today.

jim-greer 10y ago

I really wish Adobe would write a Flash runtime in WebAssembly. There are tens of thousands of great Flash games that are unplayable in modern browsers... Sure, you could rewrite them in js, but no one is going to.

moron4hire 10y ago
What happened to Mozilla Shumway? Looks like there haven't been any commits in over half a year.
- steveklabnik 10y ago
  Its wikipedia page links to http://www.ghacks.net/2016/02/23/flash-replacement-shumway-is-as-good-as-dead/ http://www.ghacks.net/2016/02/23/flash-replacement-shumway-i...
qwertyuiop924 10y ago
Why would it have to be Adobe? Plenty of people could do that kind of work.
- jim-greer 10y ago
  That's true. Would be nice if Adobe at least threw some resources at it though. It's a huge undertaking. There are just a ton of library calls to support. Here's the list of AS3.0 classes: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/class-summary.html http://help.adobe.com/en_US/FlashPlatform/reference/actionsc... And a whole lot of games are still in AS2 - game developers never really embraced AS3. It really isn't going to happen, I'm afraid. EDIT - Maybe it's possible to compile the C++ sources for the Flash Player to WebAssembly? Then you wouldn't have to re-implement the libraries. I don't know the state of these compilers, but there was a Mozilla post about it a while back: https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/ https://hacks.mozilla.org/2015/12/compiling-to-webassembly-i.... Adobe hasn't open sourced the Flash Player, so it would have to be them.
  - 10y ago

deleted 10y ago

[deleted]

rayalez 10y ago

What do you guys think is the best-case scenario for this project? Like if everything goes well, how do you imagine it will affect the web in 5-10 years? What are we going to be able to do with it?

Ajedi32 10y ago
Best-case scenario: in 5-10 years you can use any language you want for building apps on the front-end, just like you currently can for the back end. Existing, widely-used C libraries can be used in front-end applications if desired, and libraries in varying languages can all seamlessly interact with both each other and the DOM.
- xigency 10y ago
  Really, that's all possible now using emscripten and it still doesn't sound productive.
  - raquo 10y ago
    Not sure how the integration with JS looks like in Emscripten. Scala.js is fabulous, with typed facades for the DOM, easy interaction with dynamic JS types, etc.
Yuioup 10y ago
Finally getting rid of Javascript and its spawn nodejs and npm.
c-smile 10y ago
As soon as this will be in place: 1. You will not see obfuscated (a.k.a.) uglified JavaScripts anymore. Everything will be compiled into bytecodes. 2. But don't worry, you will see bunch of webDisAssembly tools. 3. You will not see blog posts "How bad is that JavaScript" anymore. 4. But do expect to see "How bad is WebAssembly" though. 5. "Vanilla JavaScript" camp may have "Vanilla WebAssembly" banners on some tents. 6. You will not see anymore those ugly attempts to write Ray Tracer in JS. 7. Each framework will finally have its own programming language. Most advanced of them will change language on month basis, like Angular35 will use Rust build 3234.23.400. Moving asymptotically close to the Web Holy Grail. 8. Browser API will be decomposed to bare-bone state, 8.1 you will see immediate mode drawing a la WM_PAINT drawing style. Finally. 8.2 you will see CSS extendedable by custom layout managers and properties. 8.3 CSS modular system will reach its eternal ideal. Instead of them writing specs for us each our site will have its own CSS modules. At the end: each team will write their own browser - FF, GC, IE will just provide WebAssembly loader means. Everything else will be just loadable. So at the end you will get good Java Applet idea with User Agent exposing pure AWT alike primitives. With the browser as such a ClassLoader thing.

iamleppert 10y ago

Bye bye, native app developers...

SadWebDeveloper 10y ago
Unless you own an iPhone/iPad like half the kids in the world today.
- equasar 10y ago
  Webkit won't support it?
equasar 10y ago
Why is that? Does this will provide full access to the phone hardware?

titzer 10y ago

Hello from the Chrome/V8 side of this announcement! We'd like to say that we're incredibly excited to keep moving WebAssembly forward, and that's in large part due to the amazingly collaborative model that all of the vendors have put together through interpersonal relationships and shared vision. Please scrutinize and comment on the design, bang on the tools, and give us feedback! Maybe try writing a codegen or tinkering with the existing tools. Try porting an app or a game. If all goes well, this is what the vendors have agreed to ship at the beginning of next year, so we want to be absolutely sure that it's something solid that others can build on top of. This is also not the end of the evolution for WebAssembly, since there is a pipeline of features planned that go beyond the MVP (minimal viable product), well into next year and after. The web and the working group is the place to experiment with and perfect those details going forward. It's an exciting time for the future of the web! Thanks, - TL on the V8 side

bluejekyll 10y ago
Thanks for all the hard work! This is really excellent. I know this is marked as "future", but is there any progress on exposing the DOM? That's something I'm personally really excited for.
- titzer 10y ago
  It's something we've discussed on various occasions, usually after in-person meetings. So far it has not been the highest priority additional feature, since one can always FFI to JS in the mean time, so that gives us some breathing room to see how usage patterns develop before committing to a potentially large new API surface. A step along that path is just the ability to refer to JS and other objects directly through opaque typed references, and that is more likely to happen sooner rather than later.
nickthemagicman 10y ago
Thanks much for yalls work and vision on this!! Looking forward to the possibilities this opens up!
siggypop 10y ago

Mack65 10y ago

Looking for ethical hCKING services , visit mackathack.com

dccoolgai 10y ago

And so ended the Age of Javascript. Many will say, "good riddance" but I wonder what we lose by making the Web less shareable and copyable...

labrador 10y ago
From what I've read, the architects of WebAssembly are committed to still be able to show source.
- ilaksh 10y ago
  There will always be the S-expression format at least.
  - SquareWheel 10y ago
    The S-expression syntax will be temporary. https://www.youtube.com/watch?v=RByPdCN1RQ4&feature=youtu.be&t=1714 https://www.youtube.com/watch?v=RByPdCN1RQ4&feature=youtu.be...
    - ilaksh 10y ago
      Replaced with what?
      - SquareWheel 10y ago
        Doesn't appear to be standardized yet, but some of the goals are outlined here. https://github.com/WebAssembly/design/blob/master/TextFormat.md https://github.com/WebAssembly/design/blob/master/TextFormat...
- wahern 10y ago
  WebAssembly doesn't permit unstructured branching. That is, the bytecode doesn't support "goto". All conditionals and loops use structured mechanisms. Reconstituting branches and loops is the hardest part of decompiling, which means WebAssembly decompilers will have the hardest part already solved for them. It doesn't matter what binary or text formats the WebAssembly team chooses, they'll all be equally easy to parse, and even generate, in this regard. The downside is that translating goto constructs in languages like C can be tricky and sometimes computationally very expensive. Even supporting multi-level "break" can be tricky. And constructs like "computed goto", which are often used in C, Fortran, etc to improve the readability (easier to read state machines) or performance (faster state machines for bytecode interpreters) cannot be supported by WebAssembly directly, which means instead of always being faster they'll always be slower. But the downside is mostly irrelevant for people concerned by decompiling WebAssembly to readable source code.

tmzt 10y ago

I guess this explains some things I heard last week ;)

partycoder 10y ago

This is great. I cannot wait for projects like Scala.js to compile to WebAssembly, to bring some more language diversity to the browser.

chx 10y ago

We have been watching people redoing computer software perhaps 20 years behind with JS (the original Doom was ported in 2011, if I remember correctly, please bikeshed the exact number of years) Let's hope WebAssembly will seriously cut this figure down.

pettou 10y ago

Please, does anyone know: - Why the chose stack-based VM, rather than register-based one? - I see the docs mention Float128 type, is this a real possibility? What it their opinion on having Float128? - there doesn't seem to be any support for ADC instruction ("add with carry") which would be very useful for implementing multi-precision numeric types. Are the plans to support ADC and the like or not? How to implement, say BigInt, with WebAssembly? - maybe I misunderstood but when adding two integers result in an overflow, does it trigger the "trap"? I mean, lot of time (e.g. modular arithmetic) one does what fast "wrap around" (i.e. modulo 2^INT_SIZE) in integer types. Is this behaviour (of C) going to stay in WebAssembly?

wahern 10y ago
Signed integers in C don't wrap around. That's undefined behavior. Unsigned integers behave modulo 2^n, so if you want wrap around in C you should be using unsigned integers. Any C compiler to WebAssembly would have to implement unsigned behavior regardless of the semantics of WebAssembly's native unsigned operations. For information on the semantics of WebAssembly arithmetic, see https://github.com/WebAssembly/design/blob/master/Semantics.md#32-bit-integer-operators https://github.com/WebAssembly/design/blob/master/Semantics.... For other information about WebAssembly start here https://github.com/WebAssembly/design/ https://github.com/WebAssembly/design/

deleted 10y ago

[deleted]

nickthemagicman 10y ago

SO EXCITED!! Cant wait to get a block scoped language in the browser!!

atrilumen 10y ago
You mean like JavaScript? http://caniuse.com/#search=const http://caniuse.com/#search=const http://caniuse.com/#search=let http://caniuse.com/#search=let
- nickthemagicman 10y ago
  No I mean a REAL block scoped language! JS is cool but these are just bolted on features. Why does a function I pass into an Ajax query need a call statement? Why does 'this' have so many interpretations depending on its context? Other languages approach these in simpler ways. Functions inherit the scope in which they are executed and 'this' applies to its parent object. Also, whats up with nested asynchronous statements? I know ES6 and 7 are working on it but new languages would be ideal with new takes on solving some of the tough parts of web development.

st3fan 10y ago

Why speculate about what Apple is doing if you can just go look at the WebKit change history. Search for WebAssembly on https://trac.webkit.org https://trac.webkit.org and you can see that there is a lot of work happening. The most recent commit being "WebAssembly API: implement Instance" - https://trac.webkit.org/changeset/207929 https://trac.webkit.org/changeset/207929 So yeah it looks like it is not finished. But it also looks like they are investing a lot of engineering time in this feature as we speak.

awqrre 10y ago

Being a binary format is the worst part of WebAssembly... for the open web.

ajnin 10y ago
Why would that be a problem ? The open web needs standards that are well defined and used by everyone, and WebAssembly seems to bring just that with the simultaneous announcements by several browser vendors. PNG is binary too and it's arguably one of the assets of the open web.
haberman 10y ago
There is this weird belief that being a text format automatically means open, reusable, interoperable and being a binary format automatically means closed, proprietary, opaque. As counterexamples, here are several binary formats that are very open: ELF, DWARF, PNG, tar, gzip, Ogg and all its subformats, FLAC, JPEG2000. On the other hand, you have something like OOXML, which while technically open/standardized, is so incredibly complicated that it is extremely difficult to implement well. Just because something is text-based does not make it simple.
- z3t4 10y ago
  I think Wasm will be more advanced then PNG. And if there are code execution exploits in PNG, I can only imagine how many exploits there will be in Wasm.
  - haberman 10y ago
    And how many have there been in HTML, JavaScript, and CSS? https://en.wikipedia.org/wiki/Pwn2Own https://en.wikipedia.org/wiki/Pwn2Own
- awqrre 10y ago
  I was saying this because in many binary formats, lots of information is lost in the code to binary conversion (.c to binary, for example) ... and with current connection and processor speeds, I don't think that binary will help that much or be worth the trade-off. But I get your point and I know that html, js, etc can be highly obfuscated but I did extract some features from gmail before and it was not quite as bad as with ASM extracted from a binary...

wentoodeep 10y ago

Finally, time to create a programming language that run on top of wasm.

nippur72 10y ago
https://github.com/evanw/thinscript https://github.com/evanw/thinscript

Ericson2314 10y ago

I you think about it, a WASM "process" is a great middle ground between a conventional VM (ugly hardware skeoumorphism) and container (ugly Unix). I hope this becomes the standard interface for server hosting, not just the browser.

TheAceOfHearts 10y ago

Maybe someone that's more familiar with wasm can enlighten me, but isn't this still extremely limited in the capabilities it exposes? With so many limitations in place, what are some example use-cases that this helps with? Am I being too negative and unrealistic? I don't know what kind of expectations I should have. I'm not writing this to bait responses. It seems to be that until you get lower level network capabilities and some form of file system access, you're just too limited.

dpacmittal 10y ago
>It seems to be that until you get lower level network capabilities and some form of file system access, you're just too limited. JS doesn't give you those things either but would you call it limited? I think its a very early preview and we can expect a lot of limitations removed as the technology progresses.
- TheAceOfHearts 10y ago
  I do think JS is very limited for non-networked applications. If most of what you're doing is hitting APIs and displaying that data, it's great. But if you're building an app that doesn't depend on the network, you find yourself way more limited in most cases. The solution for many people is to go for Electron, but that takes you completely out of the web sandbox. I understand that it's incredibly challenging to get multiple vendors to agree on anything, and I'm sure we'll get to a good place eventually, but I guess I'm just feeling a bit frustrated with the state of things. What does this initial release of wasm enable? I've heard that game developers are expected to be the initial target audience. Do we provide adequate APIs for storing game assets? As an example, I think the latest Doom game is 50GB. I guess I'm a bit concerned that all of this incredible work will get done and released, but nobody will be able to make use of it? Is this a legitimate concern or am I being irrational? I guess I'd have a bit more peace of mind if there were some examples of concrete use-cases that are expected to be solved by this work. Maybe these use-case examples already exist and I haven't seen em? I'll admit I haven't looked around much. This is a concern I've had with regular web APIs as well. Sometimes I'll read about a new spec that's being developed, but maybe due to my poor understanding or lack of knowledge, I'll end up confused as to the purpose of those APIs.

grondilu 10y ago

How reasonable is it to hope that WebAssembly becomes a compilation target for GCC?

z3t4 10y ago

My biggest worry is that everyone will turn this off due to security concerns.

mschuetz 10y ago

What about debugging? A useful debugging suite, like the current chrome developer tools for javascript, is a must have in my opinion.

jlebrech 10y ago

will this mean we can use gtk for websites in the future?

imtringued 10y ago
You can run Qt in the browser already. http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc... I wouldn't recommend it.
- jlebrech 10y ago
  yep, i'm looking for a library that's in a state that you WOULD recommend it. :)

hitlin37 10y ago

so it compiles c++ to webassembly syntax using empscripten compiler. what js has to do with webassembly? Is the idea is same with js? i.e. compiler js code to webassembly. noob here on web assembly.

TbobbyZ 10y ago

Based on this tutorial http://webassembly.org/getting-started/developers-guide/ http://webassembly.org/getting-started/developers-guide/ web assembly lets youvwrite web apps in C?