Back in June a single developer with stolen credentials managed to publish malicious versions of more than 140 Mastra AI packages in under twenty minutes. Mastra is one of the most used frameworks for building AI agents in production. The poisoned releases went straight through npm, through the same channels as always, and anyone who installed during that window got exposed to malware hunting for crypto wallets and phoning home to a command-and-control server tied to a North Korea-linked group. This wasn't some sloppy typosquatting attempt, it was a legitimate maintainer account compromised right at the source. Original link: https://tech-insider.org/npm-supply-chain-attack-2026/ I'm not bringing this up to say frameworks equal risk, that would be way too simplistic, but episodes like this always bring back the same question in the mind of anyone who codes: how far should you go depending on a giant layer of third-party code you never actually read, just install? And the answer, like almost everything in programming, is more annoying than anyone would like: it depends. First it's worth separating things out, because "coding without a framework" means different things to different people. Some mean pure vanilla JS, without even an addEventListener hidden behind some library. Others use it to talk about avoiding only the heavyweights — React, Angular, Django — while still being fine with a light utility lib here and there. And some mix both meanings in the same sentence, which turns the whole discussion into a pointless argument in the comments. Better to get that straight before anything else. That said, the arguments for skipping the framework are real and not just posturing. The first is raw performance: every abstraction layer you add is code the browser has to download, parse, and run before doing anything useful. A framework-free site loads faster almost every time, especially on a bad connection or an older phone, and that matters a lot for people outside the bubble of folks who only test on fiber and a brand new iPhone. There's also the understanding argument. When you write your own DOM handling, your own routing, your own state management, you actually learn how those things work underneath. That's not academic purism, it's practical: a dev who only knows how to call useState without knowing what reactivity actually is gets stuck the moment the framework behaves in a way the docs never covered. And then there's longevity. Vanilla code written today tends to still run the same way five years from now. A project tied to a specific framework version runs a real risk of turning into technical debt the moment the next major version breaks everything, or worse, when the project just gets abandoned — something that's already happened to frameworks that were once the biggest hype around and that barely anyone remembers the name of today. But then comes the other side, which usually gets left out when someone writes this kind of post just to pat themselves on the back. Reinventing routing, data binding, and state management in production has a real cost, and that cost usually shows up months later, in the form of some weird bug nobody can debug because it doesn't follow any known pattern. Frameworks exist because those solutions have already been tested, broken, and fixed by thousands of projects before yours. There's also the team problem. When you work alone, your "own way" of doing things makes total sense to you. Once more people join the project, every dev coding without a shared convention ends up creating their own dialect inside the same codebase, and maintenance turns into archaeology. A framework forces a shared vocabulary, kind of like grammar in a language — annoying sometimes, but it keeps everyone from speaking a different dialect in the same code. And there's the hiring factor, which nobody likes to admit but it matters: it's a lot easier to hire a dev who already knows React than to train someone from scratch to understand the custom architecture you've been building for years. That matters even more for a company that needs to scale its team fast. So maybe the right question isn't "framework or not" but "framework for which situation." A simple landing page, a quick prototype, an internal tool three people use, a site that prioritizes performance above everything — that's when skipping the heavy framework makes total sense. A product that's going to grow, needs a bigger team, has a tight deadline, and can't afford to reinvent a router from scratch — that's when the framework pays back its own learning cost pretty quickly. One practical way to decide, without just going on opinion: look at the expected size of the project, the size of the team that's going to touch it, the deadline you're working with, and whether the goal is learning or shipping. Side project to study fundamentals? Go as vanilla as you can. Product that needs to launch in three weeks with a team of five? Solid, established framework, no hesitation. In the end I don't think it's about picking a side in a war the community has been fighting for years without a winner. It's about understanding what each path actually costs you — time now or headaches later — and making that choice with your eyes open, instead of just copying whatever the most-viewed YouTube video told you to do. So what about you, do you code without a framework on any project or do you not even consider it? Tell us in the comments what made you decide one way or the other — sometimes one real story is worth more than any theoretical argument.