Hacker News Reader

Comment by colanderman | Hacker News Reader

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.

View on HN

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.

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

The author is replying to a comparison often made.

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/CanvasRende...

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.

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/

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.

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.

What Flash-based CAD have you seen? AutoCAD and Sketchup web versions are both using WASM. Onshape and Tinkercad use JS.

Sorry, bad example. I have hazy memories of full-screen "creator" type apps in Flash from years ago. You are right that they are all JavaScript or WASM now (owing no doubt to the performance enhancements V8 has brought).

I worked on a 3d web based modeling app in my last job (Autodesk) that was based on asm.js. (and this was a legit solid modeler with heavy CPU usage - not a toy). It was basically 50% speed compared to the desktop version, which isn't ideal but totally viable. WASM is definitely welcome but you could do the same things in 2015 with asm.js. Honestly I think the biggest selling point is decreased download size. That was our big pain point with asm.js

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.

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

"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.

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.

There would be no need for WASM in that case. JS and WebGL works just fine for 99% of cases.

Yup. Maybe some more use cases will emerge that Js and WebGl can't hit as effectively.

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.

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

WASM doesn't change that.

/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.

What capabilities do you see WASM adding over asm.js, beside speed and ease of integration (e.g. built-in linking and parsing)?

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.

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.

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!

Today, there's no difference. In the future, there may be: threading and SIMD are two examples.

JavaScript already has multithreading (Web Workers), and Flash never had SIMD support. (At least, a Google search of the latter turns up nothing.)

I was making the comparison between wasm and JS. Web workers is a browser platform feature, not a JavaScript feature. Not all JS runs in a browser.

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.

There's plenty of slow JavaScript-only pages out there ...

Reply on news.ycombinator.com