I really like this idea, but I'm not sure if it would work in practice. It's basically working against webpack's code splitting because those are tagged with hashes. Additionally, the first load will still be quite heavy, whereas with code splitting at least there's some semblance of a smaller initial load. Since it's not native to the browser, it would have a nontrivial initialization overhead as well.
I think it could be a cool idea if it's offered as a static file hosting as a service kind of deal that requires zero config, but then again if you're the kind of person that wants a zero config static file hosting, you're probably not pushing daily/hourly software releases?
It would be neat to have something like this more transparently implemented though. Seeing a 2MB+ module rebuild for a minor typo fix is aggravating.
* For each bundle, webpack produces the compiled bundle and a seperate diff file between the latest release and every previously published release. Filenames could be [oldhash]-[newhash].js
* The webpack loader can check if the browser has that specific module cached (I believe service workers are able to inspect the http cache like this), and then based on the version that is cached, request the correct filename for a diff to the latest version.
* Then apply the diff and load the javascript as normal.
I just did a quick test with a webapp of mine, and a small diff file made with the rsync algorithm (via rdiff-backup) of a webpack bundle was just 150 bytes.
> Then apply the diff and load the javascript as normal.
Can service workers mutate the HTTP cache? I haven't seen it yet, but if not, it seems like the client might be forever pinned to the old version. I guess most likely we'd have to avoid the HTTP cache all together and run our own application module caching. That could work, but wonder if the performance overhead would be worth it...
I'll play around this a little more though, it's a really cool idea. Getting a clean API seems tricky but doable.
I think it could be a cool idea if it's offered as a static file hosting as a service kind of deal that requires zero config, but then again if you're the kind of person that wants a zero config static file hosting, you're probably not pushing daily/hourly software releases?
It would be neat to have something like this more transparently implemented though. Seeing a 2MB+ module rebuild for a minor typo fix is aggravating.