How Do I Evaluate JavaScript Libraries

Earlier this year CODE Magazine published an article I authored encouraging the use of MicroJS libraries instead of large frameworks. One question I attempted to answer was where to find libraries, which of course there are many possible sources. Another question I am often asked is how do I choose a library? This is important because choosing a bad library can lead to bad consequences.

How Do I Evalutate JavaScript Libraries

I have no absolute rules on choosing a library, but I do have some evaluations I make before picking a library. Today I want to review some of the criteria I use and some simple examples of how they apply to choosing the best JavaScript libraries for your application.


One of my favorite JavaScript library sources has a rule, all libraries must be under 5kb minified and gzipped. Personally I think 5kb might be too generous. Why is size so important? Script evaluation and HTTP requests take longer for larger files. The concept of a larger file taking longer to load over the Internet should make sense to everyone. JavaScript evaluation is an often overlooked issue, but should be considered. When JavaScript is loaded and evaluated it is a blocking action, which means the browser stops everything while it loads and evaluates a script. Smaller scripts are better.

How Do I Evalutate JavaScript Libraries

However load time performance issues are not the only problems a large library owns. The larger a library or fast food framework is the more the library tries to do. This means the browser needs to request and process more code than the application needs to perform what ever it is you are trying to do. Plus as the library solves more problems you your application will surely use a smaller percentage of the code. This means you are shipping dead weight code. I call this web fat.

Web pages are fat enough and need to go on a serious diet. Think of all the unused code you download as belly fat. It has been said, 'we have created the web in our own image, obese'. According to HTTP archive the average web page is 2MB. Think about that amount for a second, the average web page would not fit on a 3.5" floppy disk from the 90s. JavaScript is accounting for roughly 300kb. While 15% of the payload, it is still significant and can be reduced in both size and number of HTTP requests.

The Obese Web Guy

The size or weight of a single library or framework in itself is not the complete problem, but rather an easy way to measure the problem. The size is indicative of more problems, I like to think of it as saturated fats and processed sugars. A good JavaScript library should solve a single problem and nothing more. Once you start adding adjacent problems you start building a framework. When you have a one size fits all framework you have a lot of code that never gets executed in 99% of applications. Size is the #1 reason why I eliminate fast food JavaScript frameworks. I know they are trying to do too much and I know my application needs to be lean and fast. Instead I find libraries that solve the application's problems and apply good architecture. The result is complete applications that use less JavaScript than even the smallest fast food frameworks.


In the past I relied heavily on jQuery, I loved it. I still have a big developer crush on jQuery, I just do not use it in my applications anymore. Several years ago I needed to architect a mobile web application that loaded quickly. Like most developers I added jQuery to the code. I began to feel the performance drag rather quickly on phones. After some quick evaluations I realized my best friend was a big problem and I needed to remove it from the application.

Purging jQuery was a emotional process, jQuery is so awesome. But alas it is big and not designed well for a modern web application. After doing some research I learned how easy it was to access the DOM using document.querySelectorAll and other native functions. Native APIs are 10s of thousands of times faster than jQuery and they require no extra JavaScript. Plus all browsers support the same native APIs.

This left the bulk of my jQuery usage to AJAX. Again some quick research lead me to an AJAX library that implemented the jQuery AJAX function interfaces, reqwest. Compressed Reqwest is merely 3.4kb and offers rich AJAX functionality. I still use this library is many applications because it makes other developers and architects feel 'safer'.

I have shied away from Reqwest on my own applications because AJAX can be fully executed in around 20 lines of code. I did that on this Blog almost 2 years ago. The way I design my applications I can replace these small libraries quickly because I tend to abstract libraries behind providers. Replacing a dependency like reqwest with another solution is very simple. This is one advantage modular architecture provides, the easy exchange of libraries and solutions. Remember your application will evolve and you cannot predict how it will evolve. What I can tell you is your customers should drive those changes.

