Framework vs Plain Language for Learning Projects

docs/learning-project-framework-tax-assessment.md tracks tradeoffs for your upcoming personal recipe tracker learning project.

Map the two implementation choices for your project

You start by defining the two distinct paths you can take to build your learning project, aligned with your core goals of building working features quickly, retaining core web development skills, and finishing the project before you shift focus to other priorities. The first option is the plain language (vanilla) stack: no build tools, no external dependencies, no framework-specific syntax. You write plain HTML for structure, vanilla CSS for styling, and untranspiled JavaScript for interactivity, and all files run directly in any modern browser without extra processing. The second option is a full framework stack: a pre-built opinionated toolset like React, Next.js, or Vue that handles routing, state management, and rendering for you, but requires you to install dependencies, configure build pipelines, and learn framework-specific rules that do not apply to core web development work. You note that this assessment is for a solo learning project, not a production-grade app built for thousands of users or a team of 10+ contributors, so tradeoffs that make sense for enterprise use cases do not apply here.

Calculate the framework tax for your expected scope

Framework tax is the total amount of time you spend on work that is not directly related to building the features you care about for your project: setup, debugging dependency conflicts, fixing build errors, learning framework-specific APIs, and troubleshooting quirks that only exist because of the framework layer. You build a comparison table for the three most common implementation paths for your recipe tracker, which has an initial scope of 15 user-facing features, adjusted for your current skill level (6 months of experience with core HTML/CSS/JS, no professional experience working with React or Next.js):

The plain vanilla stack has the lowest setup time and fastest time to first deploy, because you only need to create three files (index.html, styles.css, app.js) and add basic boilerplate before you can start building features. The framework options have higher setup time, but lower per-feature time once you have the base configured, as they include built-in utilities for common tasks like state updates and DOM re-renders. Illustrative example: If you cut your initial scope down to 12 custom features instead of 15, the plain vanilla stack has a total projected time of 14.9 hours, which is 0.1 hours faster than the React + Vite stack and 2.9 hours faster than the Next.js stack. You note that the table estimates do not include the 3-5 extra hours of learning time you would need to spend to get up to speed on framework-specific syntax and best practices if you choose either framework option, which would push their total projected times significantly higher than the vanilla stack for your current skill level.

Choose your implementation path and document it here

After weighing the tradeoffs, you select the plain vanilla HTML/CSS/JS stack for this learning project. Your core learning goals for this project are to master DOM manipulation, build responsive layouts with CSS grid and flexbox, implement client-side data storage with localStorage, and write clean, reusable vanilla JavaScript functions, all of which are achievable without a framework. You do not need server-side rendering, dynamic routing, or complex global state management for a project that only has 3 core pages (recipe list, individual recipe view, add recipe form) and stores all data locally on the user’s device. You document your choice in this file by adding a line at the top of your project README linking to this assessment, so you can reference it later if you are tempted to add a framework mid-project when you hit a minor repetitive code pattern. You can reference Build Next Stack’s vanilla JS project boilerplate if you want a pre-configured set of CSS reset styles and utility functions to cut your initial setup time even further, without adding unnecessary dependencies. You list the first four features you will build, in order: add a new recipe with name, ingredients, instructions, and dietary tags, search existing recipes by name, filter recipes by dietary restriction (vegan, gluten-free, nut-free), and export a consolidated grocery list from selected recipes. You also add a note that you will only consider adding small, single-purpose utility libraries (no full frameworks) if you hit a specific bottleneck that slows down feature development for more than 2 consecutive work sessions.

Next time you open this file to adjust your project timeline

This file lives in the root of your project directory, so it appears at the top of your file tree every time you open the project in your code editor. When you open it next, you will first update the comparison table with your actual setup time and the actual time you spent building the first four features, to adjust your average per-feature hour estimate for the remaining 11 features. You will also assess if you are running into any repetitive code patterns that could be simplified with a small, single-purpose utility library if you want to speed up development, without adding the overhead of a full framework tax. If you decide to expand your project scope to include user accounts, cloud storage, or public sharing of recipes, you will re-run this framework tax assessment to see if switching to a framework makes sense for your updated goals, but you will not switch stacks without completing the initial 15 features first. You will also add notes to this file about any core web skills you learned while building with the plain vanilla stack, to track your learning progress over the course of the project. If you finish the initial scope under your projected total time, you can use the remaining hours to experiment with adding a lightweight framework to a fork of the project for extra learning, without risking your ability to finish the core project on your original timeline.