7 ms·

WebAssembly consensus and end of Browser Preview

167 points by brosky117 10y ago

pella 10y ago
more: https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-whats-next/ 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."
felipellrocha 10y ago
Does anyone have an example on how to get the SDL2 to compile using WebAssembly?
- n00b101 10y ago
  There are several SDL2 Emscripten examples for compiling to ASM.js. You would follow the same process, except just direct Emscripten to generate WebAssembly using a "vanilla" LLVM's WebAssembly backend [1]. You will probably first need to compile LLVM yourself with WebAssembly experimental target enabled, as explained in the link. [1] https://github.com/kripken/emscripten/wiki/New-WebAssembly-Backend https://github.com/kripken/emscripten/wiki/New-WebAssembly-B...
- azakai 10y ago
  There is already SDL2 support for emscripten, and emscripten can compile to WebAssembly with the WASM flag flipped on. So basically just use emcc with -s WASM=1 -s USE_SDL=2 for WebAssembly + SDL2. The test_sdl2* tests in emscripten's test suite have working samples in them, https://github.com/kripken/emscripten/blob/master/tests/test_browser.py#L2371 https://github.com/kripken/emscripten/blob/master/tests/test... A full SDL1 testcase is in the tutorial, http://kripken.github.io/emscripten-site/docs/getting_started/Tutorial.html#generating-html http://kripken.github.io/emscripten-site/docs/getting_starte...
pella 10y ago
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/ http://webassembly.org/getting-started/developers-guide/
gedy 10y ago
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.
- TazeTSchnitzel 10y ago
  asm.js is not exactly human-readable at present. If anything, the WebAssembly form might be more readable.
- CaptSpify 10y ago
  I thought web-assembly still had the view-source implemented even though it is sent as binary, is that incorrect?
  - __s 10y ago
    It'll be like viewing an assembly print out. Which I'm sure will be less opaque than asm.js output, but comparable to asm output
- geofft 10y ago
  JavaScript minifiers are already in wide use by anyone making serious use of JS, and JavaScript obfuscators exist. I think the cause of computing freedom is likely better served by building high-quality wasm disassemblers (radare has an open ticket, for instance) and by making sure that wasm code is so tightly sandboxed that DRM can't work, i.e., that you have the equivalent of an "analog hole" because you can write a browser extension / patch that taps all the data and the inside code can't tell. Hoping that technologies won't get developed has historically not been a productive approach for software freedom; the folks who want to take our freedom have enough resources that they'll do it whether or not there's a standards process involved.
  - kbenson 10y ago
    > that you have the equivalent of an "analog hole" because you can write a browser extension / patch that taps all the data and the inside code can't tell. Even if it isn't, it's not like the browser itself is just some binary blob these days. Taking the source for firefox or blink or webkit and compiling your own version with slight changes is not only possible, it's already done in many instances. What's Mozilla's response when you take their browser and provide a fork with the sole change being to provide more freedom and choice? Not that it even matters, as it's not like you need to get mindshare from the public for this, developers that want to see the source will actively search for and find solutions, or make their own. There are simple extensions to bypass CORS controls for most (all?) browsers. If they didn't exist, browser variants disabling those same security mechanisms would exist. It's all opt-in gentlemen's agreement style security. Both ends have to by in for it to work, and you control your end...
zfedoran 10y ago
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)
- TazeTSchnitzel 10y ago
  > 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? It's not, because asm.js is treated specially in some cases. For instance, in Firefox asm.js calls to JS have to go through an FFI, IIRC.
- geofft 10y ago
  asm.js code is "just" JS code in the sense that it is a subset of JS: a non-asm.js-aware JS implementation can treat it the same way as normal JS, and it will execute correctly. But in implementations where it's fast, asm.js is usually handled separately. It looks like Mozilla's asm.js implementation used to have the exact same problem: https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/#comment-17219 https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/#c... I'm not familiar enough with asm.js to know if that's still a problem.
- klodolph 10y ago
  First question in the FAQ https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md Memory allocation is particularly painful in asm.js, for example.
  - zfedoran 10y ago
    Thank you for that link, exactly what I was looking for.
z1mm32m4n 10y ago
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!).
- Nypro 10y ago
  The logo isn't as nice as the most voted one. But I get the philosophy behind it though, probably the biggest reason it was chosen. But my heart still remains with the other logo. It looks so modern and can go with different color palettes.
  - simplify 10y ago
    What did the other logo look like?
- steveklabnik 10y ago
  My understanding is that that is coming.
- mbebenita 10y ago
  That's in the works. Here is a patch that provides some of the foundation for getting first-class support for WASM: https://reviews.llvm.org/D26722 https://reviews.llvm.org/D26722 Interestingly enough, the "clunky" Emscripten compilation path is quite a bit faster than the WASM backed ATM because it bypasses all the cruft in the LLVM backend which can be pretty slow.
