When You Don't Need a Framework Yet

Phase 2 gave a starting framework for every major language. Here's the honest exception: for some of what you're building, you don't need any of them yet.

The standard library already does a lot

Most languages ship an HTTP server in the box. Python has http.server, Go and C# both have production-usable HTTP stacks in their standard libraries, Node has the http module underneath every framework built on it. None of these are toys - they can route a request, read a body, and send a response with no framework at all.

Two guides in this library build a real server directly on the standard library, no framework in sight: Build a Server with Node's http Module and Web Services with Only net/http. Both are worth doing even if you already picked a framework in Phase 2 - they show you what the framework is actually doing underneath.

Where the line actually sits

A framework earns its cost when the app is big enough, long-lived enough, or team-shaped enough that its conventions save more time than they take to learn. Below that line, the standard library alone is the better call:

• A single-endpoint tool - a webhook receiver, a health-check ping, a small script that needs one route. A framework's routing, middleware stack, and config system solve a problem you don't have yet.
• Learning what's underneath a framework you already use. Building the same small server twice
  • once raw, once in your Phase 2 framework - is the fastest way to see exactly what the framework buys you, instead of taking it on faith.
• A throwaway or short-lived project. If it won't outlive the afternoon, the framework's setup cost outweighs anything it would have saved you.

Outside those cases, a framework usually wins - once real routes, real middleware needs, and a real team show up, hand-rolling the same things a framework gives you for free stops being a good trade.

Why the boundary matters more than the pick

What a Framework Even Is covers this cost directly in its "Price of Magic" material - every convenience a framework adds is also a thing you now depend on and don't fully see. That's a fair trade for a real application. It's a bad trade for a script that needed ten lines.

Knowing when to skip a framework is not a lesser skill than knowing which one to pick. It's the same judgment, pointed the other way - and it's what separates someone who reaches for a framework by reflex from someone who reaches for the right tool for what's actually in front of them.

Where this leaves you

Pick your language, pick the framework from Phase 2, build something real in it, and finish it. If what you're building is small enough that a framework feels like more setup than the problem deserves, reach for the standard library instead - and read the roots guide for your stack to see what's actually happening under the hood either way. Both paths teach you something a framework tour never will: what the code is actually doing when nobody's watching.

[
  {
    "q": "What do the 'roots' guides in this library (build-a-server-with-node-http, web-services-with-only-net-http) demonstrate?",
    "choices": [
      "That standard libraries can't handle real HTTP traffic",
      "That a real server can be built directly on the standard library, with no framework at all",
      "That every framework is built on Node specifically",
      "That frameworks are always faster than the standard library"
    ],
    "answer": 1,
    "explain": "Both guides build a working server using only the language's standard library - proof that a framework is a choice, not a requirement, for getting an HTTP server running."
  },
  {
    "q": "According to this phase, when does skipping a framework make the most sense?",
    "choices": [
      "Never - always use a framework regardless of project size",
      "For a single-endpoint tool, a throwaway script, or when you want to see what a framework is doing underneath",
      "Only when the language has no framework ecosystem at all",
      "Only for enterprise-scale applications"
    ],
    "answer": 1,
    "explain": "Small, short-lived, or single-route projects rarely earn back a framework's setup cost. The standard library also makes a good teaching tool for seeing what a framework abstracts away."
  },
  {
    "q": "Why does this guide say knowing when to SKIP a framework matters as much as knowing which one to pick?",
    "choices": [
      "Because frameworks are being deprecated industry-wide",
      "Because it's the same judgment about cost versus benefit, just pointed the other way - reaching for the right tool instead of reaching by reflex",
      "Because standard libraries are always faster than frameworks",
      "Because most professional applications are built without frameworks"
    ],
    "answer": 1,
    "explain": "Every framework convenience is also a dependency you don't fully see (the 'Price of Magic'). That's worth it for a real, long-lived app and not worth it for a ten-line script - recognizing which situation you're in is the actual skill."
  }
]

← Phase 2: A Starting Point, Language by Language · Guide overview