Today I use DollarBill, a jQuery like library I wrote one Saturday afternoon. It is 12kb minified. It does everything I used jQuery for, short of AJAX. It is extensible so the plugin model still works. I am not the only one doing this, there are many other jQuery like libraries available. Thomas Fuchs, the Microsjs site owner, created Zepto, a very popular jQuery like library. Another one I recently found is the Filament Group's ShoeString. jQuery is over 110kb today, DollarBill 12kb, that is a big difference.

Size calculations do not stop with the JavaScript. Does the library use CSS, HTML, Images, Fonts? All of these add weight and more HTTP requests. All of this needs to be part of the size evaluation process. Performance is #2 behind easy navigation in end users expectations. Slow sites convert less, have lower SEO and lead to poor brand recognition.

How Big is Too Big?


This one depends. I try to stick to the Microjs 5kb rule most of the time. However DeepTissue fails this test, but not by much. As a disclaimer I wrote DeepTissue. I use DeepTissue when I have many potential mouse and touch gestures in an application. If I only need to react to a user tapping or clicking the mouse I use a custom form of FastClick. Deeptissue defaults to pointers and falls back to the touch then mouse APIs to capture user inputs. Once Apple gets on board with Pointer Events Deeptissue and be removed and my applications will be even leaner.

When an application comes together I tend to look at the bundled and minifies file size. I don't usually consider the gzipped size because this can vary based on the compression settings. I have many single page applications under my belt and I have a decent feel for how large an application 'should be'.

This Blog for example I would consider an average size. The bundled and minified JavaScript is 45kb. It compresses to roughly 13kb. I have plans to update the entire application in the next few months. I hope to have less JavaScript, but I a betting the size will be very similar in the end. 13kb is a great size because it fits within a single HTTP packet, which leads to an 'instant' effect detailed by Ilya Grigorik. The 14kb file size should be your ultimate goal.

Recently I helped launch a 75 view application with around 120kb of JavaScript. The average controller was just under 2kb before minification. There are base 'classes' being used, which help abstract common controller functionality. The applications bulk comes as much from its breadth as third party libraries. However using small third party libraries helped keep the application size in check.

Large libraries and frameworks are a quick criteria I use to evaluate if the source is usable or not. Size has performance implications, but it also hints at bigger code smells that should be avoided. Try to stick to the rule of 5kb or less. In the end you will be much happier with your application's user experience and your development team's intimate knowledge of how everything works.

Path To Success

How difficult is the library to use? Can I solve a simple problem quickly? The typical problem developers need to solve is simple and often the code to solve these problems is simple. A library should make solving a problem even easier. A library is a refactored, reusable solution to a common problem.

So when checking out a potential library I look at any documentation or demos I can access. Is there some sort of complicated configuration step? Do I need some sort of pre-compiler to translate my code to real code? Are there a lot of complex functions involved? Too many yes answers and I will look for other solutions.

When I wrote DeepTissue I wanted to make sure it was stupid simple to use. It looks like jQuery and has methods extended off the deeptissue object. I wanted a pattern most developers would feel comfortable using. The library includes default settings so you do not need to adjust anything you do not want to adjust. It should just work out of the box.

var dt = deeptissue(".taget-item").tap(function(e){...});

The library's complexity is hidden behind the simple interface. You as the consumer developer should not need to worry about all the stuff the library abstracts away. The library takes care of the common code and gives a simple means to execute.

I find developers tend to use this as the sole criteria in evaluating a library or framework. They tend to look for something that 'feels cool' for lack of a better term. They want a developer friendly syntax. Unfortunately this approach is completely invalid for user experience. Sure you want developers to be productive, but with out sacrificing user experience. Too often popular libraries and frameworks are designed developer first and throw the customer under the bus. You should never sacrifice the customer, they pay your bills.

If I am unable to quickly solve my problem I am moving on to the next option. If the solution creates performance and usability issues, that trumps any developer comfort. My experience tells me there is always a more efficient way to solve the problem.

