A common practice people use with bundling is using cache-busting URLs, for example
src="bundle-v-1-0-3-389", or even using some kind of hash based on the file contents. In all of these cases the idea is to load the script from a different address, so any users that have it cached will get the latest version of the bundle rather than using a stale cached version. If you don’t do something along these lines, you’ll be investing in the “please empty your cache and hard reload” helpline.
So here is an excellent benefit to using modules instead of bundling.
When you load modules individually, each one can be cached independently. When your release contains a change to one of your modules, only that one module will need to be re-downloaded – everything else will be lighting fast because it is cached. If your large program is divided into one hundred modules, the cache-busting will result in 1% of the program needing to be downloaded to get the update, which is a 99% improvement compared to bundling.
One of the objections to using a module loader is this:
Multiple HTTP requests are inefficient because requests are queued longer than they take to download
There are a couple of answers to this statement. If you really care about speed you should be using HTTP/2, which allows low-latency content delivery. This eliminates the queue argument for modern web browsers. You also need to bear in mind that while you may be optimizing actual measured speed with a bundle, you are likely to be creating a sub-optimal perceived loading time (i.e. if you load the “fundamental visual modules” early, the user will feel like everything is “done” while you are still downloading tangential modules. You can also conditionally load modules so they are only downloaded if, and when, they are needed. You may be surprised at how few modules you need to load to show your users a working web application, and how much faster the perceived loading time is than downloading a massive bundle.
We can summarise all of this into four simple quadrants:
So if your program is either on the larger side, or gets deployed frequently, you’re likely to find modules are a better long-term strategy. This is especially the case as your program will get bigger over time, and your team are likely to deploy more often too.