2025 December 07 Archive - EXEIdeas

Let me tell you a story about my first “real” web project. I was building a simple content dashboard. Nothing crazy—just display some data from an API, maybe filter it, basic stuff. I didn’t even think about using plain JavaScript. My immediate, knee-jerk reaction? “I’ll use React.” Or Vue. Or Svelte. Something. Anything but the raw language itself.I spent two days configuring Webpack, Babel, and npm packages before I wrote a single line of application logic. When I finally got to building the actual feature, I realized I didn’t actually know how to efficiently manipulate the DOM, handle events natively, or manage simple state without useState. The framework was my crutch, and I had forgotten how to walk.Sound familiar? If your default answer to “What should I build this with?” is always a framework name—React, Angular, Laravel, Django, Ruby on Rails—then this post is for you. We’re going to dig into the fundamental difference between a core programming language (like JavaScript, Python, PHP) and a development framework (the tools built on top of them), and discuss the very real, often painful reasons why reaching for a framework first might be the worst decision you make for your growth and your project.The Great Misunderstanding: What Actually Is What?Before we talk about why not to use them, we need to be crystal clear on what “them” even is. This is where most confusion starts.The Core Language: Your FoundationThink of the core language as the soil, bricks, and mortar. It’s the raw material. For the web, this is:JavaScript (ES6+): The programming language of the browser. Variables, functions, loops, classes, the DOM API, Fetch API.HTML & CSS: The actual structure and styling of the web. Not “programming” languages per se, but the fundamental web trio.Python, PHP, Ruby, Java, etc.: For server-side work, these are the core languages with their built-in syntax and standard libraries.This is the stuff that runs natively. The browser understands vanilla JavaScript. The Python interpreter understands plain Python. No extra tools needed.The Development Framework: The Pre-Fab House KitA framework is a collection of tools, conventions, and pre-written code built on top of a core language to solve common problems. It gives you a structure to build within.React, Vue, Angular, Svelte: JavaScript frameworks/libraries for building user interfaces.Laravel (PHP), Django (Python), Ruby on Rails (Ruby), Express.js (Node.js): Backend frameworks that handle routing, databases, sessions, etc.Bootstrap, Tailwind CSS: CSS frameworks that provide pre-designed components and utilities.Frameworks are abstractions. They hide complexity and provide shortcuts. The crucial thing to remember: Every framework is eventually translated into the core language. React becomes JavaScript. Tailwind becomes CSS. Laravel becomes PHP. They are not magic; they are convenient wrappers. “Learning a framework without understanding the underlying language is like learning to assemble IKEA furniture without understanding how a hammer or screwdriver works. You can follow the instructions, but you can’t fix anything when it breaks, and you certainly can’t build something of your own design from scratch.” The Case Against The Framework-First MindsetI’m not saying frameworks are evil. Used correctly, by experienced developers, they are incredible productivity multipliers. The problem is the framework-first mindset adopted by beginners and even intermediate developers. Here’s why that approach backfires.1. You Learn The Framework, Not The LanguageThis is the biggest, most insidious issue. You start with React. You learn JSX, components, props, hooks, Redux. You become proficient in React’s ecosystem. But ask yourself: Can you explain the JavaScript event loop? Can you implement a simple debounce function from scratch? Do you know how the Virtual DOM diffing actually works under the hood, or is it just “magic that makes React fast”?You become a “React developer” instead of a “JavaScript developer.” This makes you incredibly vulnerable. When a new framework emerges (and it will), your knowledge has a short half-life. The core language evolves slowly. Frameworks rise and fall like fashion trends. Personal Anecdote: I interviewed a developer who listed “Advanced JavaScript” on their resume. They built impressive React apps. I asked them to write a simple function using map and filter on an array using plain JS, without React. They froze. They were so used to doing data manipulation inside useEffect and JSX that the fundamental language constructs had atrophied. 2. You Incur Massive “Conceptual Debt”Frameworks introduce abstractions and concepts that you must understand to use them. State management, lifecycle methods, dependency injection, proprietary templating syntax, ORMs (Object-Relational Mappers).These concepts are often solutions to complex problems in large-scale applications. If you’ve never built a simple app without them, you have no context for why they exist. You’re learning complex solutions before you’ve experienced the simple problems they solve. It’s conceptual overload.Can you explain what problem React’s `useState` solves if you’ve never tried to manage changing data in a plain JS app and seen the UI get out of sync? Probably not. You’re just memorizing an API.3. Bloat, Performance, and Loss of ControlFrameworks come with overhead. That simple “Hello World” in React? It might require importing hundreds of kilobytes of library code. Your user’s browser is downloading a whole framework just to render a static page that could be 10 lines of HTML.Bloat: You get features you don’t need. A full MVC framework for a simple API endpoint is overkill.Performance: The abstraction layer has a cost. A well-written vanilla JS can often outperform a framework for simple tasks.Black Box: When something goes wrong—a weird bug, a performance issue—you’re debugging the framework’s abstraction, not your code. This is infinitely harder.4. You Miss The “How” and The “Why”This is the educational tragedy. By using a framework, you skip the foundational problem-solving journey.If you build a simple SPA (Single Page Application) with vanilla JavaScript, you’ll wrestle with:How to update the UI when data changes. (This leads you to appreciate React’s reactivity.)How to structure your code to avoid spaghetti. (This makes you value component architecture.)How to efficiently query and update the DOM. (This shows you the value of a Virtual DOM.)When you finally do pick up a framework, you’ll understand it. You’ll know what it’s doing for you and why it’s designed that way. You’ll use it as a powerful tool, not as a mystical incantation. The Client Story: A client once came to me with a terribly slow WordPress site (WordPress is a framework of sorts). The page used a massive drag-and-drop page builder (another framework on a framework!) to create a simple contact page. The HTML output was a horrific, nested div soup with inline styles. The page weight was 4MB. We replaced it with 25 lines of hand-coded HTML and CSS. It loaded instantly. The framework had encouraged the creation of a monster without the client even realizing it. So… When SHOULD You Use a Framework?See, I told you I’m not anti-framework. I’m anti-unnecessary framework. Here are the right reasons to use one:You Understand the Core Language Deeply: You’re using the framework to save time on boilerplate, not to compensate for a lack of fundamental knowledge.The Project Demands It: You’re building a large, complex, interactive application with multiple developers. The framework’s structure and conventions (like React’s component model or Rails’ “convention over configuration”) will prevent chaos.You Need the Ecosystem: Sometimes, you need specific tools (like React Native for mobile) that are intrinsically tied to a framework ecosystem.After Prototyping: You built a working prototype in vanilla JS/PHP/Python. It works, but maintaining and scaling it is becoming messy. Now is the perfect time to consider introducing a framework for structure.The Practical Path: How To Learn (And Use) Tools CorrectlyIf I could design the ideal learning path for a new developer, it would look like this:Phase 1: Master the FundamentalsSpend serious time with the core language. For front-end, this means:HTML semantics and accessibility.CSS (Flexbox, Grid, selectors, specificity).Vanilla JavaScript (ES6+): DOM manipulation, events, Fetch API, array methods, closures, promises/async-await.Build things: A todo app. A weather app using a public API. A simple game. Do it all without any framework. It will be harder. You will struggle. That’s the point. That struggle is where real learning happens.Phase 2: Build Something “Framework-Worthy”Take one of your vanilla projects and make it bigger. Add more features. Notice how your code starts to get messy. How updating the UI in five places when one piece of data changes is a nightmare. Feel the pain. This pain is your teacher.Phase 3: Learn a Framework with ContextNow learn React (or Vue, or Svelte). You will have moments of revelation. “Oh! This hook solves that state problem I had!” “Components are just a clean way to organize what I was already trying to do!” You’re not just memorizing—you’re connecting new solutions to old problems. “The framework should be the last tool you reach for, not the first. It’s the specialist you call in when the generalist (the core language) can’t handle the complexity alone.” Frequently Asked Questions (FAQs)But everyone uses frameworks for real jobs. Am I wasting my time learning vanilla JavaScript?Absolutely not. It’s the opposite. In real jobs, senior developers and hiring managers desperately look for people who understand the fundamentals. Anyone can follow a React tutorial. Debugging a mysterious performance issue or integrating a non-React library requires deep JS knowledge. The vanilla skills make you valuable; the framework skills make you employable today. You need both, but the foundation is non-negotiable.Isn’t it faster to just start with a framework and build things?It’s faster for the first simple project, maybe. But it’s much, much slower in the long run. You’ll hit a “knowledge ceiling” where you can’t solve problems the framework doesn’t have a built-in solution for. You’ll spend more time debugging framework-specific issues and searching for library solutions than actually understanding your code. Building a deep foundation feels slower initially but gives you exponential speed and capability later.What about backend frameworks like Laravel or Django? Should I avoid those too?The same principle applies, perhaps even more strongly. Before Laravel, understand plain PHP: how to handle a form POST, connect to a database with PDO, manage sessions. Before Django, understand Python’s syntax, how to run a simple HTTP server, and work with SQL. The framework will then make sense as a set of organized, secure, pre-built solutions to the repetitive tasks you’ve already done manually.How do I know if my project is complex enough to need a framework?Ask yourself: Is my code becoming hard to manage? Am I constantly copying and pasting the same UI patterns? Are multiple parts of the UI dependent on the same data that changes often? Do I have multiple people working on the codebase? If you answer “yes” to several of these, a framework might help. A good rule of thumb: Start without one. Let the project’s needs tell you when it’s time to introduce one.Are CSS frameworks like Bootstrap or Tailwind also bad to start with?They suffer from the same issue. If you start with Bootstrap, you learn Bootstrap’s class names, not CSS. You won’t understand how Flexbox works, how the CSS Box Model operates, or how to debug a layout. Start by learning core CSS. Once you can build a responsive layout from scratch, then use Tailwind as a productivity tool for rapid prototyping and consistency. You’ll use it intelligently, not dependently.I’m already comfortable with a framework. Is it too late to go back?I’m already comfortable with a framework. Is it too late to go back?Not at all! It’s a very common position. Dedicate your next side project to being “framework-free.” Choose a small idea and forbid yourself from using your usual tools. You’ll be uncomfortable. You’ll Google “how to do X in vanilla JS.” That’s the whole process! This deliberate practice will fill the gaps in your knowledge and ultimately make you a better framework developer. You’ll understand the “magic.”What about tools like Next.js or Nuxt.js? They’re meta-frameworks.This layers on more abstraction! Next.js (React framework) sits on top of React (UI framework), which sits on top of JavaScript. If you don’t understand React, you can’t truly understand Next.js. If you don’t understand JavaScript, you can’t truly understand React. Starting at the top of this stack means you’re standing on a tower of abstractions with a shaky foundation. It’s riskier and limits your ability to customize or troubleshoot at a deep level.Don’t frameworks teach you good practices and patterns?They expose you to them, but they don’t teach you the “why.” You’ll use a React Hook but not understand the closure pattern it’s built upon. You’ll use Laravel’s Eloquent ORM but not understand the SQL it’s generating or the N+1 query problem it can hide. Frameworks show you one way to structure things. Understanding the core allows you to evaluate if that’s the best way for your specific problem, or even to create your own patterns.What’s the one exercise you recommend to test my core language knowledge?Here’s a challenge: Build a simple, interactive list (like a todo app) with pure HTML, CSS, and vanilla JavaScript. It must: 1) Add items, 2) Mark items as complete, 3) Delete items, 4) Persist the list between page refreshes (use `localStorage`). 5) Have a filter (show all/active/completed). Don’t use any libraries. If this feels daunting, that’s your signal. Mastering this will give you more insight into UI development than 10 React tutorials.Final word: Are you saying I should never use frameworks?No. That’s not the takeaway. I use frameworks every single day in my professional work. They are powerful, essential tools for modern development. The message is: Don’t let the framework be your teacher. Let the core language be your teacher. Let the framework be your toolbelt. Learn the fundamentals first, understand the problems they solve, and then adopt frameworks from a position of strength and choice, not from a place of dependence and ignorance. Build the foundation, then decorate the house.Closing Thoughts: Embrace the GrindLearning the core language is harder. It’s less immediately gratifying. You won’t have the shiny components or the quick setup. You’ll write more code. You’ll face more bugs.But in that grind, you build something far more valuable than any app: durable understanding. You build the mental models that will let you adapt to any tool, any trend, any new problem that comes your way.The next time you start a project, pause. Ask yourself: “Do I need a framework for this, or am I just scared of the blank canvas?” Try starting with the raw materials. Get comfortable with the soil, bricks, and mortar. You might be surprised at what you can build when you’re not leaning on someone else’s pre-fab walls.Trust the process. Build the foundation. The rest is just decoration.