Introduction: What Makes a Framework a Framework?

Django looks nothing like Express, which looks nothing like Rails, which looks nothing like Laravel. Different languages, different syntax, different philosophies loudly advertised on their own homepages. And yet underneath all of that, nearly every one of them is solving the same small handful of real problems — the same problems every single time, regardless of which language or company built the framework in question. This course looks at those problems directly, one at a time: what each one actually is, and then how genuinely differently (or similarly) real frameworks choose to solve it.

Library vs. Framework: A Real, Precise Distinction

"Framework" gets used loosely enough in casual conversation that it's worth pinning down exactly what separates it from a library — not as a vague feeling, but as a genuine, testable property: who calls whom.

A library is a collection of code your code calls, on your own schedule, in whatever order you decide. A framework inverts that relationship — it provides the outer structure and the actual control flow, and it calls your code, at moments and in an order the framework itself decides. This is genuinely old, well-established terminology: Martin Fowler's real 2004 article, "Inversion of Control Containers and the Dependency Injection Pattern," was written specifically to clarify a term that was already, even then, being used loosely and inconsistently across the industry. The informal shorthand many developers reach for — "don't call us, we'll call you," sometimes nicknamed the Hollywood Principle — captures the same real idea: the framework is in charge of the flow, not your own code.

This distinction genuinely matters for the rest of this course, because every one of the four capabilities below is, at its core, a specific place where a framework has decided to take control away from you and call your code itself — a route handler only runs when the framework's own router decides a URL matches it; a template only renders when the framework's own view-rendering machinery reaches that point in a request.

Four Real, Load-Bearing Capabilities

Real frameworks vary enormously in scope — some try to do almost everything, others deliberately do very little — but a genuinely useful, real-world starting definition keeps narrowing down to the same short list. This course picks four to go deep on, one chapter of "how it actually works" followed by one chapter of "how real frameworks differ" for each:

This isn't an arbitrary list — it's grounded directly in why one of the most widely used frameworks on this entire list was built in the first place. TJ Holowaychuk built Express specifically because, in his own real, documented words, Node.js itself "lacked key features like routing, templating, middleware, and robust error handling" — three of this course's own four chosen capabilities named explicitly, by the person who built a framework specifically to provide them.

Frameworks Are (Almost Always) Extracted From a Real Application

A recurring, genuinely verifiable pattern across framework history: the framework wasn't designed first, in the abstract, and then used to build something. It was pulled out of something real that had already been built, once its own author noticed the same problem recurring inside it.

Frameworks This Course Draws On

Every comparison chapter in this course draws on real, working frameworks this site already has dedicated courses for — this course cross-references that material directly rather than re-teaching any single framework from scratch:

Where This Course Is Headed

Routing — how it actually works (Chapter 2), then compared across Django, Express, Rails, Laravel, and FastAPI (Chapter 3); templating — how it actually works (Chapter 4), then compared across Django Templates/Jinja2, ERB, Blade, EJS/Pug, and JSX (Chapter 5); data access and the ORM layer — how it actually works (Chapter 6), then compared across the Django ORM, SQLAlchemy, ActiveRecord, Eloquent, and Prisma (Chapter 7); middleware and the request/response lifecycle — how it actually works (Chapter 8), then compared across Express, Django, Rails, and FastAPI (Chapter 9); and a closing capstone applying every prior chapter to a real, worked framework-selection decision (Chapter 10).

Hands-On Exercises