8 ms·

Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations

by sjrd 9y ago

Nice article. Although, as always with articles on WebAssembly, it keeps repeating that wasm is faster than JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). And that means there are zillions of developers who keep being misled in thinking stuff like "Why don't you compile to wasm to make your stuff faster?". That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!"

gigatexal 9y ago
Yeah I read the article too and thought: but what can I do with wasm?
- deleted 9y ago
  [deleted]
- kbumsik 9y ago
  You can import C (and many others) libraries without re-implementing it in JS for browsers. In my company's case, we compile C-written libopus almost directly to encode audio streams into Opus on browsers, not on servers. In this way we benefit much less data traffic and server CPU loads.
  - QAkICoU7IDNkpFu 9y ago
    >You can import C (and many others) libraries This means compiling the lib to wasm, right? At first I was thinking of running JS clientside that imports some C lib somehow, which confused me.
    - kbumsik 9y ago
      Yes. The C lib will be compiled into wasm. You can use the wasm-compiled code in a browser through JS wrappers. So you can say importing C lib on JS client side anyway. Note that wasm's main objective is to run non-JS code on browsers, not for a faster JS. Here is the best overview and tutorial I've ever seen in HN , if you are interested: https://news.ycombinator.com/item?id=15958827 https://news.ycombinator.com/item?id=15958827
      - gigatexal 9y ago
        So you could do the same with Cython then, too? Interesting.
        kbumsik 9y ago
        I've never experienced with Cython. But if Cython is to compile anPython file into a C file then probably.
icen 9y ago
> That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!" Is this this absurd? Given you can compile WASM whilst streaming, you should really precompile your JS into WASM if you can.
- sjrd 9y ago
  I can't tell whether you're being sarcastic or not, so I will answer as if you are not. Yes, it is absurd. Because your wasm that was compiled from JS needs to embed an entire implementation of the dynamic nature of JS. And to make all those dynamic features remotely fast, you cannot just compile them as is. You need to use a JIT to be able to perform speculative optimizations. But then, where's the JIT? Oh, it's built inside your wasm code. And basically you end up shipping a JS interpreter+compiler+JIT as part of your wasm, instead of just the .js code. Parsing and compiling all of that will be much, much worse than parsing the .js code and feed it to the already existing JS interpreter+compiler+JIT that is in the browser.
  - Yoric 9y ago
    On the other hand, you could compile well-behaved subsets of JavaScript into wasm. Kind of what asm.js was doing. Whether that's useful in practice is an open question, but it's plausible.
    - sjrd 9y ago
      asm.js was not a well-behaved subset of JavaScript. It was a well-behaved subset of assembly that happened to be encoded in JavaScript. There is virtually no human-written JS code that is amenable to compilation to wasm in a meaningful way. At the very least, you need a (mostly) sound type system to be able to compile to wasm with a positive expected ROI. The speed of wasm comes in a large part from the fact that it is entirely statically typed, which means we don't need the speculative optimizations (and their deoptimization guards) all over the place.
      - jahewson 9y ago
stevemk14ebr 9y ago
I don't think that's absurd at all. WebASM really should be the ASM of the web, everything should be compiled to it. A little pre-compilation of JS to WebASM makes sense to me
- sjrd 9y ago
  See my answer here: https://news.ycombinator.com/item?id=16169705 https://news.ycombinator.com/item?id=16169705
- white-flame 9y ago
  As far as not making sense goes, sorry but your post doesn't make any to me, either. Why would we possibly return to a manual memory management, raw pointer oriented, assembly language level of abstraction from the much richer and safer abstraction that JS already has? Wasm doesn't even have any notion of Characters or Strings! You really want to return to the days of each project having their own String libraries, because it's all built on top of raw asm? Webasm is not for JS-style code! You can't have "a little pre-compilation of JS to WebASM", that makes zero sense. We already have the incredibly complex JIT compilation of JS to x64/ARM/etc, which necessarily interacts with the garbage collector, type system, permissions & security, browser debugging/profiling tools, etc, all of which wasm does not have any notion. Wasm is a raw C-ish sandbox environment for cross-compilation of static languages to expose their behavior to javascript, for straight-line CPU performance in number crunching as in games, software rendering, numerical analysis, compression/decompression, etc.
  - felipellrocha 9y ago
    You don't really write wasm by hand. You use a higher level language that compiles to it. I wouldn't mind using go for the web, for example, if I wanted more performance, and it takes care of all the concerns you mentioned above for you...
  - hateduser2 9y ago
    They’re adding all those things to wasm. I think you’re mistaken about the future.
