Hacker News Reader

Comment by Someone1234 | Hacker News Reader

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.

View on HN

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.

> 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.

> 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.

But... Java developers should have a clue how bytecode works in the JVM. Otherwise I agree.

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

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.

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.

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.

Reply on news.ycombinator.com