Querido Geary,

He leído tu artículo y, con respeto, creo que el planteamiento queda bastante condicionado por el marco: en la práctica no es «Tailwind vs BEM», sino Tailwind vs (BEM/ACSS + Etch). Cuando comparas un framework con un entorno que neutraliza varias ventajas típicas del otro (cambio de contexto, aislamiento, automatismos), la conclusión sale casi decidida desde el inicio. Puede ser válida dentro de tu stack, pero cuesta aceptarla como tesis general.

Sobre los tokens: son muy valiosos cuando codifican decisiones del sistema (coherencia, escalas compartidas, tematización, mantenimiento global). Pero si se convierten en regla universal para valores puntuales, añaden indirección sin aportar valor real. No es anti-tokens; es «tokens cuando aportan sistema».

También me chirría cómo se arma el argumento con ciertas herramientas. En algunos textos parece que los paneles son «malos» por defecto o síntoma de un flujo inferior, pero en la práctica con Bricks + Tailwind se puede trabajar casi sin paneles si el flujo está bien planteado. Y cuando el panel encaja con ACSS o con tu forma de trabajar, entonces pasa a ser «fantástico». Los paneles no son buenos o malos: son una herramienta, y el juicio debería depender del objetivo y los trade-offs, no de la bandera del stack.

Algo similar con la IA: se critica como si degradara el trabajo, pero luego aparece en ejemplos para generar o apoyar componentes concretos. No pasa nada por usarla; el problema es el mensaje implícito de «esto es malo… salvo cuando lo uso yo». Ese doble rasero debilita el debate.

Y ya que quiero responderte con claridad, también sobre tu comentario de Bricks 2.2 (lo de «secuestra», «roba», «cinta adhesiva»…): sinceramente, ese framing me parece más retórico que técnico. En software las ideas convergen, se inspiran, se adaptan y se mejoran. Si vamos a usar “copiar ideas” como descalificador, entonces también habría que reconocer que un editor HTML+CSS+JS integrado no nació en Etch: ya existía en entornos como LiveCanvas. Lo relevante no es quién lo hizo primero, sino qué tan bien se integra, qué problemas resuelve y con qué costes.

Y te lo digo con un ejemplo para que se entienda el punto: si mañana sacaras tu propio CMS, sospecho que de repente WordPress pasaría a ser «malo malísimo» por todo lo que no hace como tu CMS, resaltando sus límites como si fueran defectos imperdonables. Pero la realidad es que nada es blanco o negro: cada herramienta tiene compromisos, cada equipo tiene un contexto, y cada uno tiene sus preferencias y metodología.

Por eso, más allá de gustos técnicos, lo único que pediría es respeto: se puede defender un enfoque sin convertir la crítica a los demás en un argumento de venta, ni presentar al resto como si estuvieran equivocados o atrasados por elegir otra vía. Un ecosistema sano mejora cuando discutimos trade-offs de forma honesta, no cuando reducimos el debate a «lo mío es lo correcto».

Un saludo.