angrygoat 10y ago
I like the new logo (inspired by the side-on profile of an IC) https://github.com/WebAssembly/design/issues/980 https://github.com/WebAssembly/design/issues/980
- mparlane 10y ago
  Top-down I think ?
hubert123 10y ago
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?
- roryokane 10y ago
  No, WebAssembly is not currently a general-purpose replacement for JavaScript. Maybe in the future it will be, but right now WebAssembly doesn’t have any APIs to access the DOM. This makes it only good for quickly doing calculations with numbers or data that can be easily represented as numbers, such as implementing a physics engine for a browser game.
  - deleted 10y ago
    [deleted]
  - bryanrasmussen 10y ago
    Even if WebAssembly had some API to access the DOM I have a feeling it would always be sort of the same thing as GWT - you can do stuff that touches the UI in it but probably isn't the best thing.
  - ilaksh 10y ago
    It doesn't have any access to any web APIs period, not just the DOM. And it doesn't make sense to use it for physics because GPUs can do that much faster (so that would be WebGL, which like everything else is JS only).
themihai 10y ago
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)
- walkingolof 10y ago
  Support for GC and DOM is coming https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
  - themihai 10y ago
    I know ...but when? 2030? There is no timeline. My point is that GC and DOM should have been part of the MVP if it were to gain any traction as the assembly of the web. Otherwise it remains an experiment/niche like Asm.js, PNaCI etc. I didn't see many(if any) "todo" apps in wasm yet.
mycall 10y ago
> reference interpreter not a compiler? ok.
- fulafel 10y ago
  A reference implementation of something is not end-user software, it's meant to be part of the specification by codifying semantics. An interpreter is more useful in this case (what would even be the compile target?).
cyborgx7 10y ago
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?
- tinco 10y ago
  All WebAssembly does is further obfuscate the code that runs in your browser. Have you ever tried to reverse-engineer Gmail or any modern web app? It's already basically impossible. A part of the web has simply become an application distribution system. That's not necessarily a bad thing, many other important websites are still very much open and accessible, like Wikipedia for example. The web just became bigger than it was before 2001.
  - cyborgx7 10y ago
    This is a further step in the reduction of user control, the thing that I think made the web so successful in the first place. I suspect it will kill the web, but it will at least make it unacceptable for me. I would like to find and support the replacement as soon as possible.
    - pjmlp 10y ago
      The user never was in control, given that the majority of the logic runs on a server that the user never sees or has access to.
jwatte 10y ago
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.
pc2g4d 10y ago
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.
ilaksh 10y ago
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.
user1241320 10y ago
Cool to see also Rust supporting it: https://blog.rust-lang.org/2016/12/22/Rust-1.14.html https://blog.rust-lang.org/2016/12/22/Rust-1.14.html

167 points by brosky117 10y ago

pella 10y ago

more: https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-whats-next/ 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."

felipellrocha 10y ago

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

n00b101 10y ago
There are several SDL2 Emscripten examples for compiling to ASM.js. You would follow the same process, except just direct Emscripten to generate WebAssembly using a "vanilla" LLVM's WebAssembly backend [1]. You will probably first need to compile LLVM yourself with WebAssembly experimental target enabled, as explained in the link. [1] https://github.com/kripken/emscripten/wiki/New-WebAssembly-Backend https://github.com/kripken/emscripten/wiki/New-WebAssembly-B...
azakai 10y ago
There is already SDL2 support for emscripten, and emscripten can compile to WebAssembly with the WASM flag flipped on. So basically just use emcc with -s WASM=1 -s USE_SDL=2 for WebAssembly + SDL2. The test_sdl2* tests in emscripten's test suite have working samples in them, https://github.com/kripken/emscripten/blob/master/tests/test_browser.py#L2371 https://github.com/kripken/emscripten/blob/master/tests/test... A full SDL1 testcase is in the tutorial, http://kripken.github.io/emscripten-site/docs/getting_started/Tutorial.html#generating-html http://kripken.github.io/emscripten-site/docs/getting_starte...

pella 10y ago

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/ http://webassembly.org/getting-started/developers-guide/

gedy 10y ago

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.

TazeTSchnitzel 10y ago
asm.js is not exactly human-readable at present. If anything, the WebAssembly form might be more readable.
CaptSpify 10y ago
I thought web-assembly still had the view-source implemented even though it is sent as binary, is that incorrect?
- __s 10y ago
  It'll be like viewing an assembly print out. Which I'm sure will be less opaque than asm.js output, but comparable to asm output
