npm to our
node_modules folder and we transform and bundle it for browsers using
babel. This was necessary because browsers didn’t have support for new features, most importantly module support and sending a lot of separate files to the browser was inefficient, so we transformed and bundled ahead-of-time.
When I think of the best chunking approach that would be the most cachable, it’s no surprise that sending modules separately seems to be it. If we send
lodash separately, for instance, it will stay cached until we bump the version and all subsequent visits will hit the cache. How about initial load? It would be the best for the browsers to aware of bundles and unbundle them and cache the modules but that doesn’t seem like something on the roadmap. So it’s either you develop intricate strategies to build the “just fine” size of bundles or you trust HTTP/2 and optimize for returning users. And it’s not an either/or scenario, you can use server rendering and graceful degradation so the users don’t need to wait for loading and parsing of scripts to experience the basic functionalities of your website.
The way to solve this is to trust the browsers. They are now module aware so you can add dependencies without adding them to the global scope, and they are much better at downloading multiple resources than before. So my suggestion would be to add script tags for the modules that you use to your HTML from UNPKG, which is an excellent CDN. You may need a tool to notify your out-of-date dependencies and bump them for you but that’s it. This is the vanilla case, which would cover the needs of many projects.
In this case we can also go with UNPKG and use the hypothetical dependency tracking tool, but we also need IDE support and we may want to serve the scripts ourselves. (No, shared cache does not work anymore.) In that case using
node_modules can be unavoidable, but the bright side is you get all the niceties of
npm. Maybe in the future the tooling can be improved so we can get away with simpler tools than
npm to mimic the UNPKG way.
It also makes sense to keep in mind that static generation of routes is also an important optimization that has a bright future. The logical conclusion is to have a multi-pass rendering scheme where the routes are semi-generated for semi-static routes so unnecessary calls to the database are not made frequently. In that case database can be a trigger for the build process but that’s a topic for another note.
- If your website is mostly static, think about adding modules from UNPKG to keep things simple, using a simple tool to manage your dependencies
- Seriously consider what you can push to static, explore multi-pass rendering