5 ms·

Very true but wouldn't you say Java bytecode looks a lot more like it was intended to be interpreted as an intermediate language than Javascript does?

• comex 10y ago
  Hence the transition from asm.js to WebAssembly, which is getting pretty close to readiness.
  • kuschku 10y ago
    Except, it’s also less debuggable and modifiable by end users. How is the end user supposed to modify the code, or break the DRM to create a local copy, or port it to another platform once this isn’t supported anymore? WebAssembly breaks that ability, while Java at least retains it somewhat.
    • comex 10y ago
      What specifically are you referring to? WebAssembly and JVM bytecode are fairly similar; the JVM is more explicit about some things, like data types (classes), but I'm not sure the difference is that stark.
      • kuschku 10y ago
        Have you tried reversing code in both before? Even the most complicated bytecode for the JVM (for example, code extracted from Android apps and thrown through dex2jar) is a lot easier readable than WebAssembly. I’ve spent quite a while reversing example projects in both formats, and I really hate WebAssembly.
    • db48x 10y ago
      Webassembly is a complier target, not a type of source code; you compile your source to webassembly, you don't write code in it. On the other hand, the browser devtools all still work on pages that use it. If the owner of the site you're debugging is friendly they'll include source maps so that you see the original source. If they're not then you get a disassembled view of the webassembly code. This is not very different from seeing a prettified version of a minified or obscured Javascript file. I don't think that it changes the equation that much, except that execution speed will be better.
      • kuschku 10y ago
        > If they're not then you get a disassembled view of the webassembly code. This is not very different from seeing a prettified version of a minified or obscured Javascript file. I’ve spent a few weeks looking at those, comparing them, and manually deobfuscating examples. Even getting through DRM in most web- or android apps is easier than trying to get through similar example projects in webassembly. > If the owner of the site you're debugging is friendly they'll include source maps so that you see the original source. If they're not then you get a disassembled view of the webassembly code. The whole point is that this shouldn’t just be "if the owner is friendly", but a technical or legal requirement.
        • db48x 10y ago
          You would legislate that website operators are not allowed to obfuscate their javascript by removing all the variable names as well? That would either be a dystopian nightmare or utterly useless.
          • kuschku 10y ago
            Why not? Why would it be a dystopian nightmare? I mean, we already have early systems where you pay a tax if you create copies of stuff, which is distributed to creators, and in return you may just rip CDs, etc. Why would a truly open source world be a dystopian nightmare? Creators still would get paid, innovation would be a lot faster, without sacrificing anything. And it would find a legal solution to what is already done illegally with the remixing culture, and also allow it in software.
            • icebraining 10y ago
              I think db48x's point is that you can't force open source, since people can still obfuscate it enough to render the openness moot, unless you literally legislate and enforce a full style guide on every single programmer (hence the dystopia).
              • 10y ago
    • hulahoof 10y ago
      In this scenario WebAssembly is analogous to bytecode, which is also less debuggable and modifiable than the Java source