geofft 10y ago
JavaScript minifiers are already in wide use by anyone making serious use of JS, and JavaScript obfuscators exist. I think the cause of computing freedom is likely better served by building high-quality wasm disassemblers (radare has an open ticket, for instance) and by making sure that wasm code is so tightly sandboxed that DRM can't work, i.e., that you have the equivalent of an "analog hole" because you can write a browser extension / patch that taps all the data and the inside code can't tell. Hoping that technologies won't get developed has historically not been a productive approach for software freedom; the folks who want to take our freedom have enough resources that they'll do it whether or not there's a standards process involved.
- kbenson 10y ago
  > that you have the equivalent of an "analog hole" because you can write a browser extension / patch that taps all the data and the inside code can't tell. Even if it isn't, it's not like the browser itself is just some binary blob these days. Taking the source for firefox or blink or webkit and compiling your own version with slight changes is not only possible, it's already done in many instances. What's Mozilla's response when you take their browser and provide a fork with the sole change being to provide more freedom and choice? Not that it even matters, as it's not like you need to get mindshare from the public for this, developers that want to see the source will actively search for and find solutions, or make their own. There are simple extensions to bypass CORS controls for most (all?) browsers. If they didn't exist, browser variants disabling those same security mechanisms would exist. It's all opt-in gentlemen's agreement style security. Both ends have to by in for it to work, and you control your end...

zfedoran 10y ago

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)

TazeTSchnitzel 10y ago
> 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? It's not, because asm.js is treated specially in some cases. For instance, in Firefox asm.js calls to JS have to go through an FFI, IIRC.
geofft 10y ago
asm.js code is "just" JS code in the sense that it is a subset of JS: a non-asm.js-aware JS implementation can treat it the same way as normal JS, and it will execute correctly. But in implementations where it's fast, asm.js is usually handled separately. It looks like Mozilla's asm.js implementation used to have the exact same problem: https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/#comment-17219 https://hacks.mozilla.org/2015/03/asm-speedups-everywhere/#c... I'm not familiar enough with asm.js to know if that's still a problem.
klodolph 10y ago
First question in the FAQ https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md Memory allocation is particularly painful in asm.js, for example.
- zfedoran 10y ago
  Thank you for that link, exactly what I was looking for.

z1mm32m4n 10y ago

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!).

Nypro 10y ago
The logo isn't as nice as the most voted one. But I get the philosophy behind it though, probably the biggest reason it was chosen. But my heart still remains with the other logo. It looks so modern and can go with different color palettes.
- simplify 10y ago
  What did the other logo look like?
steveklabnik 10y ago
My understanding is that that is coming.
mbebenita 10y ago
That's in the works. Here is a patch that provides some of the foundation for getting first-class support for WASM: https://reviews.llvm.org/D26722 https://reviews.llvm.org/D26722 Interestingly enough, the "clunky" Emscripten compilation path is quite a bit faster than the WASM backed ATM because it bypasses all the cruft in the LLVM backend which can be pretty slow.

angrygoat 10y ago

I like the new logo (inspired by the side-on profile of an IC) https://github.com/WebAssembly/design/issues/980 https://github.com/WebAssembly/design/issues/980

mparlane 10y ago
Top-down I think ?

hubert123 10y ago

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?

roryokane 10y ago
No, WebAssembly is not currently a general-purpose replacement for JavaScript. Maybe in the future it will be, but right now WebAssembly doesn’t have any APIs to access the DOM. This makes it only good for quickly doing calculations with numbers or data that can be easily represented as numbers, such as implementing a physics engine for a browser game.
- deleted 10y ago
  [deleted]
- bryanrasmussen 10y ago
  Even if WebAssembly had some API to access the DOM I have a feeling it would always be sort of the same thing as GWT - you can do stuff that touches the UI in it but probably isn't the best thing.
- ilaksh 10y ago
  It doesn't have any access to any web APIs period, not just the DOM. And it doesn't make sense to use it for physics because GPUs can do that much faster (so that would be WebGL, which like everything else is JS only).

themihai 10y ago

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)

walkingolof 10y ago
Support for GC and DOM is coming https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
- themihai 10y ago
  I know ...but when? 2030? There is no timeline. My point is that GC and DOM should have been part of the MVP if it were to gain any traction as the assembly of the web. Otherwise it remains an experiment/niche like Asm.js, PNaCI etc. I didn't see many(if any) "todo" apps in wasm yet.

mycall 10y ago

> reference interpreter not a compiler? ok.

fulafel 10y ago
A reference implementation of something is not end-user software, it's meant to be part of the specification by codifying semantics. An interpreter is more useful in this case (what would even be the compile target?).

cyborgx7 10y ago

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?

tinco 10y ago
All WebAssembly does is further obfuscate the code that runs in your browser. Have you ever tried to reverse-engineer Gmail or any modern web app? It's already basically impossible. A part of the web has simply become an application distribution system. That's not necessarily a bad thing, many other important websites are still very much open and accessible, like Wikipedia for example. The web just became bigger than it was before 2001.
- cyborgx7 10y ago
  This is a further step in the reduction of user control, the thing that I think made the web so successful in the first place. I suspect it will kill the web, but it will at least make it unacceptable for me. I would like to find and support the replacement as soon as possible.
  - pjmlp 10y ago
    The user never was in control, given that the majority of the logic runs on a server that the user never sees or has access to.

jwatte 10y ago

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.

pc2g4d 10y ago

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.

ilaksh 10y ago

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.

user1241320 10y ago

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