6 ms·

I'd wager there's a lot of lower level optimisations - especially for different architectures - that you just can't get with platform agnostic 'assembly'. I al

I'd wager there's a lot of lower level optimisations - especially for different architectures - that you just can't get with platform agnostic 'assembly'. I also think its better for everyone if you don't need to load/download, decode, compile and run a full language runtime on every page load. Imagine a JVM running on web assembly: Every page load first has to decode and compile a full many-MB JVM, then the JVM can start booting - without any platform/architecture specific optimizations. The more stuff that's common for webasm-targeting-languages that we can move into the browser, the less effort wasted overall.

megaman22 8y ago
Somebody wake me up when we move beyond reimplementing Java applets and Flash once more. We had nice batteries-included VMs in the browser, and we turned our backs on them and went back to square one. Again, and again, and again. So we could bang rocks together with javascript. Almost makes me wish VBScript IE had won. We might be writing browser apps in .NET now...
- kodablah 8y ago
  One might be seen as sleeping back then too if they considered proprietary, complicated, insecure behemoths with large, sometimes shitty standard libraries and forced high-level constructs as "nice batteries-included VMs".
  - crooked-v 8y ago
    > sometimes shitty I still have to do .stream() and .toList() (or .collect(Collectors.toList())) back and forth in Java all the time just to get reliable access to map/filter lambdas while still having a valid return value.
    - megaman22 8y ago
      Java's shittiness is a problem, but for the mid 2000s, it wasn't extra shitty in comparison. That long stagnation after 1.6 really hurt.
- kibibu 8y ago
  Flash's demise is 100% Adobe's fault. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash
  - andyonthewings 8y ago
    Yeah, there are 1098 Flash related CVEs, but Google Chrome itself also has 1608 CVEs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chrome https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chro... Better stop using Chrome now.
    - deleted 8y ago
      [deleted]
    - imtringued 8y ago
      Are those CVEs still active or has google/adobe fixed them already?
      - kibibu 8y ago
        They generally only get published in any detail once they've been fixed. Chrome seem to have a bunch of 2018 vulnerabilities that aren't listed here though...
    - sanxiyn 8y ago
      Yes, the fact that Google Chrome is written in C++ is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
      - GenericsMotors 8y ago
        Yes, the fact that the Linux kernel is written in C is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
      - rthugh02 8y ago
pjmlp 8y ago
You can cache runtimes with IndexDB, no need to keep downloading them.
- vimslayer 8y ago
  But IDB follows the same-origin policy, so you can't share the cached runtime between different apps. At least not unless you can load it from the same public CDN. Edit: Actully, I'm not sure you could do that even with the public CDN.
  - pjmlp 8y ago
    Sure, but you can cache it between invocations of the same app, meaning one can make PWAs with WebAssembly help.

megaman22 8y ago

Somebody wake me up when we move beyond reimplementing Java applets and Flash once more. We had nice batteries-included VMs in the browser, and we turned our backs on them and went back to square one. Again, and again, and again. So we could bang rocks together with javascript. Almost makes me wish VBScript IE had won. We might be writing browser apps in .NET now...

kodablah 8y ago
One might be seen as sleeping back then too if they considered proprietary, complicated, insecure behemoths with large, sometimes shitty standard libraries and forced high-level constructs as "nice batteries-included VMs".
- crooked-v 8y ago
  > sometimes shitty I still have to do .stream() and .toList() (or .collect(Collectors.toList())) back and forth in Java all the time just to get reliable access to map/filter lambdas while still having a valid return value.
  - megaman22 8y ago
    Java's shittiness is a problem, but for the mid 2000s, it wasn't extra shitty in comparison. That long stagnation after 1.6 really hurt.
kibibu 8y ago
Flash's demise is 100% Adobe's fault. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=adobe+flash
- andyonthewings 8y ago
  Yeah, there are 1098 Flash related CVEs, but Google Chrome itself also has 1608 CVEs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chrome https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=google+chro... Better stop using Chrome now.
  - deleted 8y ago
    [deleted]
  - imtringued 8y ago
    Are those CVEs still active or has google/adobe fixed them already?
    - kibibu 8y ago
      They generally only get published in any detail once they've been fixed. Chrome seem to have a bunch of 2018 vulnerabilities that aren't listed here though...
  - sanxiyn 8y ago
    Yes, the fact that Google Chrome is written in C++ is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
    - GenericsMotors 8y ago
      Yes, the fact that the Linux kernel is written in C is nothing short of total disaster. It is bad for humanity. Just count all those "use after free" vulnerabilities.
    - rthugh02 8y ago

pjmlp 8y ago

You can cache runtimes with IndexDB, no need to keep downloading them.

vimslayer 8y ago
But IDB follows the same-origin policy, so you can't share the cached runtime between different apps. At least not unless you can load it from the same public CDN. Edit: Actully, I'm not sure you could do that even with the public CDN.
- pjmlp 8y ago
  Sure, but you can cache it between invocations of the same app, meaning one can make PWAs with WebAssembly help.