Choosing and learning a framework

docs.scrimba.com

The last two chapters covered what frameworks are and what exists. This one is the practical end: whether to use one, which one, and how to learn it. The order matters, because the first question is the one that gets skipped most often.

Should you use a framework at all?

Picture two projects. The first is an app with accounts, forms, and screens that all react to shared data. Hand-rolling that means rebuilding exactly the plumbing a framework has already perfected, and the vanilla version ends up as a scattered, half-tested framework of your own invention that nobody wants to inherit. Reaching for Django or React there is choosing fewer moving parts than the alternative.

The second is a landing page, a content site, a small script, a form that submits somewhere. Plain HTML, CSS, and a little JavaScript cover these with no build step, no dependency updates, and nothing to migrate next year. Wrapping a page like that in a full framework adds machinery that only the tooling benefits from. Plenty of experienced developers ship vanilla on purpose, and it is a professional answer, never a beginner's compromise.

Engineering has a blunt old rule that covers both cases: KISS, "keep it simple, stupid". The insult is aimed at the design rather than the designer, and the idea is that the best solution is the one with the least machinery that still does the job. Both projects above obey it, and they land on opposite answers.

That makes the test one question, asked fresh for each project: choose whichever option leaves you less machinery to maintain. When the plumbing dwarfs the product, that is the framework. When the product is nearly all there is, that is vanilla.

A few signals make the call concrete. Leaning framework: lots of screens sharing live data, user accounts and permissions, forms that validate and save, several people working on the same codebase for years. Leaning vanilla: mostly content, little interactivity, a lifespan measured in months, one or two maintainers, or a page where load speed is the whole feature. And project size can change the answer over time in both directions, so the useful habit is re-asking the question whenever the project changes shape.

This decision fails in two recognisable ways, and both come from skipping the question. The first failure is the framework-shaped landing page: a build pipeline, a dependency tree, and eventual migrations attached to four screens of content, where every hour spent on tooling is an hour the product did not need. The second is the accidental framework: a vanilla codebase that grows its own router, its own state store, and its own component system, each written once, tested never, and understood by one person. That second project pays framework costs without framework benefits. Both failures look like conviction from the inside; the fix in both cases is the same unglamorous move of re-deciding based on what the project has become.

JunoDo you need a framework? Ask one question per project: which option leaves less to build and maintain? For an interactive app with accounts and shared data, a framework usually wins. For a content page or a small script, plain code usually wins. Both answers are respectable, and choosing plain code is never a downgrade!

JunoDo you need a framework? Shared live state, accounts, forms, and a long multi-person life point to a framework; content-heavy, short-lived, or speed-critical pages point to vanilla. Re-ask when the project changes shape instead of defending the original call, and make it per project every time.

JunoDo you need a framework? Watch for the two classic failures: the framework-shaped landing page paying tooling costs for nothing, and the vanilla app that quietly grew an unmaintained framework of its own. Both come from treating the choice as settled. I re-decide at every project inflection, and it has saved me from both ditches more than once.

How to choose one

When the answer is yes, choose with unglamorous criteria. Benchmarks and feature comparisons are the least useful inputs, because within a family the popular options are all fast enough and all capable enough. What actually shapes your daily life:

The ecosystem and community: mature documentation, answered questions, and packages for the problems you will hit. The team and codebase you are joining: the best framework is usually the one your project already uses, and consistency beats novelty inside a team. The job market, if learning for work: sheer usage numbers matter, which is a large part of why React is many people's rational first pick. And the language you know: a Python developer reaches Django faster than Rails for reasons that have nothing to do with quality.

Keep the vanilla option on the list to the end. If the comparison table fills up and none of the candidates beats "none of the above" on the simplicity test, that is the answer telling you something.

For a closer look at a candidate, an hour of firsthand evaluation beats a week of reading opinions: skim the official tutorial and judge whether the documentation explains or gestures; check the release history for a steady, unfrantic pace; search for "migrating from version X to Y" and see whether those guides read like an afternoon or a season; and look at whether the questions you would ask already have good answers. A framework is a long relationship, and these are the compatibility checks.