pjmlp 9y ago
I don't see lack of GC as limitation, just bring your alongside. Modern CPUs also don't have hardware GC support. Intel i432 was the last attempt at it. Interaction with DOM can be achieved with a few imported functions.
- cwzwarich 9y ago
  > Modern CPUs also don't have hardware GC support. Intel i432 was the last attempt at it. Intel i432 was far from the last attempt. Besides all of the Lisp HW developed after it, Azul made CPUs in the 2000s with hardware support for GC. Acceleration of concurrent copying collection requires a surprisingly low amount of CPU support.
  - pjmlp 9y ago
    I had my history reversed regarding i432 vs Lisp HW. You are right I also forgot about Azul, but eventually they dropped it, because it wasn't worthwhile anymore, just like it happened with all other specialized hardware implementations.
    - dfox 9y ago
      Azul (and AFAIK most lisp machines) does not do garbage collection in hardware. In these contexts the "GC HW" involves hardware acceleration of read/write barriers required by concurrent and incremental GCs (which otherwise requires the compiler/JIT to inline implementation of barriers into user code). The reason why Azul can now use stock amd64 CPUs is that they found that you can abuse the MMU to provide exactly this kind of HW accelerated barriers.
yzmtf2008 9y ago
No one is saying you should do your whole application in WASM though, it's really just like native extensions in any dynamic language: of course, you're not going to get GC or interaction with dynamic parts of the language in your extension, but the reason might be: - libraries written in another language, such as SQL.js - hot spots of an application that can benefit from fast number crunching (e.g., gaming, visualization) - truly cross-platform at native performance etc. I don't think anyone serious enough to use WASM in their application is making the assumption of using wasm will make all your stuff faster. It won't. It's just another performance tool, with its benefits subject to performance methodologies. Sidebar: Google Doc is an interesting application in this perspective, given they render the entire application in a canvas, and the application itself is probably not written in JS. I'm excited what the future holds for tools like Google Doc.
- sjrd 9y ago
  I understand all that. I have been writing compilers for more than 10 years, including the compiler of Scala.js. I am not criticizing wasm nor its benefits. What I profoundly dislike is that such good articles about wasm, written by excellent technical people, all silently ignore that. I am absolutely certain that the authors know all about it, but they don't mention that to their audience, which, for the majority, doesn't know. Therefore, that very silence (not just glossing over, but actual silence) brings misinformation to the masses.
flavio81 9y ago
>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs. Mark my words.
- ake1 9y ago
  do you know of any ongoing work?
- avaer 9y ago
  I'll do you another. If 2D screens ever cease being the main way of interacting with computers, something like a DOM-less WASM will take over consumer computing, and the DOM will get washed away in the process.
  - dfox 9y ago
    Moving from 2D to 3D does not imply that applications will all use immediate mode. And having some standard way of doing retained mode 3D (which is the major feature provided typical 3D game engines and there is no reason why DOM could not be at least partially used as the underlying data model) seems like one of the requirements for that shift to actually happen.
    - rictic 9y ago
      For an example of this model today, take a look at the wonderful A-Frame library for doing 3D scenes, including web VR.
  - dragonwriter 9y ago
    Or something like X3dom will take center stage.
- dragonwriter 9y ago
  Declarative UI systems that look a lot like HTML+CSS+JS, keep cropping up in other domains besides the web; I think, but for increasing freedom to replace the JS part with some other languages to specify behavior, the basic model will be around for a long time.

by sjrd 9y ago

