9 ms·

I'm far from an expert, but isn't this what WebAssembly gives them? My understanding is that webassembly is a binary file that is an opaque binary. Why not have

I'm far from an expert, but isn't this what WebAssembly gives them? My understanding is that webassembly is a binary file that is an opaque binary. Why not have webassembly build out the entire page dynamically?

folkrav 7y ago
WASM doesn't have DOM access (yet).
- irrational 7y ago
  That is interesting. I didn't realize WASM was designed to be so constrained.
- EvanAnderson 7y ago
  WASM doesn't need DOM access. You can just implement a browser in WASM and target canvas. I'm really surprised somebody hasn't done this already and marketed it as an unblockable ad delivery platform.
  - Faark 7y ago
    How many accessibility laws does this violate? Does it work with a screen reader?
    - EvanAnderson 7y ago
      You can be certain that, when this does happen, these considerations will be dealt with. I feel very strongly that this is going to happen. The chance to execute arbitrary code on clients will be too alluring for adtech companies to ignore.
      - folkrav 7y ago
        "Dealing with it" basically means re-building a browser rendering engine inside the browser renderer.
        naniwaduni 7y ago
        You don't need to build a browser rendering engine, with everything that entails; you only need to render your content. This is a much easier problem.
        folkrav 7y ago
        For accessibility compliance, you _need_ text and a DOM. Screen readers rely on HTML element semantics, ARIA attributes, and text content. The only way to make a canvas element (which is what you'd typically need to render custom UI) accessible is to have a textual fallback. Outside accessibility there's also the issue of responsive design, huge SEO impacts, rendering performance... I'm probably missing a bunch. Lifting a sedan with my bare hands is obviously easier than lifting a 10 wheeler, but it's still a massive problem. Rendering stuff is not the biggest issue.
        EvanAnderson 7y ago
        Embed a browser with all that stuff into a page. Whatever APIs are missing to make the "inner browser" unable to fulfill all the requirements that the "outer browser" will eventually be filled-in by well-meaning developers who want the Javascript VM in the "outer browser" to be able to host general purpose applications.
  - irrational 7y ago
    How big of a WASM binary would that be? Can we block WASM binaries that are over a certain size in the browser?
    - EvanAnderson 7y ago
      You won't be able to block the binary, because the binary will be what renders the content. Your browser is going to act as a VM to run a browser that will display the content. The "inner" browser will be running on your computer, but short of binary reverse engineering, you won't be able to control it.
      - pdkl95 7y ago
        > Your browser is going to act as a VM to run a browser that will display the content. Gary Bernhardt's talk "The Birth & Death of JavaScript"[1] was an ominous portent of a terrifying future. Unfortunately, some people apparently saw it as development roadmap. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - HugoDaniel 7y ago
    those two would be easy blocks: the canvas showing the ad, and the wasm payload for that to happen
    - throwaway2048 7y ago
      Except the content is mixed into the WASM payload...
  - GrayShade 7y ago
    You can already do that in JavaScript, what's the difference? You can even implement a WASM interpreter in JS.
    - EvanAnderson 7y ago
      Functionally, nothing. WASM being a compiler target just lowers the bar (although we've had Emscripten for years). The browser developers are working hard to make it performant, too. Sufficiently obfuscated Javascript is as difficult to reverse engineer as a binary, though.
      - GrayShade 7y ago
        I don't do web, but I imagine there must be some webpack plugins that make an obfuscated mess out of your code, so the barrier to entry must already be quite low. WASM at least is standardized, so there will be a whole ecosystem dedicated to it. Think IDA Pro for WASM. > although we've had Emscripten for years We did. And I didn't see the "asm.js apocalypse" you seem to fear.
        EvanAnderson 7y ago
        I don't "fear" an "asm.js apocalypse". It's just the next step in the arms race between those who would have the Internet be like television, and those who would prefer it not. I'm one of the people who would have rather had the web stay more like Gopher and less like Java, but that's not the predominant opinion. We're going to lose the document-oriented declarative web because the web is financed by advertising. The spice must flow-- the ads must not be allowed to be blocked. WASM is different between Emscripten was always a fun curiosity, and WASM is being "marketed" to developers as "get native app performance in a browser". "Modern" Javascript has been able to deliver this future for a few years now, but it lacked the marketing and tooling to make it mainstream. Flash and Java were attempts to move to that future that didn't pan out. Having IDA Pro for WASM is all well and good, but doing binary reverse engineering on every single website isn't practical. The web, as it has been, was nice. We're not going to get to keep it. I'm unhappy with it, but I'm resigned to it.
kgwxd 7y ago
Can WebAssembly make HTTP request invisible to the browser?
- EvanAnderson 7y ago
  It doesn't need to. Don't think about it as documents being delivered to the browser anymore. Think of it as a binary executing inside the browser. You're not going to have HTTP requests to block, apart from the one that downloads the binary.
  - austincummings 7y ago
    A minified JavaScript bundle is just slightly less obscure than a WebAssembly binary though.
    - EvanAnderson 7y ago
      Absolutely. I'm not railing against WASM. WASM just has better marketing and tooling than straight Javascript. Putting a VM into our browsers, along with sufficient API support to make that VM useful, is what spells the eventual end of the document-based web. I think that future arrived a few years ago and it's just not evenly distributed yet.
      - irrational 7y ago
        >the eventual end of the document-based web That sounds like the worst future possible. I love the fact that I can go to any web page and look at all of the HTML, CSS, JS (even if I need to use a tool to un-obfuscate it). Have you never wondered how someone did something and then looked at their code to find out how they did it? I love being able to use curl and wget to grab a web page. How would that work in a non document-based web? I really think this would be a terrible thing if it actually came to fruition. I truly hope I'm retired or dead before it occurs.
        BlueTemplar 7y ago

folkrav 7y ago

WASM doesn't have DOM access (yet).

irrational 7y ago
That is interesting. I didn't realize WASM was designed to be so constrained.
EvanAnderson 7y ago
WASM doesn't need DOM access. You can just implement a browser in WASM and target canvas. I'm really surprised somebody hasn't done this already and marketed it as an unblockable ad delivery platform.
- Faark 7y ago
  How many accessibility laws does this violate? Does it work with a screen reader?
  - EvanAnderson 7y ago
    You can be certain that, when this does happen, these considerations will be dealt with. I feel very strongly that this is going to happen. The chance to execute arbitrary code on clients will be too alluring for adtech companies to ignore.
    - folkrav 7y ago
      "Dealing with it" basically means re-building a browser rendering engine inside the browser renderer.
      - naniwaduni 7y ago
        You don't need to build a browser rendering engine, with everything that entails; you only need to render your content. This is a much easier problem.
        folkrav 7y ago
        For accessibility compliance, you _need_ text and a DOM. Screen readers rely on HTML element semantics, ARIA attributes, and text content. The only way to make a canvas element (which is what you'd typically need to render custom UI) accessible is to have a textual fallback. Outside accessibility there's also the issue of responsive design, huge SEO impacts, rendering performance... I'm probably missing a bunch. Lifting a sedan with my bare hands is obviously easier than lifting a 10 wheeler, but it's still a massive problem. Rendering stuff is not the biggest issue.
        EvanAnderson 7y ago
        Embed a browser with all that stuff into a page. Whatever APIs are missing to make the "inner browser" unable to fulfill all the requirements that the "outer browser" will eventually be filled-in by well-meaning developers who want the Javascript VM in the "outer browser" to be able to host general purpose applications.
- irrational 7y ago
  How big of a WASM binary would that be? Can we block WASM binaries that are over a certain size in the browser?
  - EvanAnderson 7y ago
    You won't be able to block the binary, because the binary will be what renders the content. Your browser is going to act as a VM to run a browser that will display the content. The "inner" browser will be running on your computer, but short of binary reverse engineering, you won't be able to control it.
    - pdkl95 7y ago
      > Your browser is going to act as a VM to run a browser that will display the content. Gary Bernhardt's talk "The Birth & Death of JavaScript"[1] was an ominous portent of a terrifying future. Unfortunately, some people apparently saw it as development roadmap. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- HugoDaniel 7y ago
  those two would be easy blocks: the canvas showing the ad, and the wasm payload for that to happen
  - throwaway2048 7y ago
    Except the content is mixed into the WASM payload...
- GrayShade 7y ago
  You can already do that in JavaScript, what's the difference? You can even implement a WASM interpreter in JS.
  - EvanAnderson 7y ago
    Functionally, nothing. WASM being a compiler target just lowers the bar (although we've had Emscripten for years). The browser developers are working hard to make it performant, too. Sufficiently obfuscated Javascript is as difficult to reverse engineer as a binary, though.
    - GrayShade 7y ago
      I don't do web, but I imagine there must be some webpack plugins that make an obfuscated mess out of your code, so the barrier to entry must already be quite low. WASM at least is standardized, so there will be a whole ecosystem dedicated to it. Think IDA Pro for WASM. > although we've had Emscripten for years We did. And I didn't see the "asm.js apocalypse" you seem to fear.
      - EvanAnderson 7y ago
        I don't "fear" an "asm.js apocalypse". It's just the next step in the arms race between those who would have the Internet be like television, and those who would prefer it not. I'm one of the people who would have rather had the web stay more like Gopher and less like Java, but that's not the predominant opinion. We're going to lose the document-oriented declarative web because the web is financed by advertising. The spice must flow-- the ads must not be allowed to be blocked. WASM is different between Emscripten was always a fun curiosity, and WASM is being "marketed" to developers as "get native app performance in a browser". "Modern" Javascript has been able to deliver this future for a few years now, but it lacked the marketing and tooling to make it mainstream. Flash and Java were attempts to move to that future that didn't pan out. Having IDA Pro for WASM is all well and good, but doing binary reverse engineering on every single website isn't practical. The web, as it has been, was nice. We're not going to get to keep it. I'm unhappy with it, but I'm resigned to it.

kgwxd 7y ago

Can WebAssembly make HTTP request invisible to the browser?

EvanAnderson 7y ago
It doesn't need to. Don't think about it as documents being delivered to the browser anymore. Think of it as a binary executing inside the browser. You're not going to have HTTP requests to block, apart from the one that downloads the binary.
- austincummings 7y ago
  A minified JavaScript bundle is just slightly less obscure than a WebAssembly binary though.
  - EvanAnderson 7y ago
    Absolutely. I'm not railing against WASM. WASM just has better marketing and tooling than straight Javascript. Putting a VM into our browsers, along with sufficient API support to make that VM useful, is what spells the eventual end of the document-based web. I think that future arrived a few years ago and it's just not evenly distributed yet.
    - irrational 7y ago
      >the eventual end of the document-based web That sounds like the worst future possible. I love the fact that I can go to any web page and look at all of the HTML, CSS, JS (even if I need to use a tool to un-obfuscate it). Have you never wondered how someone did something and then looked at their code to find out how they did it? I love being able to use curl and wget to grab a web page. How would that work in a non document-based web? I really think this would be a terrible thing if it actually came to fruition. I truly hope I'm retired or dead before it occurs.
      - BlueTemplar 7y ago