6 ms·

I'm dreaming of seeing a wasm DOM api that directly binds to the browser's apis, without passing through javascript. Is this even a possibility?

grayrest 9y ago
I believe that'd be a follow-up to the host bindings proposal [1]. [1] https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md https://github.com/WebAssembly/host-bindings/blob/master/pro...
- alex_duf 9y ago
  Thanks for the link!
steveklabnik 9y ago
That’s the “host bindings” proposal. All of this tooling has been written to be forward-compatible with it, so whenever that lands, you can upgrade the tool and get a speed boost for free.
- alex_duf 9y ago
  Great!
plurgid 9y ago
when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?
- s73v3r_ 9y ago
  I cannot disagree more. Sure, the days of "View Source" might be coming to an end (although I doubt it), but there has never, and I mean never been an easier time to get started with these things. The vast amount of tools and resources for learning available for free is unprecedented. The open web is quite safe for years, if not decades to come.
- ag_dubs 9y ago
  there's a human readable version, you can read more about it here: https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...
- steveklabnik 9y ago
  The ability to preserve “view source” has been a first-class consideration of wasm since the beginning. It’s effectivly the same as JavaScript in this regard.
- mrec 9y ago
  > Is a disassembler for WASM a thing yet? Yes, it's part of the standard toolkit. See https://github.com/WebAssembly/wabt https://github.com/WebAssembly/wabt and specifically the "wasm2wat" tool.
- jchw 9y ago
  I've tried to read source code from YouTube and let me tell you: If that kills it, it was already dead. Obfuscation and minification is already as bad as bytecode. Honestly, wasm might be a little better because there are less insane hacks and more simple, if low level, code. Also, if people are willing to implement DRM in it just because it's bytecode, I'd rather they did that than implemented rootkits in all of the browsers. Thanks for that one W3C.
- api 9y ago
  Webpacked and possibly optimized/minified JavaScript is basically the same thing as compiled code. We are already there.
- krapp 9y ago
  > when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. No more than it was when Flash was a thing, or Java applets, or Silverlight. The world has been presented with numerous opportunities to turn the web into nothing but binaries, it hasn't happened. >Unless maybe I'm missing something. You're missing the part where someone would have to put a gun to everyone's head and force them to rewrite the entire web as WASM blobs, then force all of the browsers to be redesigned, and the servers, so that HTML and plaintext are deprecated, for your doomsday scenario to be even remotely plausible.
api 9y ago
It's proposed but it's also already possible if you use a very thin JS glue layer.
abritinthebay 9y ago
It's absolutely a possibility but the problem is one of speed. DOM interop is one of the things that slows down JS so much and requires a lot of flexibility. Adding it to WASM will not be the amazing experience many think it will be.
- hinkley 9y ago
  I don't know about others but I'm not expecting it to be an amazing experience. It's more that I expect not having DOM interop to be an amazingly boring experience. Maybe Rust could be good for Web Workers but it'll be far more interesting when I can use it for interactions. The overhead problem you mention reminds me a little of the false intuition that people have about databases. I've worked on a couple projects where people were surprised that as the data set grew (either more customers, or accumulated customer activity), operations like INSERT and UPDATE got slower and slower, even without new functionality getting in the way. Everyone expects SELECT to get slower, but INSERTs seem to catch them off guard. Every INSERT or UPDATE has to update the indexes. And when you quadruple the data, the update time for each index doubles. At first the cost of the insert is in the noise floor. It's swamped by the communication and transaction overhead. But after a handful of doublings it becomes detectable. A few more and it becomes noticeable. After a few more it becomes a problem, and if you haven't already changed your product roadmap, you do now. To make a web page fast, you have to correlate the DOM with the CSS and the viewport. Adding more data isn't free.
  - abritinthebay 9y ago
    Good illustration of that issue. I don’t know if I agree it’ll be less interesting- but it will have narrower applications. They’ll be more self contained - data and processing related - rather than driving the UI... but I don’t know if I’d call that not interesting. I mean... imagine a WASM game engine where the modules/plugins can be any language as long as the compile target is WASM and they follow the right API... with JS/DOM just doing the DOM part (canvas or webgl I guess). Sounds pretty powerful and fun.