gigatexal 9y ago

Yeah I read the article too and thought: but what can I do with wasm?

deleted 9y ago
[deleted]
kbumsik 9y ago
You can import C (and many others) libraries without re-implementing it in JS for browsers. In my company's case, we compile C-written libopus almost directly to encode audio streams into Opus on browsers, not on servers. In this way we benefit much less data traffic and server CPU loads.
- QAkICoU7IDNkpFu 9y ago
  >You can import C (and many others) libraries This means compiling the lib to wasm, right? At first I was thinking of running JS clientside that imports some C lib somehow, which confused me.
  - kbumsik 9y ago
    Yes. The C lib will be compiled into wasm. You can use the wasm-compiled code in a browser through JS wrappers. So you can say importing C lib on JS client side anyway. Note that wasm's main objective is to run non-JS code on browsers, not for a faster JS. Here is the best overview and tutorial I've ever seen in HN , if you are interested: https://news.ycombinator.com/item?id=15958827 https://news.ycombinator.com/item?id=15958827
    - gigatexal 9y ago
      So you could do the same with Cython then, too? Interesting.
      - kbumsik 9y ago
        I've never experienced with Cython. But if Cython is to compile anPython file into a C file then probably.

icen 9y ago

> That includes absurdities like "We should write a compiler from JavaScript to wasm to make all our JS faster!" Is this this absurd? Given you can compile WASM whilst streaming, you should really precompile your JS into WASM if you can.

sjrd 9y ago
I can't tell whether you're being sarcastic or not, so I will answer as if you are not. Yes, it is absurd. Because your wasm that was compiled from JS needs to embed an entire implementation of the dynamic nature of JS. And to make all those dynamic features remotely fast, you cannot just compile them as is. You need to use a JIT to be able to perform speculative optimizations. But then, where's the JIT? Oh, it's built inside your wasm code. And basically you end up shipping a JS interpreter+compiler+JIT as part of your wasm, instead of just the .js code. Parsing and compiling all of that will be much, much worse than parsing the .js code and feed it to the already existing JS interpreter+compiler+JIT that is in the browser.
- Yoric 9y ago
  On the other hand, you could compile well-behaved subsets of JavaScript into wasm. Kind of what asm.js was doing. Whether that's useful in practice is an open question, but it's plausible.
  - sjrd 9y ago
    asm.js was not a well-behaved subset of JavaScript. It was a well-behaved subset of assembly that happened to be encoded in JavaScript. There is virtually no human-written JS code that is amenable to compilation to wasm in a meaningful way. At the very least, you need a (mostly) sound type system to be able to compile to wasm with a positive expected ROI. The speed of wasm comes in a large part from the fact that it is entirely statically typed, which means we don't need the speculative optimizations (and their deoptimization guards) all over the place.
    - jahewson 9y ago

stevemk14ebr 9y ago

I don't think that's absurd at all. WebASM really should be the ASM of the web, everything should be compiled to it. A little pre-compilation of JS to WebASM makes sense to me

sjrd 9y ago
See my answer here: https://news.ycombinator.com/item?id=16169705 https://news.ycombinator.com/item?id=16169705
white-flame 9y ago
As far as not making sense goes, sorry but your post doesn't make any to me, either. Why would we possibly return to a manual memory management, raw pointer oriented, assembly language level of abstraction from the much richer and safer abstraction that JS already has? Wasm doesn't even have any notion of Characters or Strings! You really want to return to the days of each project having their own String libraries, because it's all built on top of raw asm? Webasm is not for JS-style code! You can't have "a little pre-compilation of JS to WebASM", that makes zero sense. We already have the incredibly complex JIT compilation of JS to x64/ARM/etc, which necessarily interacts with the garbage collector, type system, permissions & security, browser debugging/profiling tools, etc, all of which wasm does not have any notion. Wasm is a raw C-ish sandbox environment for cross-compilation of static languages to expose their behavior to javascript, for straight-line CPU performance in number crunching as in games, software rendering, numerical analysis, compression/decompression, etc.
- felipellrocha 9y ago
  You don't really write wasm by hand. You use a higher level language that compiles to it. I wouldn't mind using go for the web, for example, if I wanted more performance, and it takes care of all the concerns you mentioned above for you...
