Externalize Dependencies to be Loaded via CDN with webpack
We can separate our custom application code from the common libraries we leverage, such as React and ReactDOM. In this lesson we'll configure webpack to treat React and ReactDOM as external dependencies. Then we'll update our HTML template to conditionally include the CDN links for those libraries for production builds.
What's the main benefit of doing this separation (is there a benefit?) of React and ReactDOM from the main app.bundle.js to CDNs?
What's the main benefit of doing this separation (is there a benefit?) of React and ReactDOM from the main app.bundle.js to CDNs?
One of the main advantages of using a CDN is reduced latency, so if you cannot, for some reason, host your main bundle on a CDN, you can at least speed up loading of some dependencies. In addition to that, if you use a commonly used CDN, you can potentially take advantage of the browser's cached copy of React and ReactDOM from other sites that are also hosting from that CDN.
How does versioning work with this, especially if the cached copy is different? I assume it must match exactly. Also, I don't quite understand why there would be reduced latency - is this just because the CDN for popular packages like React is assumed to be faster than wherever I'm serving my bundle from, or is it because my bundle and CDN scripts can be served in parallel?
How does versioning work with this, especially if the cached copy is different? I assume it must match exactly. Also, I don't quite understand why there would be reduced latency - is this just because the CDN for popular packages like React is assumed to be faster than wherever I'm serving my bundle from, or is it because my bundle and CDN scripts can be served in parallel?
Yes, you would want your versions to match. In cases where SemVer is properly followed, your CDN version being a higher minor version should be fine, but going the other way would be an issue if you use new features from a recent minor in your code and serve a previous version from the CDN... your life will be much easier if you keep version synced.
The reduced latency comes from the fact that a CDN will serve files from a POP (point of presence) that is geographically closer to the requester. The reduced latency is a pure physics problem of distance. This doesn't solve other network issues like congestion and throughput limits, but it's a step in the right direction.
The added benefit of serving a popular library from a popular CDN is that you might benefit from a browser cached copy of React being on a user's machine from visiting other websites.
Sir can this CDN approach be followed for css libraries like font-awesome and font-files as well?
In your earlier video you mention "parsing time" of a bundle being the most significant factor, it seems like "parsing time" would be unaffected by this optimization and therefore not have a very significant impact on overall load time if I am understanding correctly?
Why is Webpack supporting EJS and is it mentioned in the Webpack docs somewhere? If yes, where?
I like the feature, reminds me of Flask templates. However! I also want to know where this knowledge comes from and what is EJS and why is it supported :D
What happens if my application in this case app.min.js loads before the cdn ?
Will this add some level of inconsistency ?
Also is there a config/workaround to add externals to the index.html template without having to add each package manually ?