4 ms·

The main thing I didn't like about those was that they were proprietary single vendor blobs that stagnated and ran poorly.

CaptSpify 11y ago
I guess I fail to see how the end result of this will end up any different
- bobajeff 11y ago
  Considering WebAssembly is a feature that going to be standardised and supported in all JavaScript engines while those other things were either proprietary runtimes or browser specific API's I'd say you have no reason to think this will end up like them.
  - CaptSpify 11y ago
    so, IMO, I don't think any of them failed because they were > standardised and supported in all JavaScript engines while those other things were either proprietary runtimes or browser specific API's I think they failed because they were closed off, and nobody could read the shitty code, so people wrote shitty code. If we have things open, it gives people an incentive to make it look/work nice. Sure, not everyone will, but it makes it easier to shame those that dont.
    - bobajeff 11y ago
      You can't read the code of most C++ programs yet if operating systems dropped support for C++ there would be a reckoning.
drdaeman 11y ago
Well, it's no different. Say, ActiveX were just x86 binary blobs. Java applets were JVM binary blobs. (Flash applets were somewhat worser kind of binary blobs with proprietary and undocumented bytecode.) WebAssembly is... again, binary blobs.
- bobajeff 11y ago
  The runtime (which I was taking about) isn't a blob. Plus minified and obsfucated JavaScript is already quite common. See closure and asm.js.
  - drdaeman 11y ago
    Well, my point is OpenJDK/IcedTea-Web isn't a blob either, but it doesn't make Java applets any better. Neither is Wine (which can host ActiveX controls), but I'm not going to try it at home. And I agree that modern minified, packed and obfuscated JavaScript is also more like a binary blob than source code. WebAssembly is just a logical conclusion of this.

CaptSpify 11y ago

I guess I fail to see how the end result of this will end up any different

bobajeff 11y ago
Considering WebAssembly is a feature that going to be standardised and supported in all JavaScript engines while those other things were either proprietary runtimes or browser specific API's I'd say you have no reason to think this will end up like them.
- CaptSpify 11y ago
  so, IMO, I don't think any of them failed because they were > standardised and supported in all JavaScript engines while those other things were either proprietary runtimes or browser specific API's I think they failed because they were closed off, and nobody could read the shitty code, so people wrote shitty code. If we have things open, it gives people an incentive to make it look/work nice. Sure, not everyone will, but it makes it easier to shame those that dont.
  - bobajeff 11y ago
    You can't read the code of most C++ programs yet if operating systems dropped support for C++ there would be a reckoning.

drdaeman 11y ago

Well, it's no different. Say, ActiveX were just x86 binary blobs. Java applets were JVM binary blobs. (Flash applets were somewhat worser kind of binary blobs with proprietary and undocumented bytecode.) WebAssembly is... again, binary blobs.

bobajeff 11y ago
The runtime (which I was taking about) isn't a blob. Plus minified and obsfucated JavaScript is already quite common. See closure and asm.js.
- drdaeman 11y ago
  Well, my point is OpenJDK/IcedTea-Web isn't a blob either, but it doesn't make Java applets any better. Neither is Wine (which can host ActiveX controls), but I'm not going to try it at home. And I agree that modern minified, packed and obfuscated JavaScript is also more like a binary blob than source code. WebAssembly is just a logical conclusion of this.