Questions about depcache

[make-github-pseudonymous-again]

With depcache, do I understand correctly that you suggest extracting static import information to a separate file? The consequence: All static imports are known ahead of (run)time, thus, when a module is loaded, all its dependencies can be loaded simultaneously without delay.

The presented solution sacrifices space, loading a potentially large but usually moderate-size metadata file, to save on the latency induced by evaluating static imports at runtime. This evaluation could hopefully be done faster than waterfall by a functioning streaming JS interpreter but these a) do not exist yet, and b) you will never be able to beat zero-latency.

Can you imagine a situation where the depcache information would become too large to preload unconditionally?

[guybedford]

Hi @aureooms, these are some good questions!

Can you imagine a situation where the depcache information would become too large to preload unconditionally?

For very large applications, this is why lazy loading import maps may be useful to even lazy load this information.

But for most applications, the depcache bloat isn't too bad. If anything integrity metadata provides more bloat than this.

The reason being that if you know your entry points / dynamic import roots, then you only need to construct the depcache backbone that applies to those specific module loads. This backbone is just the first post-order visitor to each leaf for the execution of each of the entry points, merged together into a single depcache. This can then be a significant reduction over having to include the entire graph construction.

SystemJS has been shipping depcache for a while now, and I've been using techniques to construct depcache based on the above for a while as well.

More benchmarks and performance comparisons are needed though than we have right now.