Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to WebAssembly: why should we care?

tomassetti.me

Post reply on HN
Print view View original

31–40 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#31

Post by Figs »

pjmlp wrote: post #11
Longhanks wrote: post #7

Earlier quoted context omitted.

With all major browser JIT compiling JavaScript, aren't they already?

No, because it still is the pile of HTML, CSS and JavaScript hacks. With WebAssembly you can bypass all of it, and do your UI framework in GL, and everything else with native libraries compiled into WebAssembly.

Which is a terrible usability nightmare waiting to happen...

Seriously, DON'T do this. This breaks ctrl-f. This is unlikely to work well for people who need to enlarge text or enhance contrast due to vision impairment. This breaks screen readers. This will probably break most site archive navigators, so your content is lost to history (e.g. wayback machine). This will probably prevent Google from indexing your site, killing your page ranking and driving away potential customers. Even if you re-implement all the things you think it will break, you'll find that your users have things set up in ways you'd never considered...

Just, don't. Please don't do that.

Re: Introduction to WebAssembly: why should we care?

#32

Post by pdkl95 »

osrec wrote: post #5

I know a lot of people long for the days when the web was just text and a few JPGs. I personally am waiting for the web to become a rich, ubiquitous, standardised application delivery platform that works on any device. I think web assembly adds to the richness while being fairly standardised, so I welcome it!

> richness

That includes the problematic features like tracking. Running software from random sources is dangerous in ways we are only beginning to understand.

Re: Introduction to WebAssembly: why should we care?

#33

Post by kiriakasis »

pmlnr wrote: post #15

> In practical terms, WebAssembly is implemented by browsers’ developers on the back of the existing JavaScript engine. Isn't this contrary to the whole idea of wasm? EDIT: this is a completely serious question, I honestly don't understand why this is built into the existing JS engines instead of something separate.

If I understood correctly the main reason was ease of implementation for a MVP.

at this point webassembly run in a sorta VM with a security model added. the fact that wasm and JS share the interpreter should not have (ignoring bugs of the implementation, which is not trivial) a security effect

Re: Introduction to WebAssembly: why should we care?

#34

Post by adriancooney »

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.

Re: Introduction to WebAssembly: why should we care?

#35

Post by c-cube »

pdkl95 wrote: 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…

Currently you can block many ads based on their url (which is from a third party provider). Using umatrix, ad and tracking is often clearly marked in red, and the corresponding js never even loaded. I don't think that would change with webasm?

Re: Introduction to WebAssembly: why should we care?

#36

Post by Figs »

pdkl95 wrote: 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…

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

Your site would also be unreadable by Google, meaning that you'll be heavily penalized in search ranking and no one will find your abomination of a website designed this way.

Re: Introduction to WebAssembly: why should we care?

#37

Post by pjmlp »

rekado wrote: 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.

Re: Introduction to WebAssembly: why should we care?

#38

Post by pdkl95 »

endless1234 wrote: post #26
pjmlp wrote: post #11

Earlier quoted context omitted.

No, because it still is the pile of HTML, CSS and JavaScript hacks. With WebAssembly you can bypass all of it, and do your UI framework in GL, and everything else with native libraries compiled into WebAssembly.

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.

Re: Introduction to WebAssembly: why should we care?

#39

Post by pjmlp »

Figs wrote: post #36
pdkl95 wrote: 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…

> 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. Your site would also be unreadable by Google, meaning that you'll be heavily penalized in search ranking and no one will find your abomination of a website designed this way.

People never had any problem finding Flash and Silverlight websites.

Re: Introduction to WebAssembly: why should we care?

#40

Post by Hasknewbie »

pmlnr wrote: post #15

> In practical terms, WebAssembly is implemented by browsers’ developers on the back of the existing JavaScript engine. Isn't this contrary to the whole idea of wasm? EDIT: this is a completely serious question, I honestly don't understand why this is built into the existing JS engines instead of something separate.

WASM uses the current JS/VM environments to leverage its existing infrastructure (i.e. low-level abstraction and security). In practice it is a pre-optimized bytecode that only relies on JS primitives, so it does not need dynamic typing features or GC, i.e. the slowest and least safe parts of JS. Which means that anything compiled to WASM is "near-native" in terms of performance, making the use of a separate VM unnecessary.
Post reply on HN