from Hacker News

WebAssembly consensus and end of Browser Preview

by brosky117 on 2/28/17, 6:06 PM with 56 comments

  • by pella on 2/28/17, 10:44 PM

    Developer’s Guide "This page provides step-by-step instructions to compile a simple program directly to WebAssembly."

    http://webassembly.org/getting-started/developers-guide/

  • by gedy on 3/1/17, 12:04 AM

    I worry it means "end of browser view source" and frankly concerned this will be (ab)used to implement DRM for information that we can easily view and copy the source now.

  • by pella on 2/28/17, 10:40 PM

    more: https://hacks.mozilla.org/2017/02/where-is-webassembly-now-a...

    "With this, developers can start shipping WebAssembly code. For earlier versions of browsers, developers can send down an asm.js version of the code. Because asm.js is a subset of JavaScript, any JS engine can run it. With Emscripten, you can compile the same app to both WebAssembly and asm.js.Even in the initial release, WebAssembly will be fast. But it should get even faster in the future, through a combination of fixes and new features."

  • by angrygoat on 3/1/17, 5:12 AM

    I like the new logo (inspired by the side-on profile of an IC)

    https://github.com/WebAssembly/design/issues/980

  • by hubert123 on 3/1/17, 5:23 AM

    I still dont understand: Can this be a general purpose replacement for javascript or not? Because if it is then every language, even Dart and typescript, should switch to producing webassembly. Right?

  • by z1mm32m4n on 3/1/17, 1:14 AM

    I think the big milestone for me is going to be when LLVM has first-class support for a wasm backend. I get that you can already get similar behavior using emscripten through asm.js to wasm, but it still feels clunky.

    Even still, it's great to see that things are still moving on smoothly (and the new logo looks really nice!).

  • by ilaksh on 3/2/17, 1:15 AM

    I believe that some of the core people who proposed this are actually NOT getting what they really intended. Because ALL APIs are only accessible through JavaScript still.

    I think this could be much more useful if at least some APIs didn't have to go through JS. Not saying that's easy.

    Part of the problem is the whole idea that every program is supposed to test for the existence of every feature it might need. I think that's ridiculous. I suggested on github that actually what needs to happen eventually is to decompose the web platform into a a bunch of semantically versioned modules. One big problem with that is that modern modularization is not really first class in C++ because of its legacy worldview.

  • by cyborgx7 on 3/1/17, 10:22 AM

    First DRM and now this. I'm getting the feeling the web is not interested in my priorities anymore.

    So if I wanted to support a standard that prioritizes easy, accessible exchange of information, openess and user control with my server, where would I look?

  • by zfedoran on 3/1/17, 12:28 AM

    I'd love to know what the current advantages are over running asm.js? I understand that it will definitely be faster eventually, but if I have a project that uses asm.js today, would it make sense to run it with WebAssembly instead? (ignoring the fact that not all browsers support it)

    One potential issue:

    "If you have lots of back-and-forth between WebAssembly and JS (as you do with smaller tasks), then this overhead is noticeable."

    As far as I'm aware, asm.js code does not have an issue with this, as it is just js code. Is this correct?

    (edit: I should have mentioned that I'm primarily interested from an electron.js point of view at the moment, where Firefox asm.js optimizations are unavailable)

  • by pc2g4d on 3/2/17, 1:01 AM

    Opening the web to non-Javascript languages will make it a more general platform. Imagine if Linux only let you run programs written in Perl! That's largely the situation the web has been stuck in for 20 years. I think the concerns about "view source" are ill-founded, as minified Javascript is already essentially an uninterpretable (by humans) assembly language. This essentially retains the status quo regarding human access to the underlying code, while broadening the number of ways you can build web applications. I support it.

  • by jwatte on 3/1/17, 6:29 PM

    This is great news, if nothing else then because it actually allows programs to grow their heap. Previous emscripten-based solutions have suffered severely from either running out of RAM, or requesting more than they need (and then sometimes not even being able to start because of fragmentation.)

    The web browser is still a second-rate user interface toolkit compared to a native app, but at least this gives us a slight step forward. Whether that's enough, or whether most application development will be made using native toolkits in walled gardens, remains to be seen.

  • by user1241320 on 3/5/17, 7:15 PM

    Cool to see also Rust supporting it: https://blog.rust-lang.org/2016/12/22/Rust-1.14.html

  • by themihai on 3/1/17, 6:00 AM

    I'm afraid that without DOM access and GC it won't get much traction or testing as far as the community is concerned. Did anyone took wasm seriously?(i.e run their main external/internal app on wasm as a beta version)

  • by felipellrocha on 2/28/17, 10:41 PM

    Does anyone have an example on how to get the SDL2 to compile using WebAssembly?

  • by mycall on 3/1/17, 6:01 AM

    > reference interpreter

    not a compiler? ok.