Two senior habits round this out. First, bet on the well-established: a technology that has been widely used for years has known failure modes, hiring pools, and answers, and "proven and slightly unfashionable" outlives "new and exciting" far more often than the other way round. Churn is a compounding cost, and the frameworks that survived a decade already paid it. Second, keep build-versus-adopt as a real option at the component level: sometimes the right amount of framework is a routing library and nothing else, adopted for the one hard problem while the rest stays plain. Adopting a framework is not all-or-nothing, and the smallest dependency that solves the actual hard part is a respectable architecture.

JunoChoosing one Choose with practical criteria: what your team already uses, how good the documentation and community are, what the job market wants, and which language you already know. Within a family, every popular option is good, so the stakes are lower than they feel. Your skills will transfer whichever way you go.

JunoChoosing one Give a candidate one focused hour: read its tutorial, check its release rhythm, and read a version-migration guide, since that is the future you are signing up for. Community, team fit, and hiring beat benchmarks every time. And keep "no framework" on the shortlist until the end on purpose.

JunoChoosing one Bet on the well-established: surviving a decade is the most informative benchmark a framework can post. And remember adoption is not binary; sometimes one small library for the one hard problem is the right amount of framework. The goal is a product that ships and stays shippable.

How to learn any framework

Learn the language first. A framework assumes its language everywhere: React code is JavaScript wall to wall, and every confusing line of a Django app is Python underneath. Learners who skip to the framework end up debugging two mysteries at once, the framework's behaviour and the language's syntax, with no way to tell which is which. If React is your goal, the JavaScript track is the actual first step; for Django or pytest, the Python track plays the same role. Language first is the single biggest shortcut there is, because it is the part that transfers everywhere.

Then build something small and real. One little project you actually want, built while leaning on the official tutorial, teaches more than any amount of watching and reading, because the framework's shape only makes sense under your own hands. Keep the first project modest on purpose: its whole job is to introduce you to the framework's ideas, and the masterpiece can come later.

And as you go, keep asking what the framework is doing for you. Every convenient feature is standing in for something real: a route stands in for URL parsing, a component for DOM updates, a model for SQL. You do not need to master those layers upfront, but knowing they exist, and roughly what the framework does with them, is what separates using a framework from depending on it blindly.

The common trap at this stage is the tutorial loop: finishing course after course while never starting an unguided project, because tutorials feel productive and blank files feel risky. Break it deliberately. After one official tutorial, start the small real project and let its problems drive what you look up; documentation read with a live problem in hand sticks in a way that documentation read as homework never does. Getting stuck and unstuck on your own project is the actual skill being trained.

Two habits make framework knowledge durable. Learn the escape hatches early: every framework has sanctioned ways to drop below its abstractions (raw SQL past the ORM, direct DOM access past the renderer), and knowing where they are tells you the boundaries of the machine even if you rarely use them. And invest in the platform underneath the framework, HTTP, the DOM, SQL, the language runtime, at a steady drip. Frameworks are how the platform is currently being held; the platform is what endures. Developers who knew the platform crossed every framework transition of the past twenty years intact, which is a track record worth copying.

JunoLearning one Learn the language before the framework, always: JavaScript before React, Python before Django. Then build one small real project with the official tutorial open beside you. Small and finished beats big and abandoned, and everything you learn about the language keeps its value forever!

JunoLearning one Escape the tutorial loop on purpose: one official tutorial, then a small unguided project whose problems decide what you read next. Docs studied with a live problem in hand actually stick. Getting stuck and unstuck on your own work is the skill you are really training.

JunoLearning one Find the escape hatches early; they mark the true edges of the machine. And keep feeding your knowledge of the platform underneath, HTTP, the DOM, SQL, because frameworks rotate and the platform stays. Platform people survive every framework transition; I have watched several and the pattern has not missed yet.

Where this leaves you

That is the whole primer: simplicity as the test, unglamorous criteria for the pick, language before framework for the learning. When a specific framework shows up next, in these docs or in the wild, The kinds of frameworks is the map to place it on, and What is a framework is the definition underneath it.