Adiós Tailwind: cómo estructurar tu CSS sin frameworks de utilidades
Una desarrolladora abandona Tailwind CSS y documenta lo que aprendió sobre cómo organizar hojas de estilo sin depender de clases de utilidad. Lecciones útiles para equipos PyME.
El punto de quiebre con Tailwind
Julia Evans —autora del blog jvns.ca y referente en la comunidad técnica— publicó un relato honesto sobre por qué decidió dejar Tailwind CSS en sus proyectos personales. No es un ataque al framework: es una reflexión sobre cuándo una herramienta te ayuda y cuándo empieza a estorbarte.
Su conclusión principal: Tailwind funciona bien en equipos grandes con convenciones establecidas, pero en proyectos pequeños o en solitario puede generar HTML difícil de leer y CSS que nadie entiende seis meses después, incluido tú mismo.
Qué encontró al alejarse de Tailwind
Al volver a CSS “vanilla” con algo de estructura propia, Evans identificó varios patrones que le devolvieron el control:
- Separar estilos por responsabilidad: un archivo para tipografía, otro para layout, otro para componentes puntuales. Simple, pero transforma la mantenibilidad.
- Variables CSS nativas (
custom properties): reemplazan gran parte de lo que se busca en un design token de Tailwind, sin dependencias externas. - Clases semánticas en lugar de utilitarias: nombrar las clases por lo que son (
.card-header) en vez de lo que hacen (.p-4.flex.items-center) hace que el HTML vuelva a ser legible. - Cascade layers (
@layer): una característica moderna de CSS que permite controlar el orden de especificidad sin guerras de selectores. Disponible en todos los navegadores modernos desde 2022.
Por qué esto importa más allá del debate de frameworks
El debate Tailwind vs. CSS puro no es nuevo, pero el artículo toca algo más profundo: la deuda técnica de frontend. En Ecuador, muchas PyMEs contratan proyectos web a agencias o freelancers que usan Tailwind porque acelera el prototipo inicial. El problema llega cuando el cliente quiere mantener o escalar ese proyecto internamente y nadie del equipo entiende la sopa de clases en el HTML.
Un sitio con 47 clases de Tailwind por <div> puede ser difícil de auditar para accesibilidad, difícil de depurar en producción y casi imposible de traspasar a otro desarrollador sin una curva de aprendizaje significativa.
El so-what para tu equipo
Si gestionas proyectos web en una PyME o lideras un equipo de desarrollo pequeño, estas acciones concretas valen la pena:
- Documenta la decisión de framework antes de empezar. ¿Quién va a mantener esto en 12 meses? ¿Ese perfil conoce Tailwind?
- Evalúa CSS moderno antes de instalar otra dependencia.
@layer,container queriesycustom propertiesresuelven muchos problemas sin npm. - Si usas Tailwind, agrega una guía de convenciones al repositorio. Sin reglas, cada desarrollador lo usa diferente y el resultado es peor que no usarlo.
- Audita el HTML generado de tus proyectos actuales. Si no puedes leerlo en 30 segundos, hay deuda técnica acumulada.
La lección de fondo
No existe el framework correcto en abstracto. Existe la herramienta correcta para el contexto: el equipo, la longevidad del proyecto y quién lo va a mantener. Evans lo demuestra con un caso real y código. Vale la pena leer el artículo completo si tu equipo está evaluando cómo organizar su CSS en 2026.
Fuente: jvns.ca — Moving away from Tailwind, and learning to structure my CSS
Fuente original: HN.