Do you need that hot JavaScript library?

With JavaScript libraries and/or frameworks creating uniquely skilled JavaScript developers, it’s more important than ever to focus on foundations.

Kyle Simpson, otherwise known as @getify has a wonderful books series called, “You Don’t Know JS”. One of the beautiful pieces of this series, is the focus of understanding the “why” behind JavaScript in ways other books before haven’t. This series, I think, is required reading for every developer that writes JavaScript for a living. I also believe it highlights a deficiency of our current generation.

So many times, before thoughts of what our public API will look like (you do think about that, right?) or how your event model should behave, we’ve already made the choice that it should use Angular, Ember or some other library of UI widgets.

The simple but often unasked question of, Why?

I was at a talk last year that gave me the wonderful nugget of the question, Why? It’s a very simple question but one we often fail to ask, let alone answer. We’re good with the “what I need to do?” and jump right ahead to the “how I’m going to do it?”, but often fail to address one of the most meaningful questions of all, “why am I doing it the way I am?”.

Why do I need a library to begin with? Why am I choosing this particular library or framework? Why would I use a library over a module I write? There are so many questions to ask, yet I wonder how often any of them cross our minds when approaching a project or task at hand.

JavaScript has made leaps and bounds in terms of respect and applied experience as a true application language. Unfortunately, one of the great things about JavaScript — it’s ease of entry — is also one of the reasons the leap between “what” and “how” is made without a lot of “why” being involved. Planning your approach, before choosing an external library, is something all Front-End Developers should begin making part of their regular workflow routines.

There are many questions to ask ourselves around the approach and strategy behind our code. Let’s take a brief look at five questions you should be asking yourself before you consider what library to choose, and whether you actually need to choose one at all.

* Note: Test Driven Development can help get you in the mindset of regularly asking questions about the structure of your code.

Will there be several instances of this thing on a page?

This question assumes you are going to approach your work in a modular way. If so, you may want to leverage prototypes in JavaScript with your component. By using prototypes you get the benefit of a lower memory footprint, easy extension and patching abilities, and other key benefits that come right along with prototypal inheritance in JavaScript. The unfortunate thing is that many JavaScript developers don’t dig far enough into the language to even understand prototypes and the prototype chain. Beyond performance concerns, we should consider how our thing will play in an ecosystem with other components.

Does this already exist?

If you’re a solo-developer, this question may not apply to you as much. However, if you have the benefit of working on a team with other developers, you should be leveraging the work that they are doing. When pulling a UI inventory together for a style guide, it’s easy to use buttons as an example of where we diverge from standards. How many buttons does a site need, right? The same thing can be said for many team’s code repositories as well. Two or three different JavaScript files that accomplish the same thing. If you are remaking the wheel, it better be because the wheel was square and not just because you don’t want to take the time to either look for, or read, someone else’s code. Reading code is an amazing method of self-improvement, but unfortunately it doesn’t seem to be as much of a practice in the current state of our industry.

How will I, and others, debug this?

If you dive into writing code without considering how you are going to debug it later, you are only causing yourself headaches down the road and generating all kinds of negative vibes every time someone else has the pleasure of stumbling along your code on their project. Maintainable code can be described as many things, but “debugability” is extremely high up on that list. Throw errors when necessary, and make them meaningful. Provide a debug mode for your modules that takes advantage of the browser’s console to print debug messages. Each method you create should be accompanied with the following question, “How am I going to debug this function if something goes wrong?”

Does this library solve the necessary problems that the addition of the library makes sense?

I understand the draw behind using the latest and greatest library. We work in an industry that constantly changes and moves forward. I’m not saying these libraries are bad and shouldn’t be used. What I’m saying is we should be asking ourselves if there are enough development patterns that this library solves where it makes sense to add. If you are working on a new area of a site that has more intricate views with data-binding, don’t immediately jump to a full-blown application library where well-thought, intelligent event models can keep your code lean and easily maintained. Before deciding that you need a library, first consider whether the number of problems it solves is greater than your own capacity, time, or ability to solve the same problems.

How does this library work?

When we choose a library, unless you understand how it works “under the hood” you place yourself in the position of being dependent on someone else’s expertise and knowledge. If you’re choosing between something like Angular and React, have you looked at how each library interacts with the DOM? How about how it does data-binding? Are there performance concerns around any of the approaches this library uses? When we do end up choosing a library, we should have answered the question about “why this library” and have a good understanding of “how the library” solves the problem it does.

The speed at which our industry moves, makes it easy to not force ourselves to slow down and take the time to think and plan about what we are going to do. With that in mind, I’ll end with this quote…

“If you do not know how a piece of code works, then you have no hope of understanding why it broke, or fixing it. You’ll never accidentally exceed your own understanding of this thing.” — Kyle Simpson, @getify on Hanselminutes.