5 ms·

Isn't the answer really, "no, because WASM doesn't allow you to do anything you couldn't already do with JavaScript"? I don't think anyone would complain about

Isn't the answer really, "no, because WASM doesn't allow you to do anything you couldn't already do with JavaScript"? I don't think anyone would complain about Applets or Flash if the only way they could interact with the web page was through the DOM. WASM enables nothing. It just makes a particular subset of JavaScript slightly faster. EDIT: I'm not talking about Canvas. That isn't part of WASM.

rsynnott 8y ago
Eh, I'd still complain about them; they tended to be terribly poorly written and do a lot of unnecessary work, slowing things down and using too much power. Of course, so do random javascript things. I kind of miss the days of the HTML/HTTP-only web.
- colanderman 8y ago
  > Of course, so do random javascript things. My point exactly. The author is making the wrong comparison. WASM is JavaScript all over again, and, the HN NoScript crowd aside, that's not going anywhere soon.
  - icebraining 8y ago
    The author is replying to a comparison often made.
    - colanderman 8y ago
      To which the answer should be, "no, but Canvas might have, and here's why it didn't". Actually, that would be an interesting article to me, because in retrospective, I'm surprised we haven't seen more Flash-like Canvas-based sites. My suspicion is that Canvas's interactivity story isn't yet strong enough: you kind of have to roll-your-own interactivity, pending technologies such as addHitRegion() et al. [1]; most notably there's no support whatsoever for text-based interaction (e.g. text widgets). Hence why most web apps which would have been Flash a decade ago still stick to HTML instead of Canvas. [1] https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/addHitRegion https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...
neilsimp1 8y ago
I'd still complain. I remember supporting a Java plugin application that was incredibly slow and beyond buggy. Then again, limiting the scope to only what JavaScript could already do could have helped avoid those issues to begin with.
- rusk 8y ago
  There's plenty of slow JavaScript-only pages out there ...
AnIdiotOnTheNet 8y ago
That's only because you didn't have canvas in the 90s.
- colanderman 8y ago
  WASM doesn't change that.
nabla9 8y ago
Flash was basically JavaScript that was was easily portable between browsers and allowed faster multimedia applications. In that sense the combination of WebAssemply + WebGL and others improvements is exactly like the return of Java Applets and Flash. Is the end result from the user perspective the same? I don't know. I'm just little worried that it might be.
- colanderman 8y ago
  The article isn't about WebGL, it's about WASM. WASM doesn't make anything new possible, it just makes already-possible things faster. (WASM is quite literally designed as a faster replacement of pure-JavaScript asm.js.)
- untog 8y ago
  "and other improvements" is doing a lot of work there. Flash had an entire scripting language and an API for drawing/creating UI elements, listening to their events, etc. Raw WebGL isn't going to give you any of that. And listening for any interaction events at all is going to necessitate the DOM. I don't doubt WASM will end up with something similar, but it's also something that's possible with JS today, there are a bunch of JS game engines that render to WebGL and perform very well.
  - j45 8y ago
    Yet. But maybe sometime will release something. Actionscript on flash is based on ECMAscript, it didn't seem too far fetched to think the combination of js + wasm can solve some problems.
    - untog 8y ago
      There would be no need for WASM in that case. JS and WebGL works just fine for 99% of cases.
      - j45 8y ago
        Yup. Maybe some more use cases will emerge that Js and WebGl can't hit as effectively.
