Standing on Shoulders

The Collected Wisdom of Every Programmer Before You

Imagine hiring a contractor to renovate your kitchen. You could start by explaining what wood is, how screws work, the principles of load-bearing walls, and the chemistry of paint. Or you could just say “I need new cabinets installed” and trust that they already know all that. The second approach, you’ll notice, tends to produce kitchens faster.

Libraries in programming work the same way. They’re collections of code written by other programmers, people who already solved a particular problem and wrapped the solution up neatly so you wouldn’t have to. Instead of building everything from first principles, you get to stand on top of what they already worked out.

This isn’t cheating. This is how all software is built. Every program you’ve ever used (your web browser, your phone apps, even the operating system humming away beneath your fingers) is constructed on layers of code written by other people. Libraries are how we build complex things without everyone laboriously reinventing every wheel, every time.

What Are Libraries?

A library is pre-written code that you can use in your programs. Think of it as a toolbox. You don’t forge your own hammer every time you need to hang a picture. You use the hammer that someone skilled in hammer-making already crafted and made available.

Remember when you learned about functions, how you could define a skill once and invoke it many times? Libraries are just collections of functions (and other code) that someone else wrote, tested extensively, and shared with the world. A charting library knows how to turn a column of numbers into a graph. You don’t need to understand the rendering pipeline, the color theory, or the layout math. You just need to know how to ask for what you want.

Using Your First Library

JavaScript ships with a set of built-in objects wired straight into the language, no installation required. They’re not so much tins you forgot you’d bought as fixtures already built into the kitchen: Math, Date, JSON. Open a console anywhere JavaScript runs and they’re simply there.

Notice there’s nothing to import. Math is a global object that exists from the moment your program starts, and you reach for its functions by writing Math.functionName(). The dot means the same thing it always does: “from this object, use this thing.” No setup step, because there’s nothing to set up.

The Date Object

Working with dates and times is surprisingly complex. Treacherous, even. Time zones, leap years, months of varying lengths, the occasional leap second. It’s a mess. The Date object handles all of it for you, having absorbed the suffering so you don’t have to.

Notice new Date(). No import, no prefix to strip away, just a built-in constructor you call directly. If you need to format the result nicely for a particular locale, the Intl object (also built in, also import-free) picks up where Date leaves off.

The Math Object

Mathematical operations more sophisticated than basic arithmetic live here. You could implement square root yourself, but why would you? Math has already done it, accurately and efficiently, with edge cases you haven’t yet imagined.

The functions in libraries aren’t magic, though they may seem that way at first. They’re just functions some programmer wrote, using the same language you’re learning. The difference is experience. They’ve dealt with edge cases, optimized for performance, and handled errors you haven’t encountered yet. You could write these functions yourself eventually. But you don’t need to right now, and that’s the point.

Installing External Libraries

The built-ins are useful, but necessarily limited. The real power comes from external libraries, code written by programmers around the world and shared freely, like gifts from strangers who happen to be experts. This is also where Node.js enters the story: Node is the JavaScript runtime that lets your code run outside a browser, on your own machine, and it comes bundled with the tool you need to pull in other people’s work.

To install external libraries, you use a tool called npm (Node Package Manager). It ships with Node, so if you have Node installed, you already have it.

Making Web Requests

Making an HTTP request in JavaScript isn’t the ordeal it used to be; both Node and the browser ship a built-in fetch() function, no install required. But a library like axios still earns its keep: automatic JSON parsing, clearer error messages when a request fails, request timeouts, and a handful of other conveniences you’d otherwise write by hand, every time, in every project. Three lines, done before the toast pops. This compression of complexity into simplicity is the entire point of libraries, even when the language already gives you a head start.

Popular Libraries for Beginners

As you continue programming, you’ll encounter these frequently:

• axios: Fetch data from websites and APIs
• sharp: Create, edit, and manipulate images
• phaser: Build simple 2D games
• express: Create web applications
• lodash: Handy utilities for working with arrays, objects, and data
• chart.js: Create charts and graphs

Each of these represents hundreds or thousands of hours of work by expert programmers, left on the doorstep for anyone to pick up. The generosity is breathtaking when you stop to consider it.

