I recently sat in on a presentation regarding javascript module loading. Someone in our company had taken it upon themselves to roll their own solution, because, shit, they're being paid and apparently have no oversight.
The solution involved creating an entire cache/hash layer on the client using local storage.
At the end of the presentation I had to try to be as respectful as possible when I asked why basic browser caching and content expiration weren't enough. Apparently it wasn't even considered -_-
Perhaps they wanted it to work even when offline? It can be a struggle to get basic browser caching to work nicely in online/offline scenarios. As arethuza points out though, that is better addressed using appcache.
I could imagine doing something like this if you wanted to support say es6 modules, and so each file needed to be processed after it was loaded to work in the current browser. In that case, I can imagine wanting to cache a processed one on the client side, although if you control your whole stack, it'd be better to do that work on the server.
Don't judge them too harshly. I am currently developing web app with offline capabilities. FT which provide the scaffolding code recommend using the cache manifest only for the absolutely minimum requirements (jquery + 10 lines of html) and use local storage for all the rest.
Admittedly, when I was working on it, we were trying to wrangle it into something it really wasn't meant to do, but that fact - that it wasn't a good fit for our application - wasn't at all obvious until I finally started encountering all the "gotchas", and reading more about them.
The solution involved creating an entire cache/hash layer on the client using local storage.
At the end of the presentation I had to try to be as respectful as possible when I asked why basic browser caching and content expiration weren't enough. Apparently it wasn't even considered -_-