4 ms·

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

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.

userbinator 11y ago
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.
- iamsohungry 11y ago
  > 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.
tsenior 11y ago
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.
jasode 11y ago
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 https://news.ycombinator.com/item?id=10211050

userbinator 11y ago

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.

iamsohungry 11y ago
> 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.

tsenior 11y ago

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.

jasode 11y ago

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 https://news.ycombinator.com/item?id=10211050