Live data from Hacker News

Introduction to WebAssembly: why should we care?

tomassetti.me

61–70 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#61
post #38

Earlier quoted context omitted.

Why couldn't you do that now with canvas?

You can, theoretically, but it isn't practical because of the large amount of Javascript that would need to be downloaded and parsed. The WebAssembly's purpose is to remove that limitation, which is going to trash what's left of the open web. Get ready for lots of websites becoming un-adblockable, accessibility-hostile, "custom ui" trash.

Needing to download a large amount of JavaScript hasn't been a deterrent to anyone for anything yet. These arguments against WebAssembly are just FUD.

Re: Introduction to WebAssembly: why should we care?

#62
post #19

I am still a bit baffled. I am a TypeScript user and in the article he states: For instance, instead of compiling TypeScript to JavaScript, its developers could now compile to WebAssembly. Alright, so I don't need to be a C/C++ dude to get some WebAssembly goodness (maybe some day). But now with this in my toolbelt. What occurs? What does it mean? If I have a particle simulation in TypeScript on Canvas using Shaders.…

WebAssembly is basically a VM, a JIT'd execution engine. It doesn't know about canvas, DOM etc ... those are library features available on the side, as it were, on a browser. Those libraries will be available to any languages compiling to WebAssembly.

Re: Introduction to WebAssembly: why should we care?

#63
post #27

I'm worried that this will make the JavaScript trap[1] even more of a problem. The default operation of the web is to allow remote sites to push non-free applications to your browser that it then proceeds to execute. As people have been shifting towards running everything in the browser (just like people like me run everything in Emacs), this effectively results in a revival of ubiquitous proprietary software. I don'…

JS on the web wasn't open to begin with. Just because it was sometimes human-readable doesn't make it free , to put it how Stallman would.

This is another case where the "open/closed" image doesn't apply and only contributes confusion. It wasn't free to begin with --- though there are notable cases where that is in fact the case.

There are many JS libraries and full web applications that are in fact software libre. It just isn't really any freedom the users can exercise due to the lack of application interfaces.

If I were in the mood for an argument, I'd argue that with all the ugly SOAP and Java services users had more potential freedom than today.

Re: Introduction to WebAssembly: why should we care?

#64
post #24

Earlier quoted context omitted.

Not true. A good security model is added.

It remains to be tested on the wild. Lets see when the first examples pop up on Project Zero or CCC.

It reuses the existing Javascript security model, which has been tested pretty extensively in the wild.

Re: Introduction to WebAssembly: why should we care?

#65

From the site: The kind of binary format being considered for WebAssembly can be natively decoded much faster than JavaScript can be parsed (experiments show more than 20× faster). On mobile, large compiled codes can easily take 20–40 seconds just to parse, so native decoding (especially when combined with other techniques like streaming for better-than-gzip compression) is critical to providing a good cold-load user…

Gmail takes around 5 seconds to load over a 100mbit connection. Seems to not have posed any problem for them.

Re: Introduction to WebAssembly: why should we care?

#66
post #37
post #27

I'm worried that this will make the JavaScript trap[1] even more of a problem. The default operation of the web is to allow remote sites to push non-free applications to your browser that it then proceeds to execute. As people have been shifting towards running everything in the browser (just like people like me run everything in Emacs), this effectively results in a revival of ubiquitous proprietary software. I don'…

Proprietary software doesn't need any revival, because it never went away. The irony is that proprietary browser based software happens to run on top of FOSS libraries and languages, which most companies hardly contribute anything back.

> Proprietary software doesn't need any revival, because it never went away.

True, though we have reached a point where one could be really comfortable without proprietary software. I certainly am. It's just with an increasingly "appified" web that proprietary software makes again inroads on otherwise free systems.

Re: Introduction to WebAssembly: why should we care?

#67

I feel like a really big point people gloss over when it comes to WebAssembly is browser support. It’ll be years before we can drop JavaScript (not that I want to) because we’ll be waiting for IE and friends to drop of the face of the planet. WebAssembly could act like a catalyst to propel the web forward or segment it even more. I’m leaning more towards the latter, at least for the next 7-10 years or so.

IE is already dead. Everybody non savvy has been force upgraded to windows 10 with edge and the savvy ones don't use IE.

Re: Introduction to WebAssembly: why should we care?

#68
post #38

Earlier quoted context omitted.

You can, theoretically, but it isn't practical because of the large amount of Javascript that would need to be downloaded and parsed. The WebAssembly's purpose is to remove that limitation, which is going to trash what's left of the open web. Get ready for lots of websites becoming un-adblockable, accessibility-hostile, "custom ui" trash.

Needing to download a large amount of JavaScript hasn't been a deterrent to anyone for anything yet. These arguments against WebAssembly are just FUD.

> hasn't been a deterrent to anyone for anything yet

This is patently incorrect. Javascript's impact on page load time is so widespread that Google introduced AMP to "enables the creation of websites and ads that are consistently fast ... and high-performing"[1].

[1] https://www.ampproject.org/

Re: Introduction to WebAssembly: why should we care?

#69
post #29

Remember that WebAssembly means no more ad blockers as soon as someone ports freetype. The behavior of a program written in a Turing complete language cannot be predicted without running the program[1]. Ad-blocking by regexp or DOM element doesn't help when the entire contents of the page - including the ads - is just a bunch of {canvas,WebGL} draw calls generated by a blob of obfuscated code. [1] https://en.wikipedi…

Why is WebAssembly special in this regard? Javascript is also a turing complete language that can just do a bunch of canvas / WebGL draw calls.

Re: Introduction to WebAssembly: why should we care?

#70
post #19

I am still a bit baffled. I am a TypeScript user and in the article he states: For instance, instead of compiling TypeScript to JavaScript, its developers could now compile to WebAssembly. Alright, so I don't need to be a C/C++ dude to get some WebAssembly goodness (maybe some day). But now with this in my toolbelt. What occurs? What does it mean? If I have a particle simulation in TypeScript on Canvas using Shaders.…

You're baffled because the author has no idea what they're talking about. TypeScript is a superset of JS, it makes no sense to compile it to a platform designed for AoT-compiled systems programming languages.

Since TypeScript is a transpiler, couldn't it output a new "MyLittlePony Lang" for example and then WebAssembly from that?
Post reply on HN