On Fundamentals

There's a temptation, especially early on, to skip to the part that works. Import the library, copy the snippet, run the demo. Things move fast that way — until they don't. Until you push past the happy path, and the error you get is three abstraction layers deep, and you have no idea what's failing or why.

I've been that person. I know what it feels like to have code that works and zero understanding of why. It's uncomfortable in a way that doesn't go away — it just gets quieter when things go smoothly, and very loud the moment they don't.

Why the Bottom Layer Matters

When you understand what a thing is built on, errors have addresses. "This callback isn't firing" has a different meaning when you know what the event loop actually does. "The component re-renders too much" is diagnosable when you understand how React decides to re-render. The abstraction is still useful — you don't have to implement a virtual DOM to use one — but knowing what it does underneath tells you when it's breaking and where to look.

The goal is not omniscience. It's building a mental model that's accurate enough to be useful when things go wrong.

A Concrete Example: Event Delegation

A classic case where knowing the foundation changes everything. If you only know that addEventListener attaches handlers to elements, attaching a handler per item in a loop looks fine — until the list gets large or items are added and removed dynamically. But if you know that click events bubble up the DOM, you can attach one handler to the parent and let the event come to you.

// One handler per item — breaks down when the list is dynamic
items.forEach((item) => {
  item.addEventListener("click", handleClick);
});
 
// One handler on the parent — reads the target when the event arrives
list.addEventListener("click", (e) => {
  const item = e.target.closest("[data-item]");
  if (!item) return;
  handleClick(item);
});

Neither version is wrong for a small, static list. But for large, dynamic lists the second version is dramatically cheaper, and you can only see why once you understand bubbling. That's the return on learning the foundation: the optimization is invisible until you need it, and then it's exactly what you need.

A Note on Static Languages

Fundamentals apply across languages. Here is the same idea expressed in Rust — a language where ownership makes the foundation especially visible:

fn greet(name: &str) -> String {
    format!("Hello, {}!", name)
}

The borrow checker forces you to understand ownership before your code compiles. There is no skipping the foundation.

Try It Yourself

Some snippets here are runnable — edit them and hit Run. This TypeScript builds a little DOM and logs to the console:

const el = document.createElement("p");
el.textContent = "Hello from TypeScript!";
document.body.append(el);
 
const nums: number[] = [1, 2, 3, 4];
console.log("sum =", nums.reduce((a, b) => a + b, 0));

And Python runs too — the runtime loads only when you press Run:

print("Hello from Python!")
print("2 ** 10 =", 2 ** 10)

Closing

Go slow, deliberately. Not because speed doesn't matter, but because understanding compounds. Every concept you actually grasp is a tool that doesn't expire. Skim it and it fades. Build it and it stays.

retry, but smarter. 🔁