All About Tree Shaking

Home  >>  Javascript  >>  All About Tree Shaking

All About Tree Shaking



Heard of word “Tree Shaking”… Let’s see what it is in flesh and how it can be helpful for front end application development work flow.

What is tree shaking?

Tree Shaking is a mechanism by which we can prune unused/unreachable/dead part of your code from your application as well as from 3rd party libraries during application bundling.

Application unused code:

If you are mostly writing application code, you might argue that all your code is used and that is the truth most often. But that is not the case always. Let’s say you have a util module which exports hundreds of utility functions which can be consumed through out your application. If you are using only 10 functions, then probably its better to remove those remaining 90 methods during production bundling(Not from your code base as you may use those methods in future). This is where tree shaking can help to achieve this.

3rd party library unused code:

However if you are relying on a library, do you use all of it? Let’s take the example of “lodash” library which includes a lot of useful functions, but even if only a single function is actually imported and used, the whole library’s code will end up in the final bundle. Tree-shaking will check for every module which exports are being used and will drop unused ones. If you wonder why it’s called tree-shaking: think of your application as a dependency graph, this is a tree, and each export is a branch. So if you shake the tree, the dead branches will fall. Now it makes sense. Its will make your final application bundle very small to perform better and load faster.

Tree shaking support on languages:

The web development workflow is missing a linking step. A linker’s job is to combine distinct project files into a single executable. A smart linker will only include the symbols and code that are actually used by the application, thus pruning unused code. Languages like C#, Dart, Java, Closure are taking advantages of their linker to perform tree shaking during build process. These tools support tree shaking, a technique to “shake” off unused code, thus shrinking the size of the deployed application. I can import rich libraries chock full of useful goodness into my application, but only the functions I actually use will be included in my generated output. Awesome! Though there are no linkers available for java script, the tools like transpires e.g typescript, babeljs or bundlers e.g webpack, rollupjs are adding this nice tiny feature to enable fronted developers to take advantages of tree shaking.

Minification vs Tree shaking?

Don’t get confused with minification and tree shaking. Tools like uglify is designed to minify your code, stripping unneeded spaces and reduce the length of the variable names. It is not designed to make application level tree shaking. The sole purpose of tree shaking is to drop the unused part of your code from the bundle itself. Of course you can combine them together to get best of both the world. During application bundling just shake it and minify the code which is only includes the bits of code your bundle actually needs to run.

Benefits of Tree Shaking:

  • Tree Shaking helps to remove your dead code during your application bundling
  • Minimize application bundle size
  • Less code to transfer over wire leads to better performance and faster loading time
  • All happens on build time, so no runtime cost involved

You might be thinking If tree shaking is so beneficial, then why adoption rate is so negligible. The fact is that, The tree shaking is very new kid on the modern java script era. As of writing this article(April 2016) only Rollupjs java script bundler has full support for tree shaking and Webpack2 has added tree shaking feature recently which is in Beta. Although this is the starting, Big frameworks like Angular2, Typescript, Babeljs are planning to take advantage of this awesome neat feature. Hope it will be part of standard application bundling very soon along with minification and all.


Having tree-shaking capable build tool and libraries written in ES2015 modules we don’t need to worry about choosing one lib over the other because of its size. What we should do instead is to choose what fits better in our needs and let compiler do everything else.

Follow Me On:

Leave a Reply

Your email address will not be published. Required fields are marked *