The starter CLI finished, and you still have not written a handler you understand. You ran three install commands, copied a boilerplate snippet from the docs, and your localhost port is serving a generic “Welcome to X framework” page, but you couldn’t explain what half the files in your new directory do if asked. This is the first friction point most solo learners hit when picking a tech stack for their first small project, and it’s a fork in the road that can add days of unnecessary work or make core concepts stick 2x faster.
Build Next Stack editors
The below framework tax card uses example measurements for a learner with 3 months of experience in the underlying language, no prior framework exposure, building a basic todo app as a learning project:
| Project Type | Example Measurement: Total Setup Hours (Config, Scaffolding, Dependency Fixes) | Example Measurement: Total Feature Building Hours (Writing logic that solves your project’s core goal) | Example Measurement: % of time spent on non-learning “framework tax” |
|---|---|---|---|
| Plain JavaScript (Node.js) todo app, no framework | 1.1 | 7.2 | 13% |
| Next.js 14 (App Router) todo app | 5.2 | 7.8 | 41% |
| Plain Python todo app, no framework | 0.9 | 6.8 | 12% |
| Django todo app | 4.7 | 7.1 | 40% |
| Plain PHP todo app, no framework | 0.7 | 6.5 | 10% |
| Laravel todo app | 5.0 | 7.3 | 41% |
Hours lost to config before the first route
The largest upfront cost of picking a framework for a learning project is the unplanned work required to get to the point where you can write code that directly relates to your project goals. For the Next.js 14 todo app in the framework tax card, more than 5 hours of work pass before you can write your first functional route that accepts a todo entry from a user and saves it to storage. That time is spent installing dependencies, configuring TypeScript if you opted into it, fixing lint errors that block your dev server from running, learning the App Router’s file naming conventions, and troubleshooting why your environment variables are not being picked up by the framework. None of this work teaches you core web development skills that transfer between stacks. A learner who spends those 5 hours fighting config will not be able to explain how an HTTP POST request works at the end of it, while a learner using plain Node.js will have written 3+ routes and practiced parsing request bodies, setting status codes, and handling errors in that same window.
Plain-language path that still teaches HTTP
The plain language path avoids that upfront tax by forcing you to interact directly with web primitives instead of abstracted framework APIs. When you build a todo app with plain Node.js, you have to write the code that listens for incoming requests, matches the request URL and method to a handler, parses JSON payloads from the client, sets appropriate CORS headers so your frontend can talk to your backend, and returns valid responses with correct status codes. Every one of these steps is a portable skill that applies to any backend framework you might learn later, and every line of code you write directly relates to the core goal of building your project. As shown in the framework tax card, the plain JavaScript project spends 87% of total project time on feature building and core skill practice, compared to 59% for the Next.js equivalent. You don’t sacrifice functionality by choosing the plain language path: you can add user authentication, task filtering, due date reminders, and persistent storage without relying on any framework-specific features, and you’ll understand every part of how your app works when you’re done.
Framework win when the UI has three screens
Frameworks deliver clear value once you have mastered core web concepts and are building projects with more complex UI requirements. If you expand your todo app past a single screen to include a public marketing page, a user dashboard with task sorting, and an admin panel for managing user accounts, the repetitive work of building custom routing, reusing UI components, and handling server-side rendering for fast page loads adds up quickly. When you extend the project in the framework tax card to include three UI screens, the plain JavaScript project’s total feature building time jumps to Illustrative example: 18.7 hours, as you have to build a custom client-side router, write helper functions to reuse UI elements across pages, and configure server-side rendering logic from scratch. The Next.js project’s total feature building time only increases to Illustrative example: 10.2 hours, as its built-in routing, component system, and server rendering features eliminate that repetitive boilerplate. This win only applies if you already understand the concepts the framework is abstracting, however: if you don’t know how client-side routing works under the hood, you’ll still spend hours debugging navigation errors that you could have fixed in minutes if you’d built the logic yourself once.
Tutorial lock-in that hides the language itself
The biggest risk of starting with a framework before you master the underlying language is tutorial lock-in, a pattern where you can only build projects when following a step-by-step guide that uses your chosen framework’s specific conventions. Many beginner framework tutorials walk you through copying snippets of code without explaining the core language features powering them. You might copy a server action snippet for your Next.js todo app without realizing it is just a standard async JavaScript function that handles a POST request, so when you later try to build the same feature with Express or Fastify, you have no idea where to start. This lock-in also makes it much harder to debug errors: if you don’t know the difference between standard JavaScript syntax and framework-specific syntax, you can’t tell if an error is coming from a mistake in your own code, a misconfigured framework setting, or a deprecated third-party dependency. Learners who start with frameworks first often report spending Illustrative example: 2x as much time troubleshooting errors as learners who built 2-3 plain language projects first, because they lack the foundational knowledge to isolate issues.
Switch trigger if week two is still scaffolding
You don’t have to commit to either a plain language or framework path for the entire lifecycle of your learning project, and there is a clear trigger to switch paths if you’re not making progress. Illustrative example: If you are two full weeks into your project and you are still spending most of your time scaffolding, fixing config errors, reading framework docs for built-in features, or updating deprecated APIs instead of writing code that adds functionality to your project, it’s time to step back to a plain language implementation to lock in core concepts first. You can always port your working plain language code to a framework later once you understand every part of how it works. Conversely, if you’ve built Illustrative example: 2-3 small projects with plain language and you find yourself writing the same 20 lines of boilerplate code for routing, parsing requests, and reusing UI components every time you start a new project, you’re ready to adopt a framework to cut down on repetitive work and focus on building more complex features.
Before you run your next framework starter CLI, pull up the framework tax card to calculate how much time you’re willing to spend on config before writing your first line of feature code, and commit to switching to a plain language implementation if you hit the Example measurement: 5 hour mark of troubleshooting with no functional routes to show for it.