External Dependencies

A library with an external dependency is a bad sign. To me it says the author does not understand the browser enough to make an efficient solution. It also means the small library I was looking for now is much larger. For example I will not use Bootstrap's components because they have a jQuery dependency. jQuery of course violates my first rule, size, so having a hard dependency on jQuery does not work.

In a recently released book, High Performance Responsive Design, Tom Barker points out the minimal Bootstrap install is 220kb between the library's CSS, JavaScript and jQuery dependence. Sorry but most of my applications' code bases should be far smaller than that. You can use just the parts of Bootstrap you want. I recommend sticking to the CSS and avoiding the JavaScript. Use a tool like UNCSS to isolate just the CSS being used. Often you will find you only need 10% or less of Bootstrap.

An alternative is a responsive CSS library called Skeleton. It weighs 13.2kb and has no external dependencies. It does not include predefined components, but again that is OK because you most likely would not use them if they were included.

When a library can stand by itself you can continue to utilize the code while your application matures. As an application matures the architecture evolves and eventually various libraries are removed or replaced. When a library is the only reason you are holding onto another library you should rethink the first library.

A library should be very focused on solving a single problem, not everyone's problems. It should be written to leverage the browser's native APIs, not an additional third party library. More often than not I look through a library's source code and pick the code I need and write my own library, without dependencies. I recommend this exercise because it will make you a better web developer because you learn how to read other people's code, understand the native APIs better and learn to write your own libraries.

Memory Leaks

Modern web applications are more than just markup rendered on the server. They are living beings and a single request last far longer than a classic web page. When jQuery emerged developers began building rich user experiences. These efforts were more enhancements to a static web page than a full blown application. Today we have full blown client applications designed to rarely leave the browser. My standard is having an application strong enough to live without being refreshed for a week.

A problem developers are just now starting to discover is memory leaks. Unfortunately tracking down JavaScript memory leaks is more of a dark art than a science right now. Like any application if the garbage collector is not able to purge unused memory references the application creates a large memory footprint. As this footprint grows it causes the platform, in this case the browser, to hit a limit. At that point the application crashes. As the memory grows performance becomes sluggish. These are undesirable features.

Chrome Crashing

Recently I took some time to record a video on chasing a simple memory leak in my Panorama library. It shows how overlooking a simple variable reference can lead to a big problem. The video demonstrates how to utilize Internet Explorer's memory profiling tools to identify leaking code.

When I encounter problems with a web site or I want to see how a library is used I often profile a site. When evaluating libraries I like to find web sites and applications that use the library. Recently I have been evaluating React, a templating library Facebook created and shared with developers. Profiling Facebook should give me a good idea how well React handles memory leaks.

Facebook Memory ProfileFacebook Memory Profile after scrolling the news feed

In these two screen shots you can see opening Facebook and just scrolling the news feed creates many leaks and growing memory profile. This explains why I can crash mobile Safari with ease while visiting Facebook. Give me more time and I can crash any browser on the desktop too. If you scroll through the news feed for an extended amount of time you eventually experience sluggish behavior. These are all signs of memory leaks. This exercise should also serve as a black mark against React because Facebook should be the best example of using React since their engineers created the library.

Facebook Memory Profile in Chrome

I don't want to pick on React, all the major JavaScript frameworks and libraries are riddled with memory leaks. My libraries can have leaks, I try to make sure they are resolved before completing my work, but sometimes they get through. It takes discipline and pride to keep leaks out of your code. When using other people's code for your application you need to do diligence before adding the code.

The leak issue is a major deciding factor for me because it can be so damaging across an application's life span. Leaking memory means your application will have a poor user experience or at least one that never lives up to its potential. Ensuring the code you did not write does not cause unwanted leaks is part of building a good application.

Read The Code

