6 ms·

> The complete classes are over 500kB; no one will want to download these on-line Ah, the good old days. I can't wait to see how huge the runtimes we'll be ex

> The complete classes are over 500kB; no one will want to download these on-line Ah, the good old days. I can't wait to see how huge the runtimes we'll be expected to download for WebAssembly will be.

bluedino 8y ago
I find that odd. Even over a 14.4 modem (which was obsolete by that time) it would only take about 5 minutes.
- pilif 8y ago
  Applets were supposed to be embedded into webpages like images. Given the JRE was already started, you'd expect the load time to be a few seconds at most. For sure not 5 minutes before a page becomes interactive.
  - cesarb 8y ago
    > Given the JRE was already started, you'd expect the load time to be a few seconds at most. For sure not 5 minutes before a page becomes interactive. My recollection of these times is that when the JRE was not already started (which was often the case), it took up to one minute to start - and during this start process, the whole browser was frozen, with a helpful message on the status bar pointing to Java as the culprit. No wonder people started to think of Java as slow.
    - kalleboo 8y ago
      I remember timing it to 30 seconds on our Mac Performa 5200. And in System 7.5 it froze up the whole OS when it was doing it's thing.
      - db48x 8y ago
        Cooperative multitasking at its finest.
DaiPlusPlus 8y ago
I’m hoping eventually we’ll have some form of true content-addressable storage for the web - so browsers cache content by hash instead of address. That way we wouldn’t be re-downloading jQuery-3.0.6-min.js for each website we visit (that isn’t using a CDN), but only once - the same could be done with WebAssembly - assuming it doesn’t require monolithic statically linked blobs.
- wongarsu 8y ago
  Browsers have the option to do this for javascript: with subresource integrity [0] you can add the sha256 hash of the script to a script tag. The browser could check that hash against its cache, in case it's yet another copy of jQuery-3.0.6-min.js. No browser does this because it opens up a huge data leak: I can simply add some script to my website, claim it has the hash of the javascript used by PornHub and measure the loading time of the script (or simply whether the integrity check fails) to find out if you visited PornHub. 0: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
  - SlowRobotAhead 8y ago
    News to me, but yea that’s an excellently described reason that why that isn’t used. The natural inclination would be to say “well, we just need a central repository of shared libs” but now you move to a familiar spot of the big wheel of problems we keep trying to fix.
  - DaiPlusPlus 8y ago
    It would only be for widely distributed scripts - not site-specific resources for that reason. Think things like jQuery, Angular, Vue.js and RxJS. This would be especially useful for heavier frameworks like Angular because browsers could then have the entire full-fat edition available in-cache so then smaller Angular sites could make use of more features without making their entire site a slow download.
- SlowRobotAhead 8y ago
  >so browsers cache content by hash instead of address. Are you trying to encourage investment in hash collision technologies? ;)

bluedino 8y ago

I find that odd. Even over a 14.4 modem (which was obsolete by that time) it would only take about 5 minutes.

pilif 8y ago
Applets were supposed to be embedded into webpages like images. Given the JRE was already started, you'd expect the load time to be a few seconds at most. For sure not 5 minutes before a page becomes interactive.
- cesarb 8y ago
  > Given the JRE was already started, you'd expect the load time to be a few seconds at most. For sure not 5 minutes before a page becomes interactive. My recollection of these times is that when the JRE was not already started (which was often the case), it took up to one minute to start - and during this start process, the whole browser was frozen, with a helpful message on the status bar pointing to Java as the culprit. No wonder people started to think of Java as slow.
  - kalleboo 8y ago
    I remember timing it to 30 seconds on our Mac Performa 5200. And in System 7.5 it froze up the whole OS when it was doing it's thing.
    - db48x 8y ago
      Cooperative multitasking at its finest.

DaiPlusPlus 8y ago

I’m hoping eventually we’ll have some form of true content-addressable storage for the web - so browsers cache content by hash instead of address. That way we wouldn’t be re-downloading jQuery-3.0.6-min.js for each website we visit (that isn’t using a CDN), but only once - the same could be done with WebAssembly - assuming it doesn’t require monolithic statically linked blobs.

wongarsu 8y ago
Browsers have the option to do this for javascript: with subresource integrity [0] you can add the sha256 hash of the script to a script tag. The browser could check that hash against its cache, in case it's yet another copy of jQuery-3.0.6-min.js. No browser does this because it opens up a huge data leak: I can simply add some script to my website, claim it has the hash of the javascript used by PornHub and measure the loading time of the script (or simply whether the integrity check fails) to find out if you visited PornHub. 0: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- SlowRobotAhead 8y ago
  News to me, but yea that’s an excellently described reason that why that isn’t used. The natural inclination would be to say “well, we just need a central repository of shared libs” but now you move to a familiar spot of the big wheel of problems we keep trying to fix.
- DaiPlusPlus 8y ago
  It would only be for widely distributed scripts - not site-specific resources for that reason. Think things like jQuery, Angular, Vue.js and RxJS. This would be especially useful for heavier frameworks like Angular because browsers could then have the entire full-fat edition available in-cache so then smaller Angular sites could make use of more features without making their entire site a slow download.
SlowRobotAhead 8y ago
>so browsers cache content by hash instead of address. Are you trying to encourage investment in hash collision technologies? ;)