4 ms·

Am I being paranoid to think this is going to be heavily used to introduce proprietary and locked down protocols and content? How long is it until this is used

by tux1968 9y ago

Am I being paranoid to think this is going to be heavily used to introduce proprietary and locked down protocols and content? How long is it until this is used to render web content onto a canvas without using individual DOM elements that can be stripped by ad blockers etc. We're all focused on the potential performance rather than what this will actually be used to deliver -- so maybe i'm just missing what prevents this technology from subverting the open web.

api 9y ago
This is already possible using emscripten without too much effort. Emscripten JS is basically binary code. It's also been possible with Flash for over a decade, though fewer and fewer people have that installed.
klodolph 9y ago
"The open web" is a platform where everyone can publish and access content because the standards are open. WebAssembly makes the web more open because it puts nails in the coffin of Flash, Unity Player, and the like. Back in the day we had Flash-only web sites. They died off because it turns out that it's easier to just throw HTML, CSS, and JS at people, and since these were open standards, there was a fair bit of competition between different vendors to make better tools for consumption, authoring, and delivery. If you want to reimplement that experience in WebAssembly, the ROI is going to be horrible and if you render everything to a canvas your site won't be indexable by Google (goodbye traffic) or workable with screen readers (hello lawsuits).
- wruza 9y ago
  Are lawsuits like that a real thing in EU? We’re considering to make ui, at least hard part of it, in a canvas for new web-based projects. Of course, there is no intention to discriminate people with sight issues. I think we could provide different/better interface to cover this area. Besides that, are modern sites actually accessible in that regard?
  - klodolph 9y ago
    No idea about the EU, but lawsuits under the ADA (Americans With Disabilities Act) are real in the US. And yes, modern sites really are accessible. Screen readers traverse the DOM looking for the semantic information that's already there. Look at WCAG (https://www.w3.org/TR/WCAG/ https://www.w3.org/TR/WCAG/), you'll see how easy it is to follow the guidelines. Unless, of course, you stick a bunch of stuff in a <canvas>...
    - spectredev 9y ago
      The ADA hasn't held up to digital, see Access Now v. Southwest Airlines
      - wruza 9y ago
        Thank you, this example really makes some important details clear.
- alexasmyths 9y ago
  "WebAssembly makes the web more open because it puts nails in the coffin of Flash, Unity Player, and the like." In practice, it does not. It's too low level, and the APIs to access browser features are not available, so you have to go through seriously ugly APIs and just do it in JS anyhow. So if you have to go to JS to do pretty much everything, why are we using WASM again? Performance? Is performance the issue? Because if it is, isn't there maybe better ways of solving that problem? It's certainly not for portability, we already have that. To make 'web development available to C coders' ... Not sure that's it since they will invariably have to know web browsers anyhow ... WASM is a great idea that won't gather steam until there are direct APIS. Which is on the roadmap I think. I'd suggest just trying to build a simple WA, or even trying to make a simple app out of WA. Things look different then. It's a nice dream to have, we're still a ways off.
  - klodolph 9y ago
    This is a straw man argument. WASM is obviously not a compelling alternative to JS. There are few people crazy enough to write web apps in C. Is that the "nice dream to have"? However, I can think of two very compelling use cases for WASM. As an addition to JS, it gives JS programmers access to a wealth of libraries and programs written in other languages. Codecs and compression algorithms, linear algebra libraries, image and audio processing, and a million other things have good libraries that just don't happen to be written in JavaScript. Adding a WASM blob as a library you can call from JS is a huge success. Suddenly you can do tons of client-side processing that was too prohibitive before (from an engineering cost standpoint). As an alternative to Flash and Unity Player, you can write games for the web using WASM without having to deal with JavaScript. Having used WASM personally, I can say with conviction that it is a compelling addition to the open web.
    - alexasmyths 9y ago
      "lash and Unity Player, you can write games for the web using WASM without having to deal with JavaScript." No, you have to go through a seriously crazy api wherein data is passed into a single managed array in wasm, and pulled off in JS and visa versa. Ok - so accessing C libs is useful? Are bindings from other languages to C considered to be really an important things for those languages? Was there a specific set of libs that we were angling for? Does it even make sense to do those things in the browser? And what about the limitations - i.e. having to pass data into and out of the WASM container - does that play well with usage of 'codecs'? Maybe not. So why again does WASM exist? What as the compelling use case? Flash/UX is definitely not it. I don't see any real uses cases for things like codes, nor was I seeing demand. So where is the market/product need? And use case? This is cool tech that's a long way off from being useful in the real world. Having gone through the pain of writing my own little app, I realized that it's still fairly bleeding edge. I will go back to it when there are deeper APIs between JS and C, are the toolchain is more stable.
- Someone 9y ago
  I see that change as soon as DOM bindings for WebAssembly are available. Apple/Google/Microsoft would be stupid if they weren’t already working on a Swift/Kotlin/C# to WebAssembly compiler, as each of them would give them for their preferred language what JavaScript now has: the ability for developers to work in a single language, and move code between browser and backend at will. Long-term, JavaScript is dead.
  - icebraining 9y ago
    That already happens, since you can already write compilers that target JS: Google wrote GWT and Dart. Microsoft seems to have gone the other way, pulling JS into native apps.
    - Someone 9y ago
      That is true, but it still is on JavaScript’s turf. With WebAssembly the JavaScript will be as ‘native’ as any other language. I think the psychological difference matters.
tqkxzugoaupvwqr 9y ago
Gives me nightmares. But today it’s already possible and I haven’t seen this yet. Ad supported industries haven’t moved to canvas-only websites to circumvent ad blockers. I hope this is a predictor of the future.
- jopsen 9y ago
  I find it unlikely... You would effectively have to implement a browser in webassembly, as people will expect to be able to select text etc. The degration in detach indexing and user experience, load time and battery usage would quickly make a first mover loose users.
