“Time is money” has never been more relevant. Since 2022, front-end developers have prioritized speed over perfection, adopting a “good enough UI” approach that meets these key criteria:
- 80%+ Lighthouse score – ensuring performance, accessibility, and SEO.
- Smooth, responsive UI – free of lags or glitches.
- Well-designed UX/UI – visually appealing and user-friendly.
- Mobile-friendly – optimized for most web traffic.
- Minimal JS – reducing performance overhead.
I’m not saying you should follow this approach — just highlighting the current market trend. Companies are tired of waiting weeks for UI development. It’s an oversimplification, but the shift feels inevitable — much like the adoption of calculators (which, yes, mathematicians once protested!).
Tailwind emerged from this trend and gained momentum with AI’s rise — in 2025, UI delivery speed is lightning-fast. Like any tool, it has pros and cons, but its modern design and market alignment have made it the top choice for most new websites.
As the community embraced Tailwind, an ecosystem of tools — Figma plugins, AI assistants, IDE extensions, and low-code platforms — emerged to streamline UI development. This momentum makes dethroning Tailwind a challenge.
I called it Top 1 in the title not because it’s flawless — it has drawbacks — but because its unique combination of features and balance perfectly aligns with market trends. To explain why, we need to dive deep into the history, context, and iterations of web styling.
Let’s do that today!
This timeline highlights key solutions, with estimated dates, as pinpointing exact occurrences is difficult. Also, keep in mind that many of these developments happened in parallel.
Stage 1: Early Styling (The Wild West of Websites)
Have you ever seen websites like these?
Before the CSS3 specification, this was common due to significant limitations in web technologies. Code like this was widespread:
// The beginning... Early 1990s - Mid-1990s
<font color="red" size="4">Hello, World!</font>
// Mid-1990s Inline CSS
<p style="color: blue; font-size: 16px;">This is a paragraph.</p>
Imagine the “WOW” effect when this arrived:
// Internal & External Stylesheets (Late 1990s - Early 2000s)
<style>
p { color: blue; font-size: 16px; }
</style>
// or
<link rel="stylesheet" href="styles.css">
Back then, styling was extremely limited and often felt “dirty.”
Stage 2: CSS3 Arrival and Everything Changed
CSS3 evolved as a series of modules, with features being introduced over time. While development started in the mid-2000s, full standardization and widespread adoption occurred gradually, with many features becoming mainstream in the 2010s. Here’s a small overview of important changes and features:
- Modularization
- JS Reduction
- Box Model Changes
- Flexbox
- CSS Grid
- … and an insane amount of new stuff each month.
The styling codebase started to look like this:
.grid-container {
display: grid;
grid-template-columns: repeat(3, 1fr);
}
And websites’ look and feel improved as well:
CSS continues to evolve through new modules under the CSS3 umbrella. Rather than following a versioning system, CSS is constantly updated and refined. This process is still ongoing today.
Stage 3: CSS Methodologies to the Rescue
As CSS3 was widely adopted, developers began to encounter recurring problems in larger codebases:
- Naming collisions: Overlapping class names can cause styling conflicts in a shared codebase.
- Fragile UI: Poor structure makes small changes risky, potentially breaking large sections.
- Style leaks: Unintended styles can affect unrelated components.
- Inconsistent naming: Different naming conventions lead to confusion and maintenance issues.
- No clear layering: Mixing global, base, and component styles makes management harder.
To tackle these challenges, CSS methodologies emerged to introduce structure and consistency. Let’s explore some popular approaches that help organize large-scale projects.
OOCSS in 2009 by Nicole Sullivan
To address these issues, Object-Oriented CSS was introduced, laying the foundation for future methodologies. Its key principles are:
- Separation of Structure from Skin – Keep layout (e.g., spacing, positioning) separate from visual styles (e.g., colors, fonts).
/* Structure: Defines reusable layout and spacing */
.card {
display: flex;
flex-direction: column;
width: 300px;
padding: 16px;
}
/* Skin: Defines appearance (color, typography) */
.card-default {
background-color: #fff;
color: #333;
}
.card-dark {
background-color: #333;
color: #fff;
}
/* Typography (Reusable styles for text) */
.card-title {
font-size: 20px;
}
- Separation of Container from Content – Ensure components are reusable and not dependent on specific parent elements.
/* Problem: Card styles depend on a specific container */
.card-container .card {
width: 300px;
padding: 16px;
}
.card-container .card h2 {
font-size: 20px;
}
<div class="card-container">
<div class="card">
<h2>Card Title</h2>
<p>Card content goes here.</p>
</div>
</div>
/* Good: Reusable card structure */
.card {
width: 300px;
padding: 16px;
}
/* Reusable typography */
.card-title {
font-size: 20px;
}
<!-- Card used independently -->
<div class="card">
<h2 class="card-title">Standalone Card</h2>
<p>Can be placed anywhere.</p>
</div>
This methodology suited grouped UI components but lacked guidance for smaller elements like fonts, positioning, and layout. As a result, it was applied selectively, leaving other styles unstructured.
BEM Methodology in 2010 by Yandex
BEM (Block, Element, Modifier) was another approach to solving the problem of chaotic CSS structures. It tackled the issue by introducing strict naming conventions:
Block: A standalone entity (e.g., .card).
Element: A child of a block (e.g., .card__title).
Modifier: A variation of a block or element (e.g., .card–featured).
/* Block */
.card {
border: 1px solid #ddd;
border-radius: 8px;
}
/* Elements */
.card__image {
width: 100%;
border-radius: 8px 8px 0 0;
}
.card__title {
font-size: 1.5rem;
margin: 8px 0;
}
/* Modifier */
.card--featured {
background-color: #ffefc3;
}
BEM reduced naming conflicts and added structure, but its verbosity quickly became frustrating, often cluttering HTML…
<nav class="navbar">
<ul class="navbar__menu">
<li class="navbar__menu-item navbar__menu-item--active">Home</li>
<li class="navbar__menu-item">About</li>
<li class="navbar__menu-item navbar__menu-item--disabled">Contact</li>
</ul>
</nav>
While BEM structured CSS, managing deep nesting became tedious, and debugging felt like deciphering a puzzle of underscores and hyphens. It was progress, but developers sought a simpler approach. A common complaint was handling edge cases where multiple classes applied to different blocks, leading to frequent refactoring in larger projects.
<div class="profile">
<div class="profile__header">
<!-- Issue here -->
<h2 class="card__title">John Doe</h2>
</div>
<div class="profile__content">
<p class="profile__text">Web Developer</p>
</div>
</div>
The issue mentioned in OOCSS also exists here — there are no guidelines for smaller elements that aren’t related to “chunks of UIs.”
SMACSS in 2011 by Jonathan Snook
An approach already existed to address the lack of separation of concerns and real architectural division
— SMACSS (Scalable and Modular Architecture for CSS). It introduced a layered structure to CSS:
- Base – Default styles for HTML elements.
- Layout – Major layout components.
- Module – Reusable, modular parts of the UI.
- State – Styles for different states (active, expanded, etc.)
- Theme – Swappable visual styles.
Unlike BEM or OOCSS, SMACSS wasn’t about strict naming conventions but rather about organizing styles into separate layers for better maintainability.
/* 1. BASE - Default styles */
body { font-family: Arial, sans-serif; }
/* 2. LAYOUT - Major site sections */
.l-container { max-width: 1200px; margin: 0 auto; }
/* 3. MODULE - Reusable components */
.btn { display: inline-block; padding: 8px 16px; border-radius: 4px; }
/* 4. STATE - Different states */
.is-active { font-weight: bold; }
/* 5. THEME - Swappable visual styles */
.theme-dark { background-color: #222; color: #eee; }
SMACSS was often combined with BEM or OOCSS, providing structure while relying on other methodologies for naming.
However, managing layers meant frequently shifting styles between categories. Even a simple color change could require moving a class to a different file, making refactoring a constant challenge.
Atomic CSS in 2013 by Yahoo
Atomic CSS (also known as Functional CSS) introduced single-purpose classes, each handling just one styling property. An early example from Yahoo’s Atomic CSS framework:
<... class="Bfc P(10px) M(20px) C(#333) Fz(20px)">
Nonetheless, it paved the way for utility-first frameworks like Bootstrap and Tailwind. Whether the idea emerged independently elsewhere or not, atomic styling gained traction because it simply worked. However, at the time, its design was still too immature to achieve widespread adoption.
Enduring CSS by Ben Frain in 2014
ECSS focuses on strong encapsulation, avoiding global styles, and enforcing component-based naming for maintainability. Here’s what it offered:
- Scoped selectors (Component-based naming).
- No global styles except resets.
- Minimal nesting for better maintainability.
/* Instead of using generic `.button`, we scope it */
.article__button {
background: green;
color: white;
}
/* Strong encapsulation avoids leaks */
.profile-card__image {
width: 100px;
}
This approach was also less popular… As you can see, many methodologies were just developers iterating on each other’s ideas — tweaking solutions for specific problems while inevitably creating new ones in the process.
Inverted Triangle CSS by Harry Roberts in 2015
ITCSS structures CSS in a layered hierarchy, making it scalable and maintainable. It moves from generic, low-specificity styles to highly specific ones.
Layered structure of ITCSS:
- Settings – Global variables, colors, typography, etc.
- Tools – Mixins, functions (if using a preprocessor like SCSS).
- Generic – Like Resets.css, Normalize.css, base styles.
- Elements – Default styling for HTML tags (h1, p, a, etc.).
- Objects – Reusable design patterns (e.g., .container).
- Components – Specific UI elements (.card, .button).
- Trumps – Utility classes that override everything (.hidden, .text-center).
/* Settings */
:root {
--primary-color: #3498db;
--font-main: Arial, sans-serif;
}
/* Tools */
@mixin flex-center {
display: flex;
justify-content: center;
align-items: center;
}
/* Generic */
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
/* Elements */
h1 {
font-family: var(--font-main);
color: var(--primary-color);
}
/* Objects */
.container {
max-width: 1200px;
margin: 0 auto;
}
/* Components */
.button {
background: var(--primary-color);
color: white;
padding: 10px 20px;
border-radius: 5px;
}
/* Trumps */
.hidden {
display: none !important;
}
Still, it was just a convention and remained less popular. However, I’ve seen projects adopt similar ideas — not strictly following these guidelines but clearly inspired by them. I can’t say for sure they were based on this exact approach, but they shared common principles.
Composition, Utility, Block, Exception by Andy Bell in 2021
CUBE CSS is a structured approach that balances layout composition, reusable components, and utility classes with scoped exceptions.
/* Composition (Layout rules) */
.flex {
display: flex;
gap: 1rem;
}
.grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
}
/* Utility */
.text-center {
text-align: center;
}
.margin-lg {
margin: 2rem;
}
/* Block */
.card {
padding: 1rem;
background: #f5f5f5;
}
/* Exception */
.card.featured {
background: yellow;
}
As you can see, the author addressed edge cases by treating them as exceptions. This approach explicitly accounted for necessary deviations, whereas earlier methodologies struggled with rigid structures — making any deviation feel like breaking the rules. CUBE CSS tackled this issue directly.
Stage 4: The Preprocessors Era
As the name suggests, preprocessors transform meta-syntax into plain CSS during the build process, as browsers only interpret standard CSS.
Alongside the previously mentioned methodologies, CSS preprocessors like Sass (2006), Less (2009), and Stylus (2010) became essential tools, providing:
- Variables for consistent values
$primary-color: #3498db;
button {
background-color: $primary-color;
}
- Vendor-prefixing (adding alternative directives for different browsers via plugins)
- Nesting for clearer selector relationships
.navbar {
background: #333;
a {
color: inherit;
}
}
- Mixins for reusable style patterns
@mixin flex-center {
display: flex;
align-items: center;
justify-content: center;
}
.container {
@include flex-center;
height: 100vh;
}
Functions for parameterized calculations
@function generate-list($count) {
$output: '';
@for $i from 1 through $count {
$output: #{$output} 'li:nth-child(#{$i}) { font-size: #{$i * 2}px; } ';
}
@return unquote($output);
}
ul {
@include generate-list(10);
}
- …and many other features missing in plain CSS
Preprocessors solved many issues but required careful organization to avoid messy CSS. Developers often paired them with methodologies like BEM, SMACSS, or ITCSS for better structure and scalability.
// Sass preprocessor example + BEM
$primary-color: #3490dc;
.card {
&__title {
color: $primary-color;
}
&--featured {
box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
}
}
The mix of preprocessors and conventions improved UI maintainability, but real encapsulation was still missing. Styles could still leak across components, making independent work tricky…
Want to know more about the next stages, including encapsulation with CSS modules, the impact of CSS-in-JS and – finally –Tailwind CSS’ arrival? Read part 2 of this article.
