Very nice :). Maybe the Jar could be split so that people don't load things they don't use ?
Why isn't http caching sufficient?
If the authors compressed the JAR files into a single bundle, storing the data into a BrowserFS-created IndexedDB file system removes decompression/extraction overhead on subsequent visits.
If they didn't.... then it might be sufficient, but I am not sure how well the browser cache handles large files! How long until it evicts them? Is there an upper bound on the size of cached items? etc.
I am only familiar with Firefox, where the default is 43.75MiB, anything larger than that is not cached.
There's a `browser.cache.disk.max_entry_size` setting that defaults to 51200 (50MiB), however the code also has an explicit override that no item larger than 1/8 of the total cache size (as dictated by `browser.cache.disk.capacity`, default 350MiB) is ever cached, hence the 43.75MiB limit.
All these settings can be changed, obviously, but I suspect few people ever touch them.
I assume other desktop browsers have similar default limits, while mobile browsers probably have a much lower threshold.
The authors of this project can preload the JDK with a progress bar and stash it into IndexedDB, since Doppio's file system, BrowserFS, supports arbitrary backends [1].
[1] https://github.com/jvilk/browserfs