10 ms·

I don't think so. From what I understand, calling WebAssembly functions from JavaScript (and vice-versa) incur a runtime penalty that's way worse than calling

I don't think so. From what I understand, calling WebAssembly functions from JavaScript (and vice-versa) incur a runtime penalty that's way worse than calling JavaScript functions from JavaScript. As such, WebAssembly makes sense for entire applications that would be compiled—think game engines targeting WebGL, or a font rasterizer targeting canvas, etc. Since this only supports a subset of TypeScript, you won't even be able to compile your dependencies to WebAssembly, meaning that literally any code you interact with that you did not write has this performance setback.

forgotpw1123 9y ago
... Until the first person ports QT or GTK and suddenly WASM is just pushing 60 PNG frames a second into a canvas.
- tyingq 9y ago
  It may get there eventually, but currently, having to pass the JavaScript/wasm chasm for DOM manipulation is really slow. https://github.com/rust-webplatform/rust-webplatform/issues/20 https://github.com/rust-webplatform/rust-webplatform/issues/...
  - paulddraper 9y ago
    But canvas is faster.
    - orange8 9y ago
      Canvas is part of the DOM. It is a DOM element that JS can draw graphics on.
      - abecedarius 9y ago
        Not a problem: you can ask the canvas for an arraybuffer to draw on, and pass that to the wasm code. I did this with asm.js in place of wasm (which didn't exist yet) in http://wry.me/hacking/Turing-Drawings/ http://wry.me/hacking/Turing-Drawings/ and you can judge the speed yourself. (As that page describes, there was some overhead from calling from JS to asm.js at least when asm.js first came out. I don't know the current figures.)
        orange8 9y ago
        asm.js is valid Javascript. It is a valid subset of js that the browser js engines understand, even for the older ones like IE 8. JavaScript has direct access to the DOM, with webassembly, not yet. It may in the future, its still in the proposal phrase (https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...) So the way to do it today would be WebAssembly -> asm.js/js -> canvas
        abecedarius 9y ago
        Good point about the proposal -- that'll be the answer in the end. asmj.js as JS is irrelevant to the point I was making, because if you access the DOM directly, your code won't verify as the asm.js subset, and so won't run via the asm.js engine.
        orange8 9y ago
        The asm.js engine is the javascript engine. asm.js is javascript. asm.js === javscript
        abecedarius 9y ago
        No: that's a choice that Chrome made and Firefox didn't, for example.
      - deleted 9y ago
        [deleted]
- aeleos 9y ago
  https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Your comment immediately made me think of this. Highly recommended talk for anyone that hasn't seen it. It goes through a "fictional" (maybe not so much anymore) history of javascript until 2035. We are getting pretty close to javascript all the way down.
- pjmlp 9y ago
  I am betting WASM will be the revenge of plugins. And then, just like the ad spams using JS, its advocates will be getting more than they asked for. Get ready for WASM blockers.
  - flukus 9y ago
    But management won't pay to redevelop the whole site, so they'll just embed the content in a QtWebKit widget. We can still block ads at the network level.
    - pjmlp 9y ago
      Sure they will. Instead of "why I moved from Angular/React/.... to Vue.js", it will be "why I ported into WASM".
  - slackingoff2017 9y ago
    WASM is going to kill spidering. We can't leave HTML if we want google to be able to read the page. I think Google is very afraid of this. Hence their push for Angular/Polymer/AMP. If they can build a good enough platform in JS they can stall the inevitable. In the future only marketing parts of the site will use JS/HTML. The "web app" part will be some language compiled to WASM throwing frames to the canvas
    - smrq 9y ago
      In a world where SEO consultants exist, you foresee an inevitable future where Google is killed by a massive wave of companies rewriting their websites to be un-Googleable?
      - slackingoff2017 9y ago
        The big players are increasingly doing it already. LinkedIn and Facebook only have very limited spidering. What Google has liked to do recently is take all your data and replace your service. Search for recipes, jobs, music, or weather for examples. They're trying to make leaving the homepage irrelevant by using sites data in their search results. Eventually the web will rebel.
trgv 9y ago
> From what I understand, calling WebAssembly functions from JavaScript (and vice-versa) incur a runtime penalty that's way worse than calling JavaScript functions from JavaScript. Can you provide a source for this? I've never heard it and, though it may be correct, this would make wasm much less useful to me. I have heard that accessing the DOM from wasm will be quite expensive, but that's different from just calling a function.
- gsnedders 9y ago
  I've not been that involved with WASM (I've been more or less out of the JS game since around the time asm.js became a thing), but AFAIK the only thing notable is JS -> WASM is more expensive than WASM -> WASM (but should be no worse than JS -> JS); WASM -> JS should be the same as JS -> JS.
  - Matthias247 9y ago
    One thing is pure call performance (time to invoke a void() function). I don't know where that is, but I guess for WASM<->JS it's slower than WASM<->WASM and JS<->JS, since it can't be inlined. The more important thing however is the cost of parameter passing. Let's keep in mind that WASM only support numeric types and typed arrays. So in order to make a function call from JS to WASM or the other way around which passes a string as a parameter the string needs to be converted into a format that the other side understands (Javascript string object <-> WASM typed array which contains string in UTFx format). So basically for all more complex data types crossing the boundary costs the [de]serialization of the parameters, which may be huge (and even causes allocations). If you also only work with integers and typed arrays on the JS side that does not apply. But I guess most people won't be comfortable with that.
    - gsnedders 9y ago
      > One thing is pure call performance (time to invoke a void() function). I don't know where that is, but I guess for WASM<->JS it's slower than WASM<->WASM and JS<->JS, since it can't be inlined. …why can't it be inlined? There's no good reason why it can't be inlined.

