4 ms·

Mark my words, Web ASM will be just as opaque as traditional assembly languages. Which is to say that we'll shift the problem from "JavaScript is bad" to "I can

Mark my words, Web ASM will be just as opaque as traditional assembly languages. Which is to say that we'll shift the problem from "JavaScript is bad" to "I cannot debug this," "I cannot see what this script does," "I lost the original source code, and now I have to reverse engineer WASM! Help!" WASM isn't a panacea. Much like Flash, Java Applets, and ActiveX it is just the newest in a long line of Magic Blobs™ that supposedly solve all of our problems. Sooner or later it will become so complex that even the prospect of manually reviewing WASM will be seen as more unrealistic than a simple re-write based on input/output conditions.

kartan 9y ago
> manually reviewing WASM You should not write code in WASM. You should not review WASM. In the same way that most Java developers don't have a clue how bytecode works in the JVM.
- kizer 9y ago
  But... Java developers should have a clue how bytecode works in the JVM. Otherwise I agree.
  - freedomben 9y ago
    Honest question, why? Surely some would benefit, but the average java dev hacking on a spring app? Not so sure. Would love to hear your thoughts tho
    - kizer 9y ago
      I agree totally that most will do fine without, but the parent comment cited the fact that few devs know about bytecode/jvm to support not knowing wasm. But descriptive statements don't imply prescriptive statements. So just because most have no clue, doesn't make it "right", or able to be used as justification. I wouldn't call myself a Java dev - I mean I know Java like 99% percent of the world does - so I may have a terrible perspective on this anyways. Although knowing the basics of how Java source code -> running process would certainly help any Java dev.
bitsoda 9y ago
WASM is a compilation target. Think of it as a little machine in the browser you're writing code for. While you technically could write direct WASM code, the idea here is to have other languages compile to it, which you could then debug as normal. Outside of needing some extreme performance optimization, most web developers should never need to read or write WASM code.
- rounce 9y ago
  > WASM is a compilation target. Like the VM in the Flash runtime that runs ActionScript bytecode. Part of the GP's point still stands regarding MagicBlob™s. That said, it does differ (massively) in that it doesn't cast the spell of being a closed proprietary format: primarily driven by motivations of it's owner rather than the benefit of it's community.
arcticbull 9y ago
WASM is just an intermediate representation / compilation target. It's not meant to be human readable or human writeable. You're right that today it could be difficult to debug things that are compiled down to WASM as initially it was difficult to debug C code compiled to traditional assembly. The next step, though, was debuggers. These will come, and the issue will become moot. tl;dr: The tooling will follow.
- paulhodge 9y ago
  Even after 10 years or so, when the tooling is good enough to match the debugging experience we have now, it won't be a moot issue. There will be a much more common problem where you want to examine/modify the source code for a site, and you can't, because that site only published the non-debug WASM. One of the things that keeps the web platform healthy is the way that client-side sources are pretty visible. In response to "But JS can be obfuscated/minified" - Minified JS is still much easier to examine/modify than WASM, and it's really rare for a site to deliberately obfuscate their JS beyond minification.

kartan 9y ago

> manually reviewing WASM You should not write code in WASM. You should not review WASM. In the same way that most Java developers don't have a clue how bytecode works in the JVM.

kizer 9y ago
But... Java developers should have a clue how bytecode works in the JVM. Otherwise I agree.
- freedomben 9y ago
  Honest question, why? Surely some would benefit, but the average java dev hacking on a spring app? Not so sure. Would love to hear your thoughts tho
  - kizer 9y ago
    I agree totally that most will do fine without, but the parent comment cited the fact that few devs know about bytecode/jvm to support not knowing wasm. But descriptive statements don't imply prescriptive statements. So just because most have no clue, doesn't make it "right", or able to be used as justification. I wouldn't call myself a Java dev - I mean I know Java like 99% percent of the world does - so I may have a terrible perspective on this anyways. Although knowing the basics of how Java source code -> running process would certainly help any Java dev.

bitsoda 9y ago

WASM is a compilation target. Think of it as a little machine in the browser you're writing code for. While you technically could write direct WASM code, the idea here is to have other languages compile to it, which you could then debug as normal. Outside of needing some extreme performance optimization, most web developers should never need to read or write WASM code.

rounce 9y ago
> WASM is a compilation target. Like the VM in the Flash runtime that runs ActionScript bytecode. Part of the GP's point still stands regarding MagicBlob™s. That said, it does differ (massively) in that it doesn't cast the spell of being a closed proprietary format: primarily driven by motivations of it's owner rather than the benefit of it's community.

arcticbull 9y ago

WASM is just an intermediate representation / compilation target. It's not meant to be human readable or human writeable. You're right that today it could be difficult to debug things that are compiled down to WASM as initially it was difficult to debug C code compiled to traditional assembly. The next step, though, was debuggers. These will come, and the issue will become moot. tl;dr: The tooling will follow.

paulhodge 9y ago
Even after 10 years or so, when the tooling is good enough to match the debugging experience we have now, it won't be a moot issue. There will be a much more common problem where you want to examine/modify the source code for a site, and you can't, because that site only published the non-debug WASM. One of the things that keeps the web platform healthy is the way that client-side sources are pretty visible. In response to "But JS can be obfuscated/minified" - Minified JS is still much easier to examine/modify than WASM, and it's really rare for a site to deliberately obfuscate their JS beyond minification.