brucephillips 9y ago
Tellingly, this is effectively the "dumb pipe" version of the web that Alan Kay so voraciously advocated for.

api 9y ago

This is already possible using emscripten without too much effort. Emscripten JS is basically binary code. It's also been possible with Flash for over a decade, though fewer and fewer people have that installed.

klodolph 9y ago

"The open web" is a platform where everyone can publish and access content because the standards are open. WebAssembly makes the web more open because it puts nails in the coffin of Flash, Unity Player, and the like. Back in the day we had Flash-only web sites. They died off because it turns out that it's easier to just throw HTML, CSS, and JS at people, and since these were open standards, there was a fair bit of competition between different vendors to make better tools for consumption, authoring, and delivery. If you want to reimplement that experience in WebAssembly, the ROI is going to be horrible and if you render everything to a canvas your site won't be indexable by Google (goodbye traffic) or workable with screen readers (hello lawsuits).

wruza 9y ago
Are lawsuits like that a real thing in EU? We’re considering to make ui, at least hard part of it, in a canvas for new web-based projects. Of course, there is no intention to discriminate people with sight issues. I think we could provide different/better interface to cover this area. Besides that, are modern sites actually accessible in that regard?
- klodolph 9y ago
  No idea about the EU, but lawsuits under the ADA (Americans With Disabilities Act) are real in the US. And yes, modern sites really are accessible. Screen readers traverse the DOM looking for the semantic information that's already there. Look at WCAG (https://www.w3.org/TR/WCAG/ https://www.w3.org/TR/WCAG/), you'll see how easy it is to follow the guidelines. Unless, of course, you stick a bunch of stuff in a <canvas>...
  - spectredev 9y ago
    The ADA hasn't held up to digital, see Access Now v. Southwest Airlines
    - wruza 9y ago
      Thank you, this example really makes some important details clear.
alexasmyths 9y ago
"WebAssembly makes the web more open because it puts nails in the coffin of Flash, Unity Player, and the like." In practice, it does not. It's too low level, and the APIs to access browser features are not available, so you have to go through seriously ugly APIs and just do it in JS anyhow. So if you have to go to JS to do pretty much everything, why are we using WASM again? Performance? Is performance the issue? Because if it is, isn't there maybe better ways of solving that problem? It's certainly not for portability, we already have that. To make 'web development available to C coders' ... Not sure that's it since they will invariably have to know web browsers anyhow ... WASM is a great idea that won't gather steam until there are direct APIS. Which is on the roadmap I think. I'd suggest just trying to build a simple WA, or even trying to make a simple app out of WA. Things look different then. It's a nice dream to have, we're still a ways off.
- klodolph 9y ago
  This is a straw man argument. WASM is obviously not a compelling alternative to JS. There are few people crazy enough to write web apps in C. Is that the "nice dream to have"? However, I can think of two very compelling use cases for WASM. As an addition to JS, it gives JS programmers access to a wealth of libraries and programs written in other languages. Codecs and compression algorithms, linear algebra libraries, image and audio processing, and a million other things have good libraries that just don't happen to be written in JavaScript. Adding a WASM blob as a library you can call from JS is a huge success. Suddenly you can do tons of client-side processing that was too prohibitive before (from an engineering cost standpoint). As an alternative to Flash and Unity Player, you can write games for the web using WASM without having to deal with JavaScript. Having used WASM personally, I can say with conviction that it is a compelling addition to the open web.
  - alexasmyths 9y ago
    "lash and Unity Player, you can write games for the web using WASM without having to deal with JavaScript." No, you have to go through a seriously crazy api wherein data is passed into a single managed array in wasm, and pulled off in JS and visa versa. Ok - so accessing C libs is useful? Are bindings from other languages to C considered to be really an important things for those languages? Was there a specific set of libs that we were angling for? Does it even make sense to do those things in the browser? And what about the limitations - i.e. having to pass data into and out of the WASM container - does that play well with usage of 'codecs'? Maybe not. So why again does WASM exist? What as the compelling use case? Flash/UX is definitely not it. I don't see any real uses cases for things like codes, nor was I seeing demand. So where is the market/product need? And use case? This is cool tech that's a long way off from being useful in the real world. Having gone through the pain of writing my own little app, I realized that it's still fairly bleeding edge. I will go back to it when there are deeper APIs between JS and C, are the toolchain is more stable.
Someone 9y ago
I see that change as soon as DOM bindings for WebAssembly are available. Apple/Google/Microsoft would be stupid if they weren’t already working on a Swift/Kotlin/C# to WebAssembly compiler, as each of them would give them for their preferred language what JavaScript now has: the ability for developers to work in a single language, and move code between browser and backend at will. Long-term, JavaScript is dead.
- icebraining 9y ago
  That already happens, since you can already write compilers that target JS: Google wrote GWT and Dart. Microsoft seems to have gone the other way, pulling JS into native apps.
  - Someone 9y ago
    That is true, but it still is on JavaScript’s turf. With WebAssembly the JavaScript will be as ‘native’ as any other language. I think the psychological difference matters.

tqkxzugoaupvwqr 9y ago

Gives me nightmares. But today it’s already possible and I haven’t seen this yet. Ad supported industries haven’t moved to canvas-only websites to circumvent ad blockers. I hope this is a predictor of the future.

jopsen 9y ago
I find it unlikely... You would effectively have to implement a browser in webassembly, as people will expect to be able to select text etc. The degration in detach indexing and user experience, load time and battery usage would quickly make a first mover loose users.

brucephillips 9y ago

Tellingly, this is effectively the "dumb pipe" version of the web that Alan Kay so voraciously advocated for.