Libraries and Lazy Coders - How To Make Better Software With Less Effort

If I have seen further, it is by standing on the shoulders of giants. -Isaac Newton

TIME LIMIT: 90 MINUTES

Everytime you insert <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/normalize/8.0.0/normalize.css"> into the HEAD of an HTML document, you are using a library. You are importing someone else’s code and using it.

With just one line of code, importing Normalize.css makes our webpages more functional and prettier. If you don’t believe me, go delete the Normalize.css LINK tag and take a look at any of our pages. Elements will have visibly shifted, and the page will look much less polished. If you follow the cloudflare.com link in the href attribute, you will find the 314 lines of CSS code (version 8.0.0) that all of our webpages have been using without us having to write it. Free code. Pretty handy, right?

In this chapter, we discuss libraries, and the who, what, whens, wheres, whys, and hows of using them.

What Are Libraries?

A library is basically any software unit that a separate piece of software can import into its own system and use. There are millions of software libraries in the world. It’s a pretty loose term, though not quite a buzzword.

The most commonly used libraries often follow an open-source software model. This means that the source code for these libraries is available for you to use free of charge. There are sometimes restrictions on what exactly you can do with a library depending on which precise license the software is offering (especially when it comes to redistributing the code), but everything you run into in this book has an MIT license, which means you can do whatever the fuck you want with the code, so long as you leave the copyright information in the file.

So, in a nutshell:

Libraries are free, pre-written code you can use.

There are a lot of libraries.

If you are making commercial software for distribution, you should pay attention to what kind of license they come with.

Why Should You Use A Library?

There are many different reasons to use software libraries, especially open-source ones.

Save Time, Move Faster. If you go look at the Normalize.css (version 8.0.0), it is 341 lines of code long. That is 341 lines of code we didn’t have to write to get the functionality this library offers.

Many Minds. Open-source software is built by communities of people. If you use it, you get the benefit of many people working on a problem. Someone has almost always tried to do whatever you’re currently trying to do - often many someones. Most of the best programmers routinely contribute to open-source software. You get the benefit of their more sophisticated solutions. You prevent yourself from making mistakes that someone else has already made and fixed.

Learning. Especially in your early career, seeing how experienced programmers have divided and conquered a problem is often enormously instructive. Libraries often make use of common software design patterns.

Better Software. All of these reasons combine into you making better software. It will run better and have fewer bugs. Your users will have a better experience using your software system because you used libraries. And it is important to think of the users, after all.

Why Should You Not Use a Library?

There are great reasons to not use a library. Here are some:

Don’t use a library unless it solves an existing need or problem. You should never, ever add a library if it isn’t obvious what it is going to do for your software system. Junior programmers often reveal their naiveté by enthusiastically endorsing the addition of a “hot, new library” without being able to articulate why it solves a need

Software Bloat and Dependency Hell. Every time you add a library, you create a new dependency for your software system. You have added something (the library) without which your system can no longer function correctly. And guess what? Every dependency you add could have its own dependencies. This raises a whole host of issues, including making your software codebase grow out of control, sending you into a time-sucking, development-killing tailspin of satisfying dependencies just to keep your bloated system afloat. Too many dependencies can overwhelm your system, ruining your ability to make material improvements. This is how many projects die. You must be willing to say “I don’t think this library gives us enough functionality for the 3 million lines of code it adds as a dependency to our application.”

"Dependencies" by XKCD.

The library has been abandoned. You don’t want to use a library that nobody else is using. If nobody else is using it, then you have lost the “Many Minds” advantage above. There is no community answering questions on Stack Overflow or GitHub Issues. There is no community working to improve the codebase against future changes, which is terrible - the world of software is changing all the time.

How Do You Choose a Library?

There is no one perfect method for deciding whether to use a library and which library to use. You have to weigh the advantages and disadvantages. A decision to use a library should generally progress along the following stages, which I have accompanied with some internal monologue about how I decided to use Normalize.css.

  1. Recognize that your software system has a need.