forgotpw1123 9y ago

... Until the first person ports QT or GTK and suddenly WASM is just pushing 60 PNG frames a second into a canvas.

tyingq 9y ago
It may get there eventually, but currently, having to pass the JavaScript/wasm chasm for DOM manipulation is really slow. https://github.com/rust-webplatform/rust-webplatform/issues/20 https://github.com/rust-webplatform/rust-webplatform/issues/...
- paulddraper 9y ago
  But canvas is faster.
  - orange8 9y ago
    Canvas is part of the DOM. It is a DOM element that JS can draw graphics on.
    - abecedarius 9y ago
      Not a problem: you can ask the canvas for an arraybuffer to draw on, and pass that to the wasm code. I did this with asm.js in place of wasm (which didn't exist yet) in http://wry.me/hacking/Turing-Drawings/ http://wry.me/hacking/Turing-Drawings/ and you can judge the speed yourself. (As that page describes, there was some overhead from calling from JS to asm.js at least when asm.js first came out. I don't know the current figures.)
      - orange8 9y ago
        asm.js is valid Javascript. It is a valid subset of js that the browser js engines understand, even for the older ones like IE 8. JavaScript has direct access to the DOM, with webassembly, not yet. It may in the future, its still in the proposal phrase (https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...) So the way to do it today would be WebAssembly -> asm.js/js -> canvas
        abecedarius 9y ago
        Good point about the proposal -- that'll be the answer in the end. asmj.js as JS is irrelevant to the point I was making, because if you access the DOM directly, your code won't verify as the asm.js subset, and so won't run via the asm.js engine.
        orange8 9y ago
        The asm.js engine is the javascript engine. asm.js is javascript. asm.js === javscript
        abecedarius 9y ago
        No: that's a choice that Chrome made and Firefox didn't, for example.
    - deleted 9y ago
      [deleted]
aeleos 9y ago
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Your comment immediately made me think of this. Highly recommended talk for anyone that hasn't seen it. It goes through a "fictional" (maybe not so much anymore) history of javascript until 2035. We are getting pretty close to javascript all the way down.
pjmlp 9y ago
I am betting WASM will be the revenge of plugins. And then, just like the ad spams using JS, its advocates will be getting more than they asked for. Get ready for WASM blockers.
- flukus 9y ago
  But management won't pay to redevelop the whole site, so they'll just embed the content in a QtWebKit widget. We can still block ads at the network level.
  - pjmlp 9y ago
    Sure they will. Instead of "why I moved from Angular/React/.... to Vue.js", it will be "why I ported into WASM".
- slackingoff2017 9y ago
  WASM is going to kill spidering. We can't leave HTML if we want google to be able to read the page. I think Google is very afraid of this. Hence their push for Angular/Polymer/AMP. If they can build a good enough platform in JS they can stall the inevitable. In the future only marketing parts of the site will use JS/HTML. The "web app" part will be some language compiled to WASM throwing frames to the canvas
  - smrq 9y ago
    In a world where SEO consultants exist, you foresee an inevitable future where Google is killed by a massive wave of companies rewriting their websites to be un-Googleable?
    - slackingoff2017 9y ago
      The big players are increasingly doing it already. LinkedIn and Facebook only have very limited spidering. What Google has liked to do recently is take all your data and replace your service. Search for recipes, jobs, music, or weather for examples. They're trying to make leaving the homepage irrelevant by using sites data in their search results. Eventually the web will rebel.

trgv 9y ago

> From what I understand, calling WebAssembly functions from JavaScript (and vice-versa) incur a runtime penalty that's way worse than calling JavaScript functions from JavaScript. Can you provide a source for this? I've never heard it and, though it may be correct, this would make wasm much less useful to me. I have heard that accessing the DOM from wasm will be quite expensive, but that's different from just calling a function.

gsnedders 9y ago
I've not been that involved with WASM (I've been more or less out of the JS game since around the time asm.js became a thing), but AFAIK the only thing notable is JS -> WASM is more expensive than WASM -> WASM (but should be no worse than JS -> JS); WASM -> JS should be the same as JS -> JS.
- Matthias247 9y ago
  One thing is pure call performance (time to invoke a void() function). I don't know where that is, but I guess for WASM<->JS it's slower than WASM<->WASM and JS<->JS, since it can't be inlined. The more important thing however is the cost of parameter passing. Let's keep in mind that WASM only support numeric types and typed arrays. So in order to make a function call from JS to WASM or the other way around which passes a string as a parameter the string needs to be converted into a format that the other side understands (Javascript string object <-> WASM typed array which contains string in UTFx format). So basically for all more complex data types crossing the boundary costs the [de]serialization of the parameters, which may be huge (and even causes allocations). If you also only work with integers and typed arrays on the JS side that does not apply. But I guess most people won't be comfortable with that.
  - gsnedders 9y ago
    > One thing is pure call performance (time to invoke a void() function). I don't know where that is, but I guess for WASM<->JS it's slower than WASM<->WASM and JS<->JS, since it can't be inlined. …why can't it be inlined? There's no good reason why it can't be inlined.