4 ms·

> Web{Assembly}: Enables binary executables to run in your browser “Binary executables” makes it sound like it's machine code, but WebAssembly is more like a b

> Web{Assembly}: Enables binary executables to run in your browser “Binary executables” makes it sound like it's machine code, but WebAssembly is more like a bytecode for JavaScript.

TeMPOraL 6y ago
I'm of two minds about it. On the one hand, JS should've been compiled in the first place; that we spent some two decades making computers parse increasingly complex scripts repeatedly is a sad waste, and it spawned what's probably the biggest hack ever to become a standard practice: minifying code. On the other hand, WebASM webapps will be an order of magnitude less inspectable.
- TazeTSchnitzel 6y ago
  Why will WebAssembly applications be less inspectable? JS applications are already aggressively minified multi-megabyte blobs.
  - TeMPOraL 6y ago
    I can take a look at a minified piece of JS after reformatting, and quickly guess what many of the functions do just by their shape. I won't be able to do that anywhere as easily with a piece of decompiled bytecode, especially if it went through an optimization pass.
    - derefr 6y ago
      The re-prettification of the minified code doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does. The decompiled WASM doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does. Not really seeing the difference. Minified/"uglified" JS—and especially obfuscated JS (where "minification" and "obfuscation" are frequently aligned interests, so most libraries incidentally do both)—is already "a bytecode for the browser virtual machine", just a highly-redundant encoding of one.
- qeternity 6y ago
  On the other hand, V8 is the most widely run, heavily invested and thus optimized JIT compiler in history. So I think most of the interpreted vs compiled mistakes have been Google’d out at this point.
  - TeMPOraL 6y ago
    It helps with execution speed, but not with the speed of parsing the plaintext code and interpreting (or compiling) it.
  - default-kramer 6y ago
    In my opinion, the "sad waste" has nothing to do with CPU clock cycles and everything to do with the uncountable hours humans have spent trying to make javascript tolerable. If we had bytecode from the start, it would have enabled a huge reduction in human labor.
    - drran 6y ago
      Flash implemented using bytecode.

> Web{Assembly}: Enables binary executables to run in your browser “Binary executables” makes it sound like it's machine code, but WebAssembly is more like a bytecode for JavaScript.

TeMPOraL 6y ago

I'm of two minds about it. On the one hand, JS should've been compiled in the first place; that we spent some two decades making computers parse increasingly complex scripts repeatedly is a sad waste, and it spawned what's probably the biggest hack ever to become a standard practice: minifying code. On the other hand, WebASM webapps will be an order of magnitude less inspectable.

TazeTSchnitzel 6y ago
Why will WebAssembly applications be less inspectable? JS applications are already aggressively minified multi-megabyte blobs.
- TeMPOraL 6y ago
  I can take a look at a minified piece of JS after reformatting, and quickly guess what many of the functions do just by their shape. I won't be able to do that anywhere as easily with a piece of decompiled bytecode, especially if it went through an optimization pass.
  - derefr 6y ago
    The re-prettification of the minified code doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does. The decompiled WASM doesn't have identifiers, except for the calls to the browser runtime. Unless you use a source map, in which case it does. Not really seeing the difference. Minified/"uglified" JS—and especially obfuscated JS (where "minification" and "obfuscation" are frequently aligned interests, so most libraries incidentally do both)—is already "a bytecode for the browser virtual machine", just a highly-redundant encoding of one.
qeternity 6y ago
On the other hand, V8 is the most widely run, heavily invested and thus optimized JIT compiler in history. So I think most of the interpreted vs compiled mistakes have been Google’d out at this point.
- TeMPOraL 6y ago
  It helps with execution speed, but not with the speed of parsing the plaintext code and interpreting (or compiling) it.
- default-kramer 6y ago
  In my opinion, the "sad waste" has nothing to do with CPU clock cycles and everything to do with the uncountable hours humans have spent trying to make javascript tolerable. If we had bytecode from the start, it would have enabled a huge reduction in human labor.
  - drran 6y ago
    Flash implemented using bytecode.