4 ms·

"Still, it seems to me that in the web world, nobody takes the time to pause, breathe and think things out for even a moment." Hey, how about that, another per

"Still, it seems to me that in the web world, nobody takes the time to pause, breathe and think things out for even a moment." Hey, how about that, another person who thinks this. And this from someone who read the entire ES5 specification and built a JIT compiler for JS. She gives a good example of the web moving too fast. Already asm.js is obsolete and it didn't even mature enough to be used. It's starting to feel like complexity for complexity's sake. Java and JavaScript both had a chance to win in the early days of the browser wars. JS came out on top, and it was vastly simpler than Java. Now they want to turn JS into Java. Maybe this will be the opening Google's Dart needed to take off.

azakai 11y ago
It does feel fast for asm.js, but WebAssembly is simply much better than it. We did asm.js because there wasn't an option to do something better earlier; now that there is, with all browser vendors eager to collaborate, it seems pointless to delay. Also, this evolution should not be too disruptive. First, asm.js content will continue to work, since it is just JS; it will also continue to be fast (in fact, WebAssembly will polyfill into asm.js in the short term). Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web).
- vmorgulis 11y ago
  >Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web). The problem is around the API. I know you do your best to provide a platform similar to native (with fopen(), sockets, SDL...) but I wonder if it is not simpler to do that with a VM (a kind of kernel for emscripten) ? From time to time, I look at qemu source code to find a solution. Originally, Fabrice Bellard did a standalone libqemu but it was removed. There is the SPLICE protocol too for the graphics or even VNC. I'm thinking of a layer that do not rely on the DOM or emscripten JS pragmas. Thus we could have a world of lightweight linux/bsd distros for the web. PS: I've seen your work on musl and signals.
  - azakai 11y ago
    Not sure I understand the problem - what is the issue with APIs? WebAssembly will have the same API access as asm.js, both can call into JS (and JS can then access any web API).
    - vmorgulis 11y ago
      API are OK but they are tedious to implement. You have to discover the good way to manage each subsystem. I think of something more low level for a VM that could run inside a web worker (or in the main thread). It's visible interface could be (with ArrayBuffer): - an address space for a virtual framebuffer - an address space for a virtual disk - i/o with ports for sockets, mouse, keyboard ... With that, we could use existing OS. There is too much case to implement all the existing API and each case can be complicated and have implicit assumptions. For example, instead of mapping fopen() paths to localStorage or URLs in XHR, we could implement an existing hadware API for disk storage. Instead of implementing SDL, implement a VGA memory. I think it is more reliable to use on the lowest interface and you can reuse all the stack (from the kernel, to GNOME and Firefox, all inside the browser). The rules of mapping what to what will be defined outside the VM. The browser could be in charge of these rules. The rules are: - save this address space to localStorage (or IndexDB) - send this address space in XHR (or websocket) - put this address space to this canvas (with putImageData()) I had this idea after reading a spec of a VM for a Forth: http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-o-ports http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-... I'm not criticizing your work nor emscripten at all. I'm a big fan :-) It's more about making the things simpler, get rid of the complexity, increase the features and liberate everybody of the burden of mapping native API to Web API. It's like Cygwin vs qemu/kvm. I'd like to help emscripten and I see that.
      - azakai 11y ago
        Making a new set of APIs like that would need to be done very carefully, to keep the web consistent and also to make sure it is sandboxed properly and so forth. In general the web is actually going in that direction, for example WebGL is similar to low-level OpenGL. But obviously in many other APIs, that is not the case. There are proposals for various new APIs, like for file storage, but they are each being debated separately. I don't think WebAssembly is going to change anything in that regard - we can propose new APIs for it, but the proposals will go through the usual processes.
lmm 11y ago
JS didn't win by being simpler than Java - I'd argue it never was. It won by being more tightly integrated into the browser. When one language runs on every page and another runs only in embedded rectangles when you have the right plugins installed, it's no surprise which one won.

azakai 11y ago

It does feel fast for asm.js, but WebAssembly is simply much better than it. We did asm.js because there wasn't an option to do something better earlier; now that there is, with all browser vendors eager to collaborate, it seems pointless to delay. Also, this evolution should not be too disruptive. First, asm.js content will continue to work, since it is just JS; it will also continue to be fast (in fact, WebAssembly will polyfill into asm.js in the short term). Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web).

vmorgulis 11y ago
>Second, tools like Emscripten will be able to emit both asm.js and WebAssembly, so that those users don't need to even care about what their compiler is producing (and those users are the great majority of people using asm.js on the web). The problem is around the API. I know you do your best to provide a platform similar to native (with fopen(), sockets, SDL...) but I wonder if it is not simpler to do that with a VM (a kind of kernel for emscripten) ? From time to time, I look at qemu source code to find a solution. Originally, Fabrice Bellard did a standalone libqemu but it was removed. There is the SPLICE protocol too for the graphics or even VNC. I'm thinking of a layer that do not rely on the DOM or emscripten JS pragmas. Thus we could have a world of lightweight linux/bsd distros for the web. PS: I've seen your work on musl and signals.
- azakai 11y ago
  Not sure I understand the problem - what is the issue with APIs? WebAssembly will have the same API access as asm.js, both can call into JS (and JS can then access any web API).
  - vmorgulis 11y ago
    API are OK but they are tedious to implement. You have to discover the good way to manage each subsystem. I think of something more low level for a VM that could run inside a web worker (or in the main thread). It's visible interface could be (with ArrayBuffer): - an address space for a virtual framebuffer - an address space for a virtual disk - i/o with ports for sockets, mouse, keyboard ... With that, we could use existing OS. There is too much case to implement all the existing API and each case can be complicated and have implicit assumptions. For example, instead of mapping fopen() paths to localStorage or URLs in XHR, we could implement an existing hadware API for disk storage. Instead of implementing SDL, implement a VGA memory. I think it is more reliable to use on the lowest interface and you can reuse all the stack (from the kernel, to GNOME and Firefox, all inside the browser). The rules of mapping what to what will be defined outside the VM. The browser could be in charge of these rules. The rules are: - save this address space to localStorage (or IndexDB) - send this address space in XHR (or websocket) - put this address space to this canvas (with putImageData()) I had this idea after reading a spec of a VM for a Forth: http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-o-ports http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-... I'm not criticizing your work nor emscripten at all. I'm a big fan :-) It's more about making the things simpler, get rid of the complexity, increase the features and liberate everybody of the burden of mapping native API to Web API. It's like Cygwin vs qemu/kvm. I'd like to help emscripten and I see that.
    - azakai 11y ago
      Making a new set of APIs like that would need to be done very carefully, to keep the web consistent and also to make sure it is sandboxed properly and so forth. In general the web is actually going in that direction, for example WebGL is similar to low-level OpenGL. But obviously in many other APIs, that is not the case. There are proposals for various new APIs, like for file storage, but they are each being debated separately. I don't think WebAssembly is going to change anything in that regard - we can propose new APIs for it, but the proposals will go through the usual processes.

lmm 11y ago

JS didn't win by being simpler than Java - I'd argue it never was. It won by being more tightly integrated into the browser. When one language runs on every page and another runs only in embedded rectangles when you have the right plugins installed, it's no surprise which one won.