Hacker News new | past | comments | ask | show | jobs | submit login

That is a weird, unconvincing post.

His first point about why it's different is "Wasm won"? Really? Back in the day Java applets were everywhere. They had "won". They disappeared because browser makers kicked them out along with Flash, which had also "won". He then tries to redefine plugins, which were created by Netscape, had a standard cross platform API and their own HTML tags as somehow "not a part of the web platform".

Then he says that's "in some senses the final point", as if being forced into the platform by de-facto execution of all competitors says all you need to know about why WebAssembly is good.

But still, he does go on to make other points too. Firstly he picks up on loading screens, presumably claiming WebAssembly doesn't have loading screens. Well, no, the web platform makes you implement your own. But the reason apps like Gmail have loading screens is because it's waiting whilst the browser downloads, parses and initialises megabytes of JavaScript and WASM (maybe, assuming Gmail uses some). To the extent it's faster it's only because hardware is faster, not due to any fundamental difference in technology. Not having a standardised splash doesn't seem like an actual win.

He then goes on to argue:

These platforms never gained the ability to interact with the rest of the platform provided by your browser. Well, technically they might have, but that’s not how these technologies were used in practice.

So he makes a false claim - that applets and flash couldn't interact with the hosting web page - and then immediately admits it's false, but that "this isn't how the tech was used in practice". But I remember quite a few Java and Flash applets that interacted with the host page and changed the HTML, most obviously in things like the original Google Talk. And to the extent Java applets rarely did, that's because HTML sucked in that era. Arguably it still does. The primary reason people were writing Java applets was to escape the woeful inadequacy of the web platform, so no big surprise not many applets rendered their UI using "the benefits of HTML and CSS".

And users ended up solidly rejecting it. Outside of games, users hated Flash. Java Applets were heavy and slow.

Users didn't reject Flash. Flash went everywhere. It was the de-facto video streaming solution, the de-facto cross platform lightweight games solution, it was in every Gmail page, it was the standard way to make attractive animated websites. Site authors adopted it en-masse and users loved those sites, which were often doing things HTML users couldn't even begin to do.

And of course Java applets were "heavy and slow" in an era when the web itself was so heavy and slow, that people didn't even try to do the same things with it. The crime of Java applets was mostly that they raised developer expectations to unreasonable levels and devs ended up blowing their hardware budgets. The web was crippled and limited, so people didn't even try to make sophisticated UIs or modular software, and it ended up staying within the envelope of what slow internet connections could manage more effectively.

WebAssembly, on the other hand, is much closer to JavaScript. It doesn’t inherently require taking over a part of your screen. It doesn’t expect to be its own little closed off world. Via JavaScript today, and on its own in the future, it’s able to interact with the surrounding environment. It just… fits.

Here he's just repeating an argument he already admitted himself is wrong. Flash applets and Java applets could both be invisible and could both "fit" with the surrounding environment. And he already knows that.

I have to admit I stopped reading at this point. WebAssembly is a poor re-implementation of the JVM, 20+ years later, and its primary selling point is that browser makers control it so they are forcing people to use it in the same way they did for JavaScript. The advocates for it know their own comparisons with prior tech are bogus but make them anyway. It's depressing to see.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: