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

51–60 of 259 posts

Re: Introduction to WebAssembly: why should we care?

#51

Post by TazeTSchnitzel »

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'…

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.

Re: Introduction to WebAssembly: why should we care?

#52

Post by dingo_bat »

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.

If it becomes the norm Google crawler will start running the pages and looking at the content.

Re: Introduction to WebAssembly: why should we care?

#53

Post by baldfat »

pjmlp wrote: post #16
skohan wrote: post #8

Earlier quoted context omitted.

> I long for the days when simple images and text were the norm. The main issue with the web currently is that tools designed for the purpose of displaying simple images and text, plus a little interactivity, are being stretched to realize complex applications. Powerful on-demand applications on the web are a good thing, and it's a good thing that we're finally getting the tools to build them properly.

We already had them, WebAssembly adds little to Flash, Java applets, Oberon Juice, ActiveX, Silverlight, other than a format that makes all browser vendors happy. I can easily imagine that Adobe R&D already has a working WebAssembly prototype for Flash.

> I can easily imagine that Adobe R&D already has a working WebAssembly prototype for Flash.

Actually Haxe and Openfl will probably beat them to the punch since Adobe has pretty much killed flash by 2020.

Re: Introduction to WebAssembly: why should we care?

#54

Post by tzahola »

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.

Yeah, no.

Google is an ad company. They will simply open an API for content providers to push content into their search engine. They don't have to maintain their crawlers, users can't block their ads, and both Google and the content providers get more revenue. It's a win-win situation.

Oh, I forgot the users: they obviously lose! But hey, at least you can write rich applications :^)

Re: Introduction to WebAssembly: why should we care?

#55

Post by tzahola »

c-cube wrote: post #35
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?

Websites will be obfuscated blobs downloaded from a single server.

Re: Introduction to WebAssembly: why should we care?

#56

Post by Figs »

pjmlp wrote: post #39
Figs wrote: post #36

Earlier quoted context omitted.

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

Hmm... How exactly do you know that? I can only think of a handful of full Flash sites I ever used, and of those, I learned of them from word-of-mouth advertising, not through a search engine. (e.g. Homestar Runner). There could have been tons of relevant sites locked up in Flash navigation (back when that was fad) that I never found out about because of their poor SEO -- the world would look the same to me whether they existed or not...

Re: Introduction to WebAssembly: why should we care?

#57

Post by tzahola »

MaxBarraclough wrote: post #6
pjmlp wrote: post #2

I am betting when WebAssembly gets mature all Web sites will look like Flash, just coded on the framework of choice, thus finally making the browser just yet another VM.

In the process, specialised web browsers such as browsers for the blind, will be rendered useless.

WebAudio-based client-side speech synthesizers are the solution! Finally the blind can pay their fair share too by listening to advertisements :^)

Re: Introduction to WebAssembly: why should we care?

#58

Post by TazeTSchnitzel »

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

Re: Introduction to WebAssembly: why should we care?

#59

Post by rekado »

Vinnl wrote: post #49
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'…

This is hardly inherent to Javascript/WebAssembly. Installed applications are binary code, i.e. closed by default unless you explicitly provide source code. The same holds true for web applications, however, for some reason we don't care about it being open source that much anymore...

Admittedly, I'm looking at this situation from within my comfortable bubble of a GNU system in which I only use software for which I have a source-to-binary mapping through GNU Guix.

JavaScript applications are the exception in my environment and they threaten to burst that shiny bubble.

Aside: I really think that the terms "open" and "closed" are imprecise and confusing, which is why I avoid them. With deterministic builds and free software I have a mapping from source to corresponding binary; so while the binary may not be directly editable (or "closed") it still is free software and I could edit the corresponding source to obtain a new binary. In my opinion the problem really is one of practical software freedom, which has never been achieved in a satisfying way for web applications.

Re: Introduction to WebAssembly: why should we care?

#60

Post by tzahola »

Figs wrote: post #31
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.

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,…

Are you suggesting that content providers shouldn't be able to control who can select/copy/save the text on their websites? What are you, a communist?
Post reply on HN