readittwice 8y ago
Not sure if I agree. I would still say that WASM enables new types of applications. Of course you could have compiled all that new WASM applications to asm.js or even JS as well. But it would've been slower: maybe even unusable slow. That's why I think WASM enables new types of applications. It's the same as in the past where faster JS engines enabled richer web applications like GMail, etc. Now we get games in the browser and large native applications like AutoCAD.
- colanderman 8y ago
  I don't doubt the claim that a Java Applet can be faster than JavaScript, but I haven't ever seen a modern high-performance web application written as a Java Applet. The CAD stuff, games, etc., are always Flash (EDIT: when they aren't JavaScript). So the comparison is really Flash vs. JavaScript. And… comparing Flash to V8? I'm having trouble finding modern benchmarks, but Flash is based on ActionScript, which is related to JavaScript. JavaScript has V8, which is a world-class JIT with Google's engineering talent behind it. I'd be very surprised if Flash's JIT was competitive with V8. At least as of 2011 it wasn't [1]. [1] https://habr.com/post/121997/ https://habr.com/post/121997/
  - deleted 8y ago
    [deleted]
  - readittwice 8y ago
    My answer was in reply to "WASM enables nothing". I argue that WASM is faster than JS, therefore it enables new applications. I didn't make any claims about Java Applets or Flash performance.
    - colanderman 8y ago
      Ah sorry I thought you were replying to "no-one would complain about Flash or Java Applets". I don't disagree that WASM is faster than JS; in fact I make that point myself in several comments. My point is that WASM's speed does not enable it to be abused like Flash in a way that JavaScript cannot be, because JavaScript is already as fast as (in fact faster than) Flash thanks to modern JITs like V8. The reasons that WASM is not the "new Flash" must therefore be the same reasons that V8 + Canvas are not.
nailer 8y ago
/asm.js/ doesn't allow you to do anything you couldn't already do with JavaScript Web assembly does, as far as I understand it.
- colanderman 8y ago
  What capabilities do you see WASM adding over asm.js, beside speed and ease of integration (e.g. built-in linking and parsing)?
  - nailer 8y ago
    I honestly don't know. I follow Brenden Eich and a bunch of smarter people on Twitter who could answer that better than I can.
    - colanderman 8y ago
      I've read the entire WASM spec and implemented a WASM loader and linter. It doesn't do anything that JS can't do on its own. It's just a slightly faster asm.js, in a way which is irrelevant to any comparison between JS and Flash, since JS in V8 is already far faster than AS in Flash ever was.
      - nailer 8y ago
        What I've been told by the WASM folks is that WASM won over asm.js because WASM allows you to do things that weren't possible in asm.js. I'm not a low level programmer - my WASM usage comes from Unreal Engine development - hence recommending you seek more knowledgable advice!
  - steveklabnik 8y ago
    Today, there's no difference. In the future, there may be: threading and SIMD are two examples.
    - colanderman 8y ago
skohan 8y ago
IMO the prospect of less of my bandwidth, memory and CPU cycles being waisted is a pretty big deal. It's silly how much overhead there is with standard web technologies given the fact that it's how most people spend most of their time on their computer.

rsynnott 8y ago

Eh, I'd still complain about them; they tended to be terribly poorly written and do a lot of unnecessary work, slowing things down and using too much power. Of course, so do random javascript things. I kind of miss the days of the HTML/HTTP-only web.

colanderman 8y ago
> Of course, so do random javascript things. My point exactly. The author is making the wrong comparison. WASM is JavaScript all over again, and, the HN NoScript crowd aside, that's not going anywhere soon.
- icebraining 8y ago
  The author is replying to a comparison often made.
  - colanderman 8y ago
    To which the answer should be, "no, but Canvas might have, and here's why it didn't". Actually, that would be an interesting article to me, because in retrospective, I'm surprised we haven't seen more Flash-like Canvas-based sites. My suspicion is that Canvas's interactivity story isn't yet strong enough: you kind of have to roll-your-own interactivity, pending technologies such as addHitRegion() et al. [1]; most notably there's no support whatsoever for text-based interaction (e.g. text widgets). Hence why most web apps which would have been Flash a decade ago still stick to HTML instead of Canvas. [1] https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/addHitRegion https://developer.mozilla.org/en-US/docs/Web/API/CanvasRende...

neilsimp1 8y ago

I'd still complain. I remember supporting a Java plugin application that was incredibly slow and beyond buggy. Then again, limiting the scope to only what JavaScript could already do could have helped avoid those issues to begin with.

rusk 8y ago
There's plenty of slow JavaScript-only pages out there ...

AnIdiotOnTheNet 8y ago

That's only because you didn't have canvas in the 90s.

colanderman 8y ago
WASM doesn't change that.

nabla9 8y ago

Flash was basically JavaScript that was was easily portable between browsers and allowed faster multimedia applications. In that sense the combination of WebAssemply + WebGL and others improvements is exactly like the return of Java Applets and Flash. Is the end result from the user perspective the same? I don't know. I'm just little worried that it might be.

colanderman 8y ago
The article isn't about WebGL, it's about WASM. WASM doesn't make anything new possible, it just makes already-possible things faster. (WASM is quite literally designed as a faster replacement of pure-JavaScript asm.js.)
untog 8y ago
"and other improvements" is doing a lot of work there. Flash had an entire scripting language and an API for drawing/creating UI elements, listening to their events, etc. Raw WebGL isn't going to give you any of that. And listening for any interaction events at all is going to necessitate the DOM. I don't doubt WASM will end up with something similar, but it's also something that's possible with JS today, there are a bunch of JS game engines that render to WebGL and perform very well.
- j45 8y ago
  Yet. But maybe sometime will release something. Actionscript on flash is based on ECMAscript, it didn't seem too far fetched to think the combination of js + wasm can solve some problems.
  - untog 8y ago
    There would be no need for WASM in that case. JS and WebGL works just fine for 99% of cases.
    - j45 8y ago
      Yup. Maybe some more use cases will emerge that Js and WebGl can't hit as effectively.

readittwice 8y ago

Not sure if I agree. I would still say that WASM enables new types of applications. Of course you could have compiled all that new WASM applications to asm.js or even JS as well. But it would've been slower: maybe even unusable slow. That's why I think WASM enables new types of applications. It's the same as in the past where faster JS engines enabled richer web applications like GMail, etc. Now we get games in the browser and large native applications like AutoCAD.

colanderman 8y ago
I don't doubt the claim that a Java Applet can be faster than JavaScript, but I haven't ever seen a modern high-performance web application written as a Java Applet. The CAD stuff, games, etc., are always Flash (EDIT: when they aren't JavaScript). So the comparison is really Flash vs. JavaScript. And… comparing Flash to V8? I'm having trouble finding modern benchmarks, but Flash is based on ActionScript, which is related to JavaScript. JavaScript has V8, which is a world-class JIT with Google's engineering talent behind it. I'd be very surprised if Flash's JIT was competitive with V8. At least as of 2011 it wasn't [1]. [1] https://habr.com/post/121997/ https://habr.com/post/121997/
- deleted 8y ago
  [deleted]
- readittwice 8y ago
  My answer was in reply to "WASM enables nothing". I argue that WASM is faster than JS, therefore it enables new applications. I didn't make any claims about Java Applets or Flash performance.
  - colanderman 8y ago
    Ah sorry I thought you were replying to "no-one would complain about Flash or Java Applets". I don't disagree that WASM is faster than JS; in fact I make that point myself in several comments. My point is that WASM's speed does not enable it to be abused like Flash in a way that JavaScript cannot be, because JavaScript is already as fast as (in fact faster than) Flash thanks to modern JITs like V8. The reasons that WASM is not the "new Flash" must therefore be the same reasons that V8 + Canvas are not.

nailer 8y ago

/asm.js/ doesn't allow you to do anything you couldn't already do with JavaScript Web assembly does, as far as I understand it.

colanderman 8y ago
What capabilities do you see WASM adding over asm.js, beside speed and ease of integration (e.g. built-in linking and parsing)?
- nailer 8y ago
  I honestly don't know. I follow Brenden Eich and a bunch of smarter people on Twitter who could answer that better than I can.
  - colanderman 8y ago
    I've read the entire WASM spec and implemented a WASM loader and linter. It doesn't do anything that JS can't do on its own. It's just a slightly faster asm.js, in a way which is irrelevant to any comparison between JS and Flash, since JS in V8 is already far faster than AS in Flash ever was.
    - nailer 8y ago
      What I've been told by the WASM folks is that WASM won over asm.js because WASM allows you to do things that weren't possible in asm.js. I'm not a low level programmer - my WASM usage comes from Unreal Engine development - hence recommending you seek more knowledgable advice!
- steveklabnik 8y ago
  Today, there's no difference. In the future, there may be: threading and SIMD are two examples.
  - colanderman 8y ago

skohan 8y ago

IMO the prospect of less of my bandwidth, memory and CPU cycles being waisted is a pretty big deal. It's silly how much overhead there is with standard web technologies given the fact that it's how most people spend most of their time on their computer.