A few years back, on a small project that was supposed to take two weeks and ended up dragging on for four months, I asked myself the wrong question. I asked "which framework is better," when what I should've asked was "what is this specific project going to need six months from now." That's basically the confusion most people bring when they search this. There's no single answer, and anyone who tells you there is one is selling you something — a course, a clickbait article, or they simply haven't worked on enough different projects to realize that context matters more than personal preference. The first thing that usually tips the decision is initial speed. Bootstrap, Bulma, even Tailwind with the right UI components already set up, will get you a working, reasonably good-looking site in hours. That's real, and there's no point pretending otherwise. The problem shows up later, usually around month three or four, when you need a layout the framework never anticipated and end up spending more time overriding classes with !important than you would've spent just writing the original CSS. I've seen teams burn entire days trying to make a Bootstrap site look "less Bootstrap." This isn't a universal rule, just a pattern that repeats often enough to be worth saying out loud. ## <br>Weight, and why the numbers everyone quotes are misleading Then there's the weight question, probably the most cited argument and, at the same time, the most misunderstood one. Full minified and gzipped Bootstrap CSS runs around 25 to 30kb. That's tiny next to a single poorly optimized JPEG, which alone can easily beat that number. The real problem is almost never the framework itself — it's dead CSS sitting in the final build because nobody configured purge properly. With Tailwind, running JIT mode with purge enabled, it's common to see final bundles between 5 and 15kb, often lighter than a "pure" Bootstrap setup. That surprises people who still picture Tailwind as thousands of bulky utility classes cluttering the HTML. Which brings up something worth pausing on, because it trips a lot of people up. Tailwind isn't a framework in the classic sense of the word. Bootstrap hands you ready-made components — a styled button, a navbar, a card. Tailwind hands you loose pieces, low-level utility classes, and makes you assemble every component yourself. Comparing "Tailwind versus from scratch" is, in practice, closer to comparing "writing CSS with shortcuts" against "writing CSS without shortcuts" than to the classic Bootstrap-versus-plain-CSS debate. People lump both conversations together as if they were the same thing, and they aren't. One point that rarely shows up in generic articles on this, but that in my experience matters more than file weight, is visual consistency on small teams without a dedicated designer. If you're three developers building a product with no one owning the design side, a framework enforces, even if a bit rigidly, a coherent system of spacing, colors, typography. Writing everything from scratch without that discipline tends to produce, over time, a visual Frankenstein — a button with 8px of padding here, another with 12px there, nobody really in control because nobody has the time or the clear responsibility for it. It's not that plain CSS causes inconsistency by nature. It's that lack of convention does, and frameworks impose convention by default, whether you like it or not. That idea that "every site built with a framework looks the same" is also half true and half exaggerated myth. It's true mainly when someone uses Bootstrap or Bulma straight out of the box, without touching theme variables, without swapping colors, without adjusting typography. In that case, yeah, you can spot a Bootstrap site from a hundred feet away. With Tailwind this almost never happens, because the tool's whole philosophy forces you to define the look from the start — you don't inherit a ready-made layout, you build yours out of neutral utilities. Funnily enough, the people who complain most about "cookie-cutter sites" usually never used Tailwind seriously, they just saw a screenshot of default Bootstrap. ## <br>Long-term maintenance is where things get uncomfortable for framework lovers Long-term maintenance is where things get uncomfortable for people who like frameworks. Projects meant to last years, with teams that turn over, tend to benefit more from custom CSS, well documented, following some methodology like BEM or CUBE CSS, precisely because they don't depend on a third party's architectural decisions. The jump from Bootstrap 4 to 5 broke a fair amount of code out there, and anyone who went through it knows it wasn't just bumping a version number in package.json. Depending on a framework also means depending on someone else's roadmap, and that has a cost that only shows up two or three years later, when it's too late to easily walk it back. So where does that leave someone who just wants to decide what to do on the project sitting in front of them right now? For a prototype, an MVP, an internal dashboard nobody outside the team will ever see, a framework wins almost every time — the speed more than makes up for any visual rigidity. For a product with a strong brand identity, a landing page that needs to stand out, an e-commerce site where the look is part of the perceived value, custom CSS or a heavily configured Tailwind setup tends to pay off better. Small teams with nobody thinking about design benefit from the framework as a structural crutch. Teams with a strong designer and an already-defined design system usually feel a generic framework as a hindrance, something that gets in the way more than it helps, because they already have their own rules and the framework insists on its own. One common mistake, and I see this a lot, is comparing framework weight without accounting for purge or tree-shaking — that skews the whole conversation, because you end up comparing the worst-case scenario on one side against the best-case scenario on the other. Another mistake is assuming "from scratch" is automatically lighter or faster. It only is if the team already has CSS architecture discipline. Without that discipline, from-scratch CSS tends to pile up dead rules, out-of-control specificity, repeated selectors, and ends up heavier and harder to maintain than any well-configured framework. It's also worth avoiding treating Tailwind and Bootstrap as the same category of choice, because they're not, and the right answer shifts depending on which of the two is actually on the table. And then there's the crowd that picks a framework just because "it's what the market uses," without stopping to ask whether the project — often a small, static, four-page site — actually needs all that machinery. Sometimes it does. Sometimes it's like using a truck to go buy bread. In the end, the question worth asking isn't "framework or from scratch," it's more concrete than that: how long is this project going to live, who's going to touch it a year from now, and is anyone actually thinking about design or not. Answer that first. Everything else tends to sort itself out.