DEV Community

Cover image for What I Learned from Reading JavaScript: The Good Parts

What I Learned from Reading JavaScript: The Good Parts

What I Learned from Reading JavaScript: The Good Parts

I recently finished reading JavaScript: The Good Parts by Douglas Crockford.

Even though the book was written in 2008, and javascript is much more capable now i really wanted to understand how things evolved with time and as engineer whose most time has been writing web development i really needed to know what's good and bad about the language i use

Here are the biggest lessons I took away.

1. Functions are first-class values

This was probably the biggest mindset shift.

Functions aren't special syntaxβ€”they're values.

You can:

  • store them in variables
  • pass them to other functions
  • return them from functions
  • create functions that create other functions

This idea explains callbacks, higher-order functions, currying, modules, and closures.


2. Closures are one of JavaScript's superpowers

An inner function remembers variables from its outer scope even after the outer function has finished executing.

Once this clicked, concepts like private state, factories, memoization, and modules became much easier to understand.


3. Objects inherit through prototypes

Objects don't inherit from classes.

Every object has an internal prototype link, and property lookup walks up the prototype chain until it finds a match.

Modern JavaScript gives us tools like:

Object.create()
Object.getPrototypeOf()
Enter fullscreen mode Exit fullscreen mode

to work with prototypes directly.


4. this isn't determined by where a function is written

It's determined by how the function is called.

That single rule explains most of the confusing behavior around this.


5. JavaScript has some dangerous features

Some language features are better avoided:

  • eval()
  • with
  • wrapper objects like new Boolean() or new String()
  • implicit global variables
  • == when === is what you actually want

Just because something exists doesn't mean it should be used.


6. JavaScript was designed with some historical baggage

Understanding these quirks makes many "weird" behaviors less mysterious.

Examples:

  • typeof null === "object"
  • numbers are IEEE-754 floating point values
  • floating-point precision issues (0.1 + 0.2)
  • strings are UTF-16, so emojis can occupy two code units
  • NaN is contagious

7. Readability matters more than cleverness

One quote that stuck with me was the idea that:

If you can't easily read the program, you can't confidently predict what it will do.

Many of Crockford's recommendations ultimately come down to writing code that's easy for humans to understand.


8. Simplicity beats feature count

One analogy from the book that I liked:

My microwave has dozens of buttons, but I only ever use Cook and Clock.

The point wasn't about microwavesβ€”it was about software design.

A language or API doesn't become better by adding more features.

It becomes better when the core features are well designed.


9. JavaScript is much simpler than it first appears

The language feels huge at first.

But most of it is built on a few fundamental ideas:

  • objects
  • functions
  • prototypes
  • closures
  • scope

Once those concepts make sense, many "advanced" topics feel much more approachable.


Things that are outdated today

The book is almost two decades old, so I wouldn't follow everything literally.

Today we'd use:

  • let / const instead of var
  • ESLint instead of JSLint
  • JSON.parse() instead of custom parsers
  • modules instead of IIFEs for encapsulation
  • Map and Set where appropriate

But the principles behind those recommendations are still valuable.


My biggest takeaway

I started reading this book expecting to learn more JavaScript syntax.

Instead, I finished it with a better understanding of why JavaScript behaves the way it does.

And that, more than any specific API or language feature, has already made me a better JavaScript developer.


I think this makes a stronger LinkedIn post because it focuses on insights rather than trying to cover every technical detail. People are more likely to engage with "here's how this book changed my understanding" than with a long list of language features.

Top comments (0)