Hacker News Reader

Comment by pdkl95 | Hacker News Reader

The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM. You're comparing it to asm.js, but that isn't particularly relevant as asm.js that widely used (emscripten is cool, but the lack of readability you mentioned is a barrier to wider adoption in the general case).

WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will introduce the Halting Problem in to a lot more areas. The concern isn't asm.js - it's frameworks like angular (no-content-without-js websites are already a problem). The availability of a parse tree doesn't help if I have to run it to access the structure that is current available in the DOM. With the current drama over adblopcking, I expect advertisers will jump at a technology that lets them treat clients as something they control. (compile an obfuscated version of freetype into small WebAssembly download will be be the key features).

View on HN

This is uneducated FUD.

WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to run, it's killed. There's no reason that would be any different with a faster-to-parse and smaller-in-bytesize compilation target, which is all that WASM is.

If "the concern isn't asm.js — it's frameworks like angular," then — what? Angular already exists, and is written in regular JS. No new compilation target needed.

And in regards to ad-blocking: what? Ad-blocking works by not running (or loading) content from specific, known advertising networks. That would work regardless of whether the content was written in WASM or asm.js or regular JS or anything else. Just block the network requests and you're done.

Just block the network requests and you're done.

Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. Host-level blocking still works for ads served from exclusive servers, but a lot of them are starting to realise that it's so easy to block and are resorting to more subtle methods.

That said, a new type of adblocker based on pattern-matching against a JS syntax tree would be pretty useful.

> Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts.

This is true, but it's not problem unique to WASM. In fact, your proposed pattern matching AdBlocker seems like it would be much easier to produce targeting WASM.

It's also worth nothing what an edge case this is. Some sites might do this, but large enough sites to be worth doing this will likely be large enough to inspire site-specific workarounds. Smaller sites will be unlikely to couple their ads to their rendering so tightly.

Maybe they were referring to embedding the advertisers code into the code base itself without network calls? But I still don't see how this is any different than current sites that serve ad content through their own servers.

pdkl95 has brought this up before[1] and again, it looks like everyone is confused by his (mis)understanding of: WebAssembly, The Halting Problem, and the economics+friction of practical advertising delivery (now and in the future.)

I couldn't convince him/her that any future trends towards pre-built ads rendered on server proxies, or seamless "native advertising", is orthogonal to WebAssembly.

[1]https://news.ycombinator.com/item?id=10211050

> The existence of a "readable" parse tree doesn't provide the same level of "hackability" or openness as a DOM.

Um, the DOM will still exist.

WebAssembly is just a new storage format for asm.js, which is just a javascript subset. It doesn't replace the DOM. That still exists just as it does with Javascript! Any openness problems that exist with WebAssembly already exist with minified Javascript.

That's not really the use case for it, the use case for Web Assembly is to take web audio and turn it from being a kind of toy into a platform where an ableton live could be empowered to run in the browser, as well as being able to load native plugins for audio processing and generation. Also say you want to transcode a video file from webm to hls, with web assembly that becomes possible, even with asm.js its really brutally slow to try to do that.

> and I fear it will introduce the Halting Problem in to a lot more areas.

This is the part of your post where I concluded that you were deeply confused and stopped reading. The didactic part of me wants to teach you what the halting problem is, but I'm not even sure what it is you don't know at this point.

Why are you concered that it will "introduce the Halting Problem in to a lot more areas."?

All this is already done with asm.js and emscripten.

Reply on news.ycombinator.com