4 ms·

There can be hundreds of different versions for each popular library, and as a dev, I need customers to use exactly the version that we tested against. There’s

There can be hundreds of different versions for each popular library, and as a dev, I need customers to use exactly the version that we tested against. There’s a whole ecosystem and tool chain around lockfiles and deterministic builds for a reason. And specifying a version range isn’t sufficient, because humans will and do get it wrong - either the one specifying the range or the one publishing a new version. Ultimately, browsers cache static assets anyways. So this idea only helps the user’s first page load for a given website. Edit: I’ll add that at my company we looked into preloading assets that are commonly used across teams’ web apps. And this is why we didn’t build it.

davnicwil 5y ago
The many versions thing does seem like a problem just in terms of size on disk but perhaps a one solution to this would be storing the libs as a series of git-style deltas starting from a root version which are then 'resolved' on the fly. I feel like the lockfile etc situation is pretty solvable just by making the relevant tools aware of the new standard. I.e. just a different implementation of an npm-style interface. On the existing browser cache point, I guess the difference here would be that this special cache would never be cleared, and also being a standard would probably mean better reuse across apps. It's true though that otherwise it's not too far away from everyone just agreeing on a standard CDN or something, just that maybe making it an actual web standard as part of the script tag itself would make this more likely. In fact, I guess you could even just implement it like this under the hood!
- krapp 5y ago
  >The many versions thing does seem like a problem just in terms of size on disk but perhaps a one solution to this would be storing the libs as a series of git-style deltas starting from a root version which are then 'resolved' on the fly. Just sending the scripts with the site is still far, far simpler, and guaranteed to work (provided the user hasn't turned off JS.) What little, if any, gain in performance doesn't seem worth the extra complexity.
  - davnicwil 5y ago
    Definitely agree here that the complexity / benefits tradeoff is not totally clear cut in favour of this, and it could well be the reason nothing like this has been proposed (that I know of)! That said, aside from the UX-y benefit of load time, under performance gains I would also include saving the processing and pushing around of all those bits at web scale. That's got to represent incredibly impactful absolute energy savings, and bandwidth cost savings.
    - krapp 5y ago
      You still have to do extra processing to know whether the end user has the right libraries installed, and to deal with fallbacks if necessary, that's going to involve at least an extra round trip. Also, all of this has to occur before the page starts rendering, which may not be an issue if the user has the necessary libraries, but if they don't, you still have to send them anyway. They could have them cached from a previous visit, but that's how browsers already work. The fact is, most JS libraries are small enough that they download almost immediately, it's what they actually run that's slow. All that said, I do think something like this would work great for Webassembly dependencies. What's being described is basically a dependency or package manager type of thing. I can see browsers in the future shipping with JS, Python, C or whatever runtimes as WASM blobs. All of the same issues still apply (including latency issues when downloading as a fallback,) but programming language runtimes and libraries tend not to move as fast as javascript frameworks. But imagine the possibilities if you could essentially embed the source code of any application in any language and have it interpreted or compiled and run in the browser, maybe with little more work than some script tags?
      - davnicwil 5y ago
        Just to be clear the proposal I'm making would be that all these libs are pre-included in the browser. This wouldn't just be a special non-deletable cache where the libraries are pulled lazily on first use. It'd be an entirely separate concept from the current browser cache of JS files, in fact. Potentially 'cache' is a bit of a misleading term here. There's probably a bit of a question of what to do when new versions and/or new libs are included in the index (probably download new ones periodically or upon a notification) where there could feasibly be some lag time where that lib/version isn't available yet. But that'd be an edge case situation.

davnicwil 5y ago

The many versions thing does seem like a problem just in terms of size on disk but perhaps a one solution to this would be storing the libs as a series of git-style deltas starting from a root version which are then 'resolved' on the fly. I feel like the lockfile etc situation is pretty solvable just by making the relevant tools aware of the new standard. I.e. just a different implementation of an npm-style interface. On the existing browser cache point, I guess the difference here would be that this special cache would never be cleared, and also being a standard would probably mean better reuse across apps. It's true though that otherwise it's not too far away from everyone just agreeing on a standard CDN or something, just that maybe making it an actual web standard as part of the script tag itself would make this more likely. In fact, I guess you could even just implement it like this under the hood!

krapp 5y ago
>The many versions thing does seem like a problem just in terms of size on disk but perhaps a one solution to this would be storing the libs as a series of git-style deltas starting from a root version which are then 'resolved' on the fly. Just sending the scripts with the site is still far, far simpler, and guaranteed to work (provided the user hasn't turned off JS.) What little, if any, gain in performance doesn't seem worth the extra complexity.
- davnicwil 5y ago
  Definitely agree here that the complexity / benefits tradeoff is not totally clear cut in favour of this, and it could well be the reason nothing like this has been proposed (that I know of)! That said, aside from the UX-y benefit of load time, under performance gains I would also include saving the processing and pushing around of all those bits at web scale. That's got to represent incredibly impactful absolute energy savings, and bandwidth cost savings.
  - krapp 5y ago
    You still have to do extra processing to know whether the end user has the right libraries installed, and to deal with fallbacks if necessary, that's going to involve at least an extra round trip. Also, all of this has to occur before the page starts rendering, which may not be an issue if the user has the necessary libraries, but if they don't, you still have to send them anyway. They could have them cached from a previous visit, but that's how browsers already work. The fact is, most JS libraries are small enough that they download almost immediately, it's what they actually run that's slow. All that said, I do think something like this would work great for Webassembly dependencies. What's being described is basically a dependency or package manager type of thing. I can see browsers in the future shipping with JS, Python, C or whatever runtimes as WASM blobs. All of the same issues still apply (including latency issues when downloading as a fallback,) but programming language runtimes and libraries tend not to move as fast as javascript frameworks. But imagine the possibilities if you could essentially embed the source code of any application in any language and have it interpreted or compiled and run in the browser, maybe with little more work than some script tags?
    - davnicwil 5y ago
      Just to be clear the proposal I'm making would be that all these libs are pre-included in the browser. This wouldn't just be a special non-deletable cache where the libraries are pulled lazily on first use. It'd be an entirely separate concept from the current browser cache of JS files, in fact. Potentially 'cache' is a bit of a misleading term here. There's probably a bit of a question of what to do when new versions and/or new libs are included in the index (probably download new ones periodically or upon a notification) where there could feasibly be some lag time where that lib/version isn't available yet. But that'd be an edge case situation.