Why separate vendor CSS & JS from custom CSS & JS in a workflow?

Question

I've been trying to determine the reasoning behind what seems to have become the standard practice in Front End workflows of separating vendor JS & CSS from custom JS & CSS. I'm not sure what the benefits are over the disadvantage of an extra HTTP request, it would seem cleaner to just have a single CSS & JS file rather than having vendor.css, main.css & vendor.js, main.js.

Can anyone shed some light on this?

Answer 1

Vendor code typically changes less frequently than your application's code. Thus as you update your application, the vendor code can remain unchanged and cached in your user's browser.

In the scenario where vendor code is bundled with application code, the user has to download all of the vendor code every time you update the application.

The extra HTTP request from the separate vendor bundle is mitigated by the fact that the user will download less code on each application update.

Answer 2

I can think of two reasons.

1. Hosting vendor code separately from your code (e.g. Google Hosted Libraries)
2. Separation of concerns: the vendor code might be large and is updated independently of your custom code. Maintaining your code in a separate file avoids the need to put vendor code into your source control, makes it easier to navigate your code, makes it easy to upgrade to new vendor code since you know for certain the vendor code has not been tweaked.

Especially since you tagged the question with grunt, the end user might never see this change since you can merge vendor and user styles/scripts during the build.

However, if vendor code is large and changes infrequently, you do get a caching benefit from having a rarely changing, large vendor file accompanied by a small, fast changing custom code file. For large sites that do not use a CDN (hopefully, not yours), the impact can be noticeable.