The Case Against UI Frameworks
Ask a developer why they reached for Bootstrap, Material UI, or Ant Design, and you'll typically hear one of three answers: they want a polished, professional look without a design background; they want to move fast without building every component from scratch; or they want accessible, usable components like modals and tooltips that are genuinely hard to get right. All of those are reasonable goals. The question is whether a UI framework is actually the best tool to achieve them.
Design Is More Than a Box of Parts
The most common motivation is also the most flawed. Developers without design training assume that dropping in professionally designed components will give them a professionally designed product. But that logic conflates the pieces with the whole.
Anyone who has built a LEGO set knows the difference between having the bricks and knowing where each brick goes. A 200-page instruction book is what turns a pile of high-quality parts into a recognizable Nintendo Entertainment System. Component libraries are the same: they hand you nice buttons and date pickers, but assembling them into a coherent interface is still your job. The designers at Google can make Material Design sing. The third-party apps in the Android App Store, full of the same components, demonstrate that access to the parts doesn't confer the skill.
Good design is an exercise in balance, spacing, and consistency—intangible qualities that no component library can hand you. What's more, every real product has unique requirements that no library anticipates. When you need a component that doesn't exist in the system, you have to invent one that blends in with the framework's aesthetic. That is, in practice, really friggin' hard. It's a problem for people who don't have design chops, and it's a non-issue for people who do.
The Tortoise and the Hare
The time-saving argument fares better, but only in the short term. During two years teaching web development bootcamps at Concordia University, a consistent pattern emerged. Students who started with Bootstrap or Material UI made rapid progress in the first few days. Then the momentum stalled as the gap widened between what they needed and what the framework provided. They spent enormous effort fighting the components to fit their specific use cases.
One memorable student burned an entire afternoon attempting to modify a CSS framework's masthead to accommodate their navigation. Eventually they scrapped it and rebuilt the header from scratch in ten minutes. Writing your own styles is like writing tests: the early investment slows you down, but it pays dividends in the long run.
Accessibility Has Better Options
The accessibility argument is the most legitimate. The web platform lacks a robust standard library for dialogs, menus, and tooltips. Building a modal that works for mouse, keyboard, and screen reader users is genuinely difficult. Most UI frameworks treat accessibility as a secondary concern, and results vary widely.
There is, however, a different category of tool that solves precisely this problem without imposing a visual design system. These accessibility-first primitives stay agnostic about cosmetics while covering the hardest interaction patterns:
- Reach UI — React primitives from Ryan Florence, co-creator of React Router and Remix.
- Headless UI — Unstyled, accessible components for React and Vue from the Tailwind team.
- Radix Primitives — Unstyled, accessibility-focused React components with an unusually broad component set.
- React ARIA — Hooks for building accessible components from scratch.
Nobody should be hand-rolling a modal in 2022. But the choice isn't between that and a styles-included UI framework.
Fair Rebuttals
Not every argument for UI frameworks is without merit. One worth taking seriously is familiarity. Tools like Bootstrap are widely understood, which eases onboarding and lets new team members get productive without absorbing a custom system's quirks. For agencies juggling short and medium-term projects, that shared baseline has real value — though it's worth noting that product companies like Khan Academy (with Wonder Blocks) and DigitalOcean (with Walrus) have consistently chosen to build in-house design systems instead.
Internal tools are another legitimate case. When the audience is a small team of coworkers rather than the general public, and the goal is to spin something up fast, the convenience of dropping in third-party components can outweigh the aesthetic limitations.
Where Tailwind and Chakra UI Fit
It's important to distinguish this category from tools like Tailwind CSS and Chakra UI. Tailwind doesn't provide components at all — it provides design tokens that act as guardrails. That still requires design intuition, but it lowers the bar significantly. Chakra UI does ship styled components, but they're deliberately minimal, resembling improved platform defaults rather than an opinionated aesthetic.
The crucial difference: these tools don't claim to solve design for you. They nudge you in a good direction while keeping everything customizable, so you never get locked into a look that doesn't fit your product.
Building Design Skills Without a Framework
For solo developers without a design background, the path to a professional-looking product doesn't have to run through a UI framework. But it does require a modest investment in learning how design works.
Start With Design Fundamentals
You don't need art school or years of practice. The goal isn't to become a world-class designer; it's to reach a level where your work feels intentional and polished. And you're probably closer than you think.
Front-end developers make design decisions constantly, even when working from detailed mockups. Design files rarely cover every scenario. You'll have to decide how a layout behaves between specified breakpoints, what happens when data is longer or shorter than expected, and how loading, empty, and error states should look.
Developing enough design sense to handle these gaps unblocks you when you can't reach a designer. It's a skill you can build deliberately. If you work with a design team, study their work and ask questions—most designers are happy to explain their decisions. If you don't, deconstruct the apps and sites you use daily. Notice spacing, font sizes, and layout patterns. With practice, you'll see recurring conventions.
Steal, Then Mix
Even with good intuition, designing from scratch is hard. So don't. Use existing work as a starting point.
Search design communities like Dribbble or Behance, or browse design archives like Awwwards for projects that resemble what you're building. Real-world products work too if you want something more grounded.
The key is not to copy a single design wholesale—that's plagiarism. Instead, pull from multiple sources. Take a color palette from one site, a layout structure from another, and typography from a third. Blend them into something that's yours.
Designers themselves admit this is standard practice. It still requires judgment: your reference designs won't perfectly match your needs, and you'll have to fill in the gaps with intuition. But it's the fastest route to a credible, custom-feeling result.
The Real Bottleneck: CSS
Assuming you can get the visuals right, CSS remains a stumbling block for many front-end developers. It's a genuinely tricky language, and frustration can persist even after years of experience.
This is why tools like the CSS for JavaScript Developers course exist—to give developers who work in React, Angular, or similar environments a solid mental model of how CSS behaves. A strong foundation makes the language feel predictable rather than capricious.
When CSS stops being a mystery, the need for a UI framework to compensate for design and styling gaps becomes far less necessary. The combination of basic design literacy, borrowed-but-blended references, and steady CSS knowledge is enough to ship work that holds up.