- hateduser2 9y ago
  They’re adding all those things to wasm. I think you’re mistaken about the future.

pjmlp 9y ago

I don't see lack of GC as limitation, just bring your alongside. Modern CPUs also don't have hardware GC support. Intel i432 was the last attempt at it. Interaction with DOM can be achieved with a few imported functions.

cwzwarich 9y ago
> Modern CPUs also don't have hardware GC support. Intel i432 was the last attempt at it. Intel i432 was far from the last attempt. Besides all of the Lisp HW developed after it, Azul made CPUs in the 2000s with hardware support for GC. Acceleration of concurrent copying collection requires a surprisingly low amount of CPU support.
- pjmlp 9y ago
  I had my history reversed regarding i432 vs Lisp HW. You are right I also forgot about Azul, but eventually they dropped it, because it wasn't worthwhile anymore, just like it happened with all other specialized hardware implementations.
  - dfox 9y ago
    Azul (and AFAIK most lisp machines) does not do garbage collection in hardware. In these contexts the "GC HW" involves hardware acceleration of read/write barriers required by concurrent and incremental GCs (which otherwise requires the compiler/JIT to inline implementation of barriers into user code). The reason why Azul can now use stock amd64 CPUs is that they found that you can abuse the MMU to provide exactly this kind of HW accelerated barriers.

yzmtf2008 9y ago

No one is saying you should do your whole application in WASM though, it's really just like native extensions in any dynamic language: of course, you're not going to get GC or interaction with dynamic parts of the language in your extension, but the reason might be: - libraries written in another language, such as SQL.js - hot spots of an application that can benefit from fast number crunching (e.g., gaming, visualization) - truly cross-platform at native performance etc. I don't think anyone serious enough to use WASM in their application is making the assumption of using wasm will make all your stuff faster. It won't. It's just another performance tool, with its benefits subject to performance methodologies. Sidebar: Google Doc is an interesting application in this perspective, given they render the entire application in a canvas, and the application itself is probably not written in JS. I'm excited what the future holds for tools like Google Doc.

sjrd 9y ago
I understand all that. I have been writing compilers for more than 10 years, including the compiler of Scala.js. I am not criticizing wasm nor its benefits. What I profoundly dislike is that such good articles about wasm, written by excellent technical people, all silently ignore that. I am absolutely certain that the authors know all about it, but they don't mention that to their audience, which, for the majority, doesn't know. Therefore, that very silence (not just glossing over, but actual silence) brings misinformation to the masses.

flavio81 9y ago

>JavaScript, without ever mentioning the limitations of wasm wrt. JS (no GC, no interaction with the DOM or with JS libraries besides numbers, etc.). DOM will die as soon as the industry moves to one or two good GUI toolkits that run under Webassembly and are way faster to use than the cumbersome present combination of HTML+CSS+CSS preprocessor+JS libs. Mark my words.

ake1 9y ago
do you know of any ongoing work?
avaer 9y ago
I'll do you another. If 2D screens ever cease being the main way of interacting with computers, something like a DOM-less WASM will take over consumer computing, and the DOM will get washed away in the process.
- dfox 9y ago
  Moving from 2D to 3D does not imply that applications will all use immediate mode. And having some standard way of doing retained mode 3D (which is the major feature provided typical 3D game engines and there is no reason why DOM could not be at least partially used as the underlying data model) seems like one of the requirements for that shift to actually happen.
  - rictic 9y ago
    For an example of this model today, take a look at the wonderful A-Frame library for doing 3D scenes, including web VR.
- dragonwriter 9y ago
  Or something like X3dom will take center stage.
dragonwriter 9y ago
Declarative UI systems that look a lot like HTML+CSS+JS, keep cropping up in other domains besides the web; I think, but for increasing freedom to replace the JS part with some other languages to specify behavior, the basic model will be around for a long time.