I need this webpage to override the browser presets. They are messing up my HTML and keeping me from implementing the mockup.

  1. Evaluate whether you should write custom code or look for a library.

I don’t know what all of the browser presets are. I will have to research that, which will probably take an hour. Even then, I can’t be sure I found all of the presets for every browser my users will use. There are likely to be bugs I missed in the future. When I read Stack Overflow and searched Google, everyone recommended using a library.

  1. Find some library candidates.

Everyone on Stack Overflow mentioned Normalize.css and reset.css. A Google search confirms those are leading candidates. My mentor recommended Normalize.

  1. Evaluate each candidate.

Normalize has an active GitHub to which a commit has been recently made. The repository has been starred over 30,000 times. When I look it up on a package manager site like npmjs.com, I see that it’s been downloaded over 100,000 times in the last week.”

Reset.css seems to be a project in limbo. The GitHub is not very active, and it has far fewer downloads.

The codebases are both very minimal and don’t add significant bloat by themselves.

They do slightly different things - Normalize leaves some “useful” settings, while Reset seeks to remove all browser presets.

I was able to find a Stack Overflow question on “Normalize.css vs Reset.css”. The community is more in favor of Normalize. I browsed the documentation for both for about 5-10 minutes each, and Normalize’s docs are far better. If I have a problem in the future, I am more confident that I can find the answer with Normalize than I could with Reset.

  1. Make a decision.

I will use Normalize.css.

  1. Document it and track your dependencies.

In the README for a project:

I used Normalize.css version 8.0.0 (over Reset.css) because some browser presets need to be removed. The codebase has a small footprint, does the job, and has an active community.

How To Interface With Libraries: “Design By Contract”

To use a library, you first must import it into your codebase. With normalize, we import via a LINK tag. In a language like Python, you would add something like import normalize at the top of a code file.

With some libraries, all you have to do is the import - the code will automatically run and everything is working for you. Normalize is like that. The CSS page is loaded into the browser and then, because all of the selectors the Normalize stylesheet uses are plain old element selectors, it just works.

Most libraries, though, require more out of the coder. A library will import many specific pieces of code, then you pick and choose which pieces of code to use. The library makes these pieces of code available by implementing an interface. Interfaces can take many different forms, but they all make a contract with the coder - “If you use our code under such-and-such conditions and give it such-and-such inputs, you will get this result.” This is called design by contract.

In the next chapter you will use the Bootstrap CSS library. Bootstrap’s interface is HTML attributes you can apply – its contracts say things like “If you apply the attributes class="alert alert-danger" and role="alert" to a DIV, we will put a red background and border on that DIV for you.” Thus you get the functionality of those CSS rules without having to write the CSS yourself.

Recap

Libraries are great. Use them. Thoughtfully.

Exercises

  1. Because most software systems have dependencies, there is tremendous demand for “dependency management” solutions. Solutions often take the form of “package management systems” - centralized hubs where standards for software packages are set and where they can be downloaded. The standards always include versioning requirements, so you can make sure you’re getting the correct version of the software you want.

Which version of Normalize are we using?

  1. These package management systems also often include useful information about how much that software is being used. Go to npmjs.com. When you look at the “jquery” project, what useful usage information can you find?

We will learn more about package management in Part 4.

  1. Go find the GitHub page for Normalize.css. Do the following:
    • Look at the pull requests tab for the repository. Run the search filter is:pr is:closed is:merged in the search bar. As of this writing
    • Find the GitHub Issues page. Read the discussions on at least 3 issues.
  2. Let’s try a little “systems thinking”. Can you think of other reasons why separating code out into different units could help you write better software in less time?

The principle of separating code into different files or packages of functions (we’ll get to functions in Part 4) applies across the entire world of code, from how a single file is organized to how an operating system’s files are organized to how huge systems separate themselves into smaller subsystems.

  1. Buzzwords to use when talking about libraries:
    • components
    • modules
    • functionality
    • interface
    • separation of concerns
    • technology stack (AKA stack AKA tech stack)
    • design by contact
  2. Spend a minute reading about the MIT license: https://tldrlegal.com/license/mit-license