grayrest 9y ago

I believe that'd be a follow-up to the host bindings proposal [1]. [1] https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md https://github.com/WebAssembly/host-bindings/blob/master/pro...

alex_duf 9y ago
Thanks for the link!

steveklabnik 9y ago

That’s the “host bindings” proposal. All of this tooling has been written to be forward-compatible with it, so whenever that lands, you can upgrade the tool and get a speed boost for free.

alex_duf 9y ago
Great!

plurgid 9y ago

when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. Unless maybe I'm missing something. Is a disassembler for WASM a thing yet?

s73v3r_ 9y ago
I cannot disagree more. Sure, the days of "View Source" might be coming to an end (although I doubt it), but there has never, and I mean never been an easier time to get started with these things. The vast amount of tools and resources for learning available for free is unprecedented. The open web is quite safe for years, if not decades to come.
ag_dubs 9y ago
there's a human readable version, you can read more about it here: https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...
steveklabnik 9y ago
The ability to preserve “view source” has been a first-class consideration of wasm since the beginning. It’s effectivly the same as JavaScript in this regard.
mrec 9y ago
> Is a disassembler for WASM a thing yet? Yes, it's part of the standard toolkit. See https://github.com/WebAssembly/wabt https://github.com/WebAssembly/wabt and specifically the "wasm2wat" tool.
jchw 9y ago
I've tried to read source code from YouTube and let me tell you: If that kills it, it was already dead. Obfuscation and minification is already as bad as bytecode. Honestly, wasm might be a little better because there are less insane hacks and more simple, if low level, code. Also, if people are willing to implement DRM in it just because it's bytecode, I'd rather they did that than implemented rootkits in all of the browsers. Thanks for that one W3C.
api 9y ago
Webpacked and possibly optimized/minified JavaScript is basically the same thing as compiled code. We are already there.
krapp 9y ago
> when we can make web pages, and entire sites without once actually using something a human can disassemble and reverse engineer ... this will be the end of the open web. truly the complete dead end of it. No more than it was when Flash was a thing, or Java applets, or Silverlight. The world has been presented with numerous opportunities to turn the web into nothing but binaries, it hasn't happened. >Unless maybe I'm missing something. You're missing the part where someone would have to put a gun to everyone's head and force them to rewrite the entire web as WASM blobs, then force all of the browsers to be redesigned, and the servers, so that HTML and plaintext are deprecated, for your doomsday scenario to be even remotely plausible.

api 9y ago

It's proposed but it's also already possible if you use a very thin JS glue layer.

abritinthebay 9y ago

It's absolutely a possibility but the problem is one of speed. DOM interop is one of the things that slows down JS so much and requires a lot of flexibility. Adding it to WASM will not be the amazing experience many think it will be.

hinkley 9y ago
I don't know about others but I'm not expecting it to be an amazing experience. It's more that I expect not having DOM interop to be an amazingly boring experience. Maybe Rust could be good for Web Workers but it'll be far more interesting when I can use it for interactions. The overhead problem you mention reminds me a little of the false intuition that people have about databases. I've worked on a couple projects where people were surprised that as the data set grew (either more customers, or accumulated customer activity), operations like INSERT and UPDATE got slower and slower, even without new functionality getting in the way. Everyone expects SELECT to get slower, but INSERTs seem to catch them off guard. Every INSERT or UPDATE has to update the indexes. And when you quadruple the data, the update time for each index doubles. At first the cost of the insert is in the noise floor. It's swamped by the communication and transaction overhead. But after a handful of doublings it becomes detectable. A few more and it becomes noticeable. After a few more it becomes a problem, and if you haven't already changed your product roadmap, you do now. To make a web page fast, you have to correlate the DOM with the CSS and the viewport. Adding more data isn't free.
- abritinthebay 9y ago
  Good illustration of that issue. I don’t know if I agree it’ll be less interesting- but it will have narrower applications. They’ll be more self contained - data and processing related - rather than driving the UI... but I don’t know if I’d call that not interesting. I mean... imagine a WASM game engine where the modules/plugins can be any language as long as the compile target is WASM and they follow the right API... with JS/DOM just doing the DOM part (canvas or webgl I guess). Sounds pretty powerful and fun.