Hacker News Reader

Comment by frik | Hacker News Reader

We will quickly find out that while WebAssembly might sound like a next step is a bad thing to happen to the web - ads will be binary blobs that consume 100% CPU and adblockers won't work and cannot be implemented without wasting even more CPU. Beside that the web will get more and more closed down - sound like something that Bill Gates had originally in mind in 1994/95 with pay-per-view Win32 based TheMicrosoftNetwork that never took off, because of the free WWW with ads skyrocketed.

Edit: Re "Anything wasm can do, JavaScript can do." ASM.js was one thing and ok, wasm is the real concern. What about the "binary blobs" do you not understand. The usual downvoters who have vast interest in succeeding of this questionable tech.

View on HN

It's not that difficult to use 100% CPU with JS now you know. And Chrome has already taken steps to limiting CPU usage, for power saving reasons. You can implement adblocking similarly to how it's handled now, on a per-domain basis.

Edit: As browser sandboxes get better, running "binary blobs" gets less and less risky. We're a long way from "curl file | bash".

Anything wasm can do, JavaScript can do. And vice versa. Just wasm is faster.

I don't think that's right. For example wasm can't do DOM manipulation, although it might be added in the future. But as the article mentions, wasm will be getting even more different, as things like SIMD get added to wasm while SIMD.js has been abandoned.

I don't understand how would webassembly be worse than the way it is now.

Take a real webapp. Say something like Google Docs. Can you read it and understand it? What about gmail? Or Facebook?

Practically, they're a binary blob running on your computer. Not only that, but they could be hiding malware, and even if you viewed source you wouldn't be able to tell it's there.

Now maybe if JS was meant to be slow, and if there was no such thing as AJAX, and there would be no way for JS to send/receive data from the server (say, by modifying a GIF url), then I could see a complaint that a browser shouldn't run arbitrary downloaded code on your computer without opt-in. But that ship sailed over a decade ago.

I've never really thought this argument was a good one. "Hey, we've got a pretty terrible system in place, so instead of fixing it, or replacing it with something better, lets just give up and replace it with something worse!"

I think WASM can and will bring a lot of cool stuff to the web, just like JS did. What worries me is that we learned virtually nothing from the mistakes that we made with JS.

> What worries me is that we learned virtually nothing from the mistakes that we made with JS.

Just out of curiosity, what did you learn from JS's mistakes? What would you like to see happen in place of WASM?

This is quick and dirty, but...

Giving a lot of power to the server is a bad idea. Users should be able to audit, control and modify how the data is processed in a very granular way. Strong artificial limiters on how many resources something can use. Basically, it should be a fully tunable VM for each process. Readable and modifiable by the end-user, without a lot of hoops to jump through.

tl;dr: the more power that the end-user has over the code, the better.

Ah, I see. I even mostly agree with you.

But it seems unlikely things will go that way. People are motivated by what they can make webapps do, and will take the quickest way to get there. Doing it right, where the end user has the most control, is more work to design and implement, so people won't bother.

Agreed, which is why we need to severely limit what the servers can do with the clients. The security and usability fallout from this is going to be terrible, and it pains me to see the internet I love head this direction just to make a couple bucks.

The lesson I learned from JS is that you don't (or at least try not to) hardcode a language as a scripting solution. Especially a not-so-fast one as JS (yes, it's been worked on like crazy over the past decades, but writing fast scripts requires black magic (intimate knowledge of runtime), decades of work by the V8 team and hundreds of engineers)

> What about the "binary blobs" do you not understand.

I don't understand the assumption that minified and obfuscated javascript is easier to reverse-engineer than compiled wasm is. This is simply untrue. In both cases the user is, in general, running a closed source (in the GNU sense of "the preferred format for code modification") system that doesn't have their best interests in mind.

Adblockers are much the same war as antivirus was: you want to run untrusted code but still have some say over which computation it performs. Unlike with antivirus, sandboxing and isolation don't help. We're just going to be writing heuristics to strip ads forever (or until we standardize on a non-executable document format, e.g. html-without-scripts).

I agree that this will be terrible. We really need to put more tools in the hands of the users, not the developers. Instead of adding more and more closed off technology, we should be pushing to take away the tools that are currently being abused.

Unfortunately, doing the right thing isn't as profitable, so we've collectively chosen to fuck the users instead.

WebASM doesn’t have direct DOM access so I don’t see how ad blockers would work any differently than they do now.

Yes. And why? So some bro could be a "founder" of a project to get a promotion. Fly around on expenses holding meetings and act all important. I've been in the room. The pseudo-PC bro-ness is nauseating.

How did we get here? Please don't post off-topic inflammation.

No bitterness there, nope.

Reply on news.ycombinator.com