One of the open source promises is the freedom to read other people's code. You could be reading it for security purposes, but you should be reading it for educational purposes. When I use a library or new framework I try to spend some time in the code. You can learn many things by seeing with other developers do. You also might realize the cool library you wanted to use is not that cool after all. The more you understand how to write good JavaScript and CSS you can start to spot poor coding practices. Again code smells tell me the library might not be a good choice. Think about poor code as trans fats or junk food. While many of us eat crap like cheesy poofs, we know we shouldn't.

A few years ago Paul Irish released a couple of videos I love. They go into the jQuery source code and demonstrate some best practices I was able to start applying to my day to day workflow. I became a much stronger web developer because Paul showed me how to read the jQuery source code.

-10 Things I Learned From the jQuery Source Code-11 More Things I Learned From the jQuery Source Code

Last summer I was forced to work with Angular, which of course I do not recommend. As I read through the code I was appalled. There were some good techniques, do not get me wrong, but I saw so many other bad things. One obvious thing I saw was recreating the native validation API, completely wasted bytes across the wire. I wont go into the details, because honestly I put it behind me, but there were many other issues.


On the other hand I like Bootstrap's CSS. It is well organized and designed to be custom built. The library is available in a modular format, which means you can use just the parts you need, like buttons. If I were to name good reference projects Bootstrap would be one.

I think it is a best practice to take some time and read the code you are using. You will learn and identify potential issues. When you become a better programmer you write better applications. You also become better at evaluating other people's code. The applications you produce will be stronger because of the effort. So take at least an hour or two each week and read other code.


This should be obvious, but does this library solve my problem in multiple places? If I only have the problem once, then would I be better off extracting the core solution and leveraging that code or technique than adding another library? If the library is not reusable it is not that useful to me. Even when I need a UI library in one place I want the library to something I could use on other projects. If it solves a problem in multiple places this is a big plus. If it does so much I need another solution for a very similar problem the library fails my evaluation.

jQuery is a good example of being reusable. jQuery is a DOM node's Iron Man suit. It empowers a DOM node to do more than it can natively. The library can be applied to any DOM node and of course be used across any application. This is what you should look for, reusable value.

Write A Solution Yourself

There is nothing saying you cannot write your own solution. You need to write code at some point. A good carpenter has at some point created one or more custom tools to help their process. All libraries and frameworks start somewhere, with a developer wanting to make a better solution. The web development space is a wonderful breeding ground for entrepreneurial spirit. The barrier to entry is low and its ok to fail fast.

I have critics that think I should not create custom libraries. They can hate all they want, I enjoy the process. Being nothing more than an assembly line worker is not real fun to me. There are not always libraries available to solve my problem enough to be my choice. Creating libraries and making them public has made me a better developer. There are many libraries I do not make public because they are nothing more than quick fixes or just plain bad solutions. They have all taught me something and I encourage this attitude.

If it were not for thousands of developers publishing node modules Nodejs would not be what it is today. NPM drives the node echo system, making it valuable. My hope is there will be a similar ASP.NET vNext ecosystem developing in the coming year. Do not be afraid to roll your own solution, at worst you will learn and become better.


A modular client-side architecture is very beneficial because it provides the ultimate flexibility as the application matures. You can replace and remove modules as requirements change. Poor libraries can be replaced with stronger options. An application loads and typically performs much better due to the lower size and profile. Memory leaks can kill and application so evaluating libraries for memory leaks is a required evaluation step. A library should be easy to use and solve a single problem. It should be reusable to provide maximum value, even when the problem only exist once. Reading a library's code and writing your own solutions makes developers stronger. Better developers can solve problems faster and improve existing code as the application iterates over time.

Choosing good libraries or frameworks is important to the application development process. The more modular the better because mistakes can be easily corrected. There are thousands of potential problem focused libraries available as well as writing more personal solutions. Always perform a minimal evaluation that goes beyond just writing code using the library. Hidden problems are not revealed by writing code, you need a run-time evaluation to know if the library or framework is a good option.

Share This Article With Your Friends!