Reading Documentation

You discover what a library can do by reading its documentation.

Every well-maintained library has documentation: instructions for how to use it. Think of it as the instruction manual for your tools, though often considerably more thorough.

Finding Documentation

Search for “javascript axios documentation” and you will find the official site. Or look on the library’s GitHub repository. Most popular libraries have clear, detailed documentation, written by people who genuinely want you to succeed.

Anatomy of Documentation

Good documentation typically includes:

• Installation instructions: How to install the library (usually via npm)
• Quick start guide: A simple example to get you started
• API reference: Detailed information about every function, class, and method
• Examples: More complex use cases and patterns
• FAQ: Answers to questions that many people have asked before you

Tips for Learning from Documentation

• Don’t try to read it all at once. Documentation can be overwhelming. Start with what you need right now.
• Try the examples. Don’t just read. Type them out and run them. See what happens. Break them deliberately.
• It’s fine to search online. Documentation is authoritative but sometimes dry. Blog posts, tutorials, and Stack Overflow answers often explain things more accessibly.
• Pay attention to version numbers. Libraries change over time. Make sure the documentation matches the version you installed, or confusion will follow.

AI and Libraries

AI coding assistants know about thousands of libraries. Instead of searching npm or scrolling through documentation, you can describe what you need: “I want to download a web page and extract all the links” or “I need to read data from a CSV file.” The AI will suggest appropriate libraries and show you how to use them. It won’t always suggest the best option, but it’s a remarkably efficient starting point.

When to Use a Library vs. Writing Your Own Code

This is a balance you’ll develop with experience. Here are some guidelines from people who’ve made mistakes in both directions.

Use a Library When:

The problem is well-solved. Dates, time zones, HTTP requests, image processing: these are complex problems with many edge cases, each one a trap waiting to spring. Libraries handle them comprehensively because someone has already fallen into every trap.

Security matters. Encryption, password hashing, authentication: don’t try to build your own. Use libraries written by security experts who understand the threats. Your amateur cryptography will be broken by amateur cryptanalysts. (This is not a theoretical concern. It happens constantly.)

You need performance. Libraries for mathematical operations, data processing, or graphics are often written in faster languages (like C++ or Rust), compiled down to WebAssembly or wrapped as native bindings. You can’t compete with decades of optimization.

It’s not your core problem. If you’re building a recipe app, generating PDFs of recipes isn’t your unique value. Use a library for that; focus your effort on the recipe features that make your application distinctive.

Write Your Own When:

You’re learning. Want to understand how sorting works? Implement it yourself once. Then use the library version in real projects, having gained appreciation for what it does.

It’s genuinely simple. If a function is three lines of basic code, a library might be overkill. You’re adding complexity to avoid complexity, which is rarely wise.

It’s your unique logic. The business rules specific to your application are precisely what you’re here to write. Libraries provide general tools; you provide specific solutions.

No library fits. Sometimes you genuinely need something that doesn’t exist yet. That’s when you write it, and maybe share it with others who face the same need.

Libraries are tools, not crutches. Use them to build things faster and more reliably, but understand what they’re doing conceptually. You don’t need to know how to forge a hammer to use one, but you should know what hammers are for, and when a screwdriver would serve you better.

The Left-Pad Incident

In 2016, a developer removed an 11-line library called “left-pad” from npm, the very registry you’ve been installing packages from all chapter. This tiny library did one simple thing: it padded strings with characters on the left. Trivial functionality. The kind of thing you could write yourself in minutes.

Thousands of major projects broke.

Why? Because they didn’t depend on left-pad directly. They depended on libraries that depended on libraries that depended on left-pad. The dependency tree was so deep that nobody realized this 11-line function was holding up significant portions of the JavaScript ecosystem.

This incident revealed an uncomfortable truth: we build enormous towers on tiny foundations, and we don’t always know what’s holding us up. Every library you use is a dependency. Your code depends on it. And that library might depend on other libraries. This tower of dependencies is both powerful and precarious, the bottom card in a build you didn’t stack yourself.

Security and Trust

