The Coffee Threshold for Javascript Compilation

           In a modern age where computer is now considered one of man’s best friend, there lives a boy who works as a software developer. He gets up in the morning full of excitement and hurries to the office. Upon arrival, the boy logs into his lovely computer to start bundling his code – combining the javascript files into a single file. He checks that bundling has started and casually walks away to grab a cup of coffee. A few moments later, when he comes back with his aromatic coffee, he notices that bundling has still not finished!

         At that moment, rather than a few sips of coffee running down his throat, he experiences something else rolling down from his eyes. “Sacrilege”, the boy whispers with subtle but clear hints of bitterness in his voice. ‘Slower than a coffee machine? This execution time is a bold mockery in the holy realm of programmers – who are obligated to optimize.’

        Concluding that something must be done, the boy hesitates no more and quickly turns to the ‘savior’ of all coders – Google. ‘Oh thy Google, have mercy on such undignified bundling time.’ Soon after, Google blesses the boy with a Babel Precompilation feature. Too glaringly bright to even glimpse at, the boy humbly accepts the feature and never again has to wait for the code to bundle with a fresh coffee present in his mug. A few days later, still treasuring the moment of epiphany, he seeks out to teach others what he has learned in the hope that no one will ever need to suffer like he did. Okay, so the boy lived happily ever after… Now onto the technical stuff that you were expecting to read.


First, I would like to introduce some terms that are crucial to understanding this blog post: Compilation and Pre-compilation, what they mean and how they are used with Javascript. Javascript, as an interpreted language, doesn’t require a compiler since the browser essentially compiles the necessary parts of the code on the fly. When mentioning compilation in the context of Javascript, it is natural and perfectly safe to refer to it by a different name called transpilation. Transpilation is a process of translating code into a different version of code. In most cases it involves converting a newer version of a language, like ES6 into a more compatible one like ES5, which a greater number of browsers are able to understand. This is where Babel Compilation steps in to compile the original source code so that all the browsers are happy.

The beauty of Babel compilation is well noted; one might wonder why we would need anything else. The thing is that if we stop at compilation only, the boy from our story will forever weep as he waits for his npm script to finish. What is missing? PREcompilation. At a big company such as Hootsuite, we have hundreds of thousands of lines of Javascript code organized into a number of sub-projects. Every day, we merge in files for new features, bug fixes and many more with sprinkles of mystery in every sub-projects. The problem is evident and inevitable – compilation of the entire projects must happen every time to setup a working environment! This is where the Babel Precompilation feature takes charge to change our lives; a programmer’s life is too short to be waiting for entire projects to compile.

The process of precompilation works like this: when updated code receives a green light, it’s merged and is built for a release. While creating this package, Babel steps in to create a compiled version which gets included. Later, users can fetch the package from the remote server to leverage the precompiled files for bundling instead of the non-transpiled code. Simple and yet marvelous. This ensures that Javascript files don’t need to be compiled again and again to support other independent changes. Sure, there will be some time losses to learn and setup the correct environment and possibly frustration down the road for the sake of the gain. However, as I show below, the accumulation of saved time for the developers outweighs the loss to the point where it brings shame to be even mentioned.


To better illustrate the productivity gains brought by precompilation, we’ll use an experiment that will run 10 times with 9 randomly selected projects out of all the projects existing in Hootsuite. Out of the 10 tests, the average of last 5 results will be used for comparison of efficiency. The purpose of choosing the last 5 projects will be to avoid discrepancies caused by file system caching. In each tests, each project will be precompiled separately in separate tests but in the same manner to validate the efficiency of precompilation. However, they will be compiled in order of their project size. The below shows the results observed.

Figure 1. Absolute time observed when bundling with different number of Precompiled Projects.

        We run the first test by enabling precompilation for different numbers of projects, resulting in Figure 1. As the graph portrays, the time for the entire project to bundle decreases as the number of precompiled projects increases. Through a simple calculation, we observe that we were able to save up to roughly 40.11% of the time required to bundle the entire project.

Figure 2. Accumulation of time saved with different number of precompiled projects

        Figure 2 shows the amount of time saved while bundling when different number of projects have been precompiled. Ultimately, with all 9 participating projects precompiled, each developer would be saving roughly 54 seconds per bundling. Assuming 100 developers must bundle their project once a day, we would see 54 seconds x 100 = 1.5 hours freed. This means we will gain an additional 33 hours of productivity in terms of time efficiency within a month (22 business days). Precompilation salvaged a bit less than a week worth of a single programmer’s time per month! This is amazing

Figure 3. Amount of time freed per each precompiled project.

        Figure 3 shows the time freed for each individual project strictly relative to the number of ES6 files in each projects. The graph above illustrates that time saved is not exponential, as other graphs have visually suggested, but linearly proportional to the number of files that need to be compiled. This strongly suggests that as more files are precompiled, more time would be saved, in a linear fashion.


Mind-blowing! It seems after analysis of our experiment that integrating this precompilation feature is a must. But as a project lead, one should not simply integrate Babel Precompilation into their project blindly. For instance, if the project is a big monolith, there is no point of pre-compiling since any changes in the code would result in compiling all the code again. In other cases where there are only a small number of associated projects, the users may not be able to practically tell the difference or benefit from time saved. However, if bundling time takes more than the time for your coffee machine to spit out a cup of fresh coffee, I strongly recommend researching what Babel Precompilation can do for you and your team.

About the Author

John Lim is a Co-op software developer at Hootsuite working within Publisher Team. He studies Computer Science and Mathematics at UBC. He is passionate about Web Development and earnest in learning new technologies. During free time, he would spend his time playing and deconstructing/designing games. Find him here!