3 ms·

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

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.

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.