3 ms·
Nice! I've heard that Google's Inbox (and likely other websites) uses this technique, although the implementation AFAIU is not open source. ...actually, I thi
by stephen 10y ago
Nice!
I've heard that Google's Inbox (and likely other websites) uses this technique, although the implementation AFAIU is not open source.
...actually, I think their's is different, in that it doesn't depend on service workers; AFAIU the approach is:
if you move from js-lib-v1.js to js-lib-v2.js, they'll go ahead and source js-lib-v1.js in the browser, and then also load js-lib-v1-to-v2.js, which is a server-side generated JS file that redeclares/redefines only the JS functions/modules/whatever that have changed from v1 to v2.
So, I believe their approach is much more intricate, because I believe it diffs the JS at a semantic level to generate the "patch the already-loaded JS by doing another JS load", vs. AFAICT your approach of just doing a textual diff.
Assuming my assumptions about both approaches are right, I definitely prefer yours in terms of simplicity; albeit the Google approach is (or was?) necessary to benefit most users.
- lstamour 10y agoI'm reminded of https://github.com/google/module-server/blob/master/README.md https://github.com/google/module-server/blob/master/README.m... from a (linked) 2012 presentation. I believe I found it in 2013, there might be other more recent talks. If I recall, the unique feature of the proposed Google loader was that it would dynamically take into consideration a dependency graph of the next JS to load and serve up just enough to show whatever page you needed, and if the next page in the graph had different dependencies, it would load just the ones you didn't already have. Can't remember the details right now, it's been a few years. Made tremendous sense at the time, but the implementation might need to be improved a bit given HTTP/2 and more modern JS loaders, including a WhatWG spec.