/ code

Why you need to separate vendor libraries from application code

Everybody hates slow websites. One of the many things that can cause it is the site's assets are too big to load, hence the overall slow loading.

Screen-Shot-2017-08-18-at-2.57.56-PM

Long load time? Seamless route change ftw!

Above is a Chrome developer tools screenshot of a site built with react, as you can notice the big bundled javascript file size. That big file contains pretty much every view the site can provide, the home page, the account details page, the article page, every view you will or will never see on the site is on that big fat file.

789 KB for a javascript asset is huge compared to server rendered applications like those ones built with Laravel. Because they don't make the browser load unnecessary views like the former does. The server only returns the associated view, most of the times handled by the routes. Sure, loading views all at once can benefit you later when you access other parts of the site because you don't have to download the view again. But for first visitors, first load time can hugely impact the user experience and it can make users decide whether they convert to your loyal visitors or they will never visit your site again, ever.

But, I am not going to cover that. That can be solved by using the same approach as server side applications do, by sending only the associated components for that route. This can be achieved using webpack magic too.

There are other initial-load-related problems that affect react applications too.

Big assets can be a thing, but there are also other thing that can impact load time.

That one big chunk of javascript file contains everything, vendor libraries and application code. If you build a react application, it can contain from the react and react-dom themselves to those niche packages you downloaded like lodash, react-slider and wowjs (because, really, everybody likes those plug and play stuffs).

Imagine one day you made a react application, shipped it, the users already visited and downloaded your site's assets, then you need to make a hotfix for that buggy component of yours. One line fix, hell, even one character fix can force the browser to download the asset all over from the beginning. All that 789 kilo bytes containing just a very slight different must be downloaded all over again.

See, the browser doesn't care whether you changed the entire code base or just one character, as long as it's different, it will discard the cache and re-download the file. It will be so much waste. That's why you need to separate your vendor libraries from your application code. Because then, you don't have to force the users to download already-in-cache-and-there-is-no-new-change code, such as react. The browser only need to download the updated code.

without separating the vendor

vendor separated using webpack

But then it raises some problems like how to seamlessly integrate the work flow, how to make sure that objects libraries from the vendor file can be used within the application code file, etc.

With webpack magic, surely we can! I will post the webpack configuration and logic behind it later.