Every dependency is trust extended to strangers. So before you invite a library into your code, do a little vetting. Is it maintained? Is it popular? When was the last update, and are people’s issues actually being answered or just piling up unread? More users generally means more bugs already found and fixed, better documentation, and more people who can help when you get stuck. npm is generally safe, but a quick look at who’s behind a library never hurts. And never, ever try to roll your own cryptography. That way lies tears.

Version Numbers Mean Something

Take a closer look at a library’s version number: 2.4.7. Those digits aren’t decoration. This is semantic versioning, a quiet little protocol between the people who write libraries and the people who use them. The format is MAJOR.MINOR.PATCH. A PATCH bump (2.4.7 to 2.4.8) means bug fixes: nothing should break. A MINOR bump (2.4.7 to 2.5.0) adds new features but plays nicely with your existing code. A MAJOR bump (2.4.7 to 3.0.0) means breaking changes, so code that worked yesterday might not work today. When you see a library leap a major version, tread carefully. And version 0.x.x is its own warning label: experimental, unstable, liable to rearrange the furniture while you’re out of the room.

Standing on the Shoulders of Giants

There’s a peculiar human tendency to want to build everything yourself. It feels more authentic somehow, more “real.” You didn’t really make that chair if you used wood someone else cut, right?

In programming, this tendency will destroy you.

Every functioning software ecosystem operates on a simple principle: we build upon what came before. The web browser you’re using to read this doesn’t reimplement TCP/IP from scratch every time you load a page. The operating system doesn’t reinvent memory management for each application. The JavaScript engine running your code doesn’t rewrite its garbage collector with every version.

This isn’t laziness. This is civilization.

Think about what happens when someone creates a truly excellent solution to a common problem. Maybe it’s parsing JSON data. Maybe it’s handling HTTP requests. Maybe it’s rendering images. Someone spends weeks or months understanding the edge cases, optimizing the performance, fixing the security vulnerabilities. They package it as a library. They share it freely.

Now thousands of programmers don’t need to spend those weeks. They can dedicate that time to their actual problems instead. The time saved would fill a calendar you could never reach the end of. It’s like having access to every expert in the world, simultaneously, for free.

This is the power of open source. Shared knowledge that compounds. Every solved problem becomes solved for everyone. And unlike physical resources, code can be copied infinitely without diminishing the original.

You’re not “cheating” when you import a library. You’re participating in humanity’s collective technical knowledge. You’re standing on shoulders that want to be stood on.

Language and Ecosystem

When you choose a programming language, you’re not just choosing syntax. You’re choosing an ecosystem. JavaScript’s greatest strength isn’t the language itself. It’s the millions of packages on npm, the largest software registry in the world. Python’s ecosystem is PyPI, leaning heavily toward data science and scripting. Go’s ecosystem is optimized for servers and distributed systems. Popular languages attract library authors, which attracts users, which attracts more library authors. The rich get richer. This is why teams often stick with languages even when alternatives might be technically superior. Leaving means packing up a house you’ve lived in for years.

You’re Part of the Ecosystem

The functions you write are no different from library functions. They’re the same concept at different scales.

You’re creating reusable skills, exactly as library authors do. The only difference is scope. Your function might be used in one project; a library function might be used in thousands. But the fundamental act, solving a problem once and making that solution reusable, is identical. A library, when you get right down to it, is just a function that got famous.

As you gain experience, you might:

• Extract useful functions into your own personal library
• Contribute improvements to libraries you use
• Publish your own library for others to use

The ecosystem of libraries exists because programmers share their work. Every library author was once a beginner learning how to use code written by others. Now they contribute back. The cycle continues, and civilization advances.

Real projects keep their history with version control tools like Git: how you track changes, undo your own mistakes, and work alongside other people without trampling each other. We’ll get to that in Chapter 12.

What Lies Ahead

Look at what you can do now: read code, work with AI, organise data, hunt down bugs, and pull in the collected labour of every programmer who came before you. That’s a real toolkit. It’s time to build something with it.

Next, we’ll get into interactive programs: applications that respond to what the user does, remember things between one moment and the next, and feel genuinely alive. You’re ready to make tools that people can actually use.

Next: Chapter 9 - Building Interactive Programs