Voy a decir algo que podría herir algunos sentimientos: dejé de usar Tailwind CSS en nuevos proyectos a finales de 2025 y no he mirado atrás. No porque Tailwind sea malo -- es genuinamente excelente en lo que hace. Pero porque CSS vanilla se ha vuelto tan bueno que los compromisos ya no tienen sentido para el tipo de proyectos que construimos.

Los tokens de diseño están en el corazón de este cambio. La idea de almacenar tus decisiones de diseño como variables reutilizables e independientes de la plataforma no es nueva. Pero las herramientas y el soporte de navegador para propiedades personalizadas CSS en 2026 han madurado al punto en que puedes construir un sistema completo de tokens de diseño sin pasos de compilación, sin dependencias y sin necesidad de memorizar clases de utilidad. Déjame mostrarte cómo.

Tabla de Contenidos

Tokens de Diseño CSS Vanilla Sin Tailwind en 2026

Qué son realmente los Tokens de Diseño

Los tokens de diseño son los valores atómicos que definen tu lenguaje visual. Colores, espaciado, tipografía, sombras, radios de borde, duraciones de animación -- cualquier cosa que represente una decisión de diseño. El término fue acuñado por el equipo de diseño de Salesforce en 2014, pero el concepto ha evolucionado significativamente.

Here's the key insight most people miss: design tokens aren't just variables. They're a contract between design and engineering. When your designer says "use the primary action color," that maps to a token, not a hex value. When they say "medium spacing," that's a token too.

El grupo comunitario de tokens de diseño de W3C publicó la especificación del módulo de formato de tokens de diseño, y aunque aún está evolucionando, las ideas principales se han solidificado. Los tokens existen en capas:

  1. Tokens primitivos (valores brutos como #1a73e8 o 16px)
  2. Tokens semánticos (alias dirigidos por propósito como color-action-primary)
  3. Tokens de componente (limitados a elementos UI específicos como button-background)

Esta arquitectura de tres capas es lo que hace manejables los sistemas a gran escala. Las propiedades personalizadas CSS se adaptan perfectamente a ella.

Por qué CSS Vanilla me Ganó

Séame honesto sobre mi viaje. Usé Tailwind felizmente durante años. Construí sitios de producción con él. Lo recomendé a clientes. Pero varias cosas cambiaron:

CSS se ha puesto al día. Anidación, :has(), container queries, @layer, @scope, color-mix(), oklch(), sintaxis de color relativo -- estas no son características experimentales. Son base en todos los navegadores principales en 2026. ¿El vacío que llenaban los frameworks de utilidad? Se ha encogido drásticamente.

El tamaño del bundle importa más que nunca. Con Core Web Vitals impactando directamente en rankings de búsqueda, cada kilobyte cuenta. Un sistema de tokens de diseño CSS vanilla bien estructurado pesa casi nada. El compilador JIT de Tailwind es ingenioso, pero aún envía CSS para cada utilidad que usas.

El costo de mantenimiento es real. He heredado proyectos de Tailwind donde los componentes tienen 30+ clases de utilidad encadenadas. Leer className="flex items-center justify-between px-4 py-2 bg-white dark:bg-gray-800 rounded-lg shadow-sm hover:shadow-md transition-shadow duration-200 border border-gray-200 dark:border-gray-700" no es divertido. Con tokens de diseño y una capa delgada de CSS, la intención es más clara.

La entrega entre diseño e ingeniería mejoró. Cuando los tokens en CSS coinciden con tokens en Figma 1:1, las conversaciones se vuelven precisas. No más "¿qué clase de Tailwind se asigna a esta variable de Figma?".

Esto no es una guerra santa. Si Tailwind funciona para tu equipo, sigue usándolo. Pero si estás comenzando algo nuevo y quieres control máximo con abstracción mínima, los tokens de CSS vanilla merecen consideración seria.

Configurando tu Arquitectura de Tokens

Vamos a construir esto desde cero. Usaré la estructura de archivos que hemos refinado en múltiples proyectos de CMS headless en Social Animal, pero adáptalo a tus necesidades.

El principio central: los tokens fluyen hacia abajo a través de capas de especificidad.

tokens/
├── primitives.css       /* Valores brutos */
├── semantic.css         /* Alias dirigidos por propósito */
├── components/
│   ├── button.css
│   ├── card.css
│   └── input.css
├── themes/
│   ├── light.css
│   └── dark.css
└── index.css            /* Orquestación de importaciones */

Tu index.css usa @layer para establecer una cascada clara:

@layer primitives, semantic, themes, components;

@import './primitives.css' layer(primitives);
@import './semantic.css' layer(semantic);
@import './themes/light.css' layer(themes);
@import './components/button.css' layer(components);
@import './components/card.css' layer(components);
@import './components/input.css' layer(components);

Esto es importante. @layer te da control explícito sobre la cascada sin luchar contra la especificidad. Los tokens primitivos son anulados por tokens semánticos, que son anulados por temas, que son anulados por componentes. Jerarquía limpia.

Tokens de Diseño CSS Vanilla Sin Tailwind en 2026 - arquitectura

Tokens Primitivos: Tus Valores Brutos

Los primitivos son tu paleta. No están destinados a ser utilizados directamente en componentes -- piensa en ellos como la pintura en tu estante antes de decidir qué pintar.

/* primitives.css */
:root {
  /* Colores usando OKLCH para paletas perceptualmente uniformes */
  --color-blue-50: oklch(0.97 0.01 250);
  --color-blue-100: oklch(0.93 0.03 250);
  --color-blue-200: oklch(0.87 0.06 250);
  --color-blue-300: oklch(0.78 0.10 250);
  --color-blue-400: oklch(0.68 0.15 250);
  --color-blue-500: oklch(0.58 0.19 250);
  --color-blue-600: oklch(0.50 0.19 250);
  --color-blue-700: oklch(0.42 0.17 250);
  --color-blue-800: oklch(0.35 0.14 250);
  --color-blue-900: oklch(0.27 0.10 250);

  /* Escala de espaciado (modular, basada en grid de 4px) */
  --space-1: 0.25rem;   /* 4px */
  --space-2: 0.5rem;    /* 8px */
  --space-3: 0.75rem;   /* 12px */
  --space-4: 1rem;      /* 16px */
  --space-5: 1.25rem;   /* 20px */
  --space-6: 1.5rem;    /* 24px */
  --space-8: 2rem;      /* 32px */
  --space-10: 2.5rem;   /* 40px */
  --space-12: 3rem;     /* 48px */
  --space-16: 4rem;     /* 64px */
  --space-20: 5rem;     /* 80px */
  --space-24: 6rem;     /* 96px */

  /* Escala tipográfica */
  --font-size-xs: 0.75rem;
  --font-size-sm: 0.875rem;
  --font-size-base: 1rem;
  --font-size-md: 1.125rem;
  --font-size-lg: 1.25rem;
  --font-size-xl: 1.5rem;
  --font-size-2xl: 1.875rem;
  --font-size-3xl: 2.25rem;
  --font-size-4xl: 3rem;

  /* Pesos de fuente */
  --font-weight-normal: 400;
  --font-weight-medium: 500;
  --font-weight-semibold: 600;
  --font-weight-bold: 700;

  /* Radio de borde */
  --radius-sm: 0.25rem;
  --radius-md: 0.5rem;
  --radius-lg: 0.75rem;
  --radius-xl: 1rem;
  --radius-full: 9999px;

  /* Sombras */
  --shadow-sm: 0 1px 2px oklch(0 0 0 / 0.05);
  --shadow-md: 0 4px 6px oklch(0 0 0 / 0.07);
  --shadow-lg: 0 10px 15px oklch(0 0 0 / 0.1);
  --shadow-xl: 0 20px 25px oklch(0 0 0 / 0.1);

  /* Duraciones */
  --duration-fast: 100ms;
  --duration-normal: 200ms;
  --duration-slow: 300ms;
  --duration-slower: 500ms;
}

Estoy usando OKLCH aquí porque es un espacio de color genuinamente mejor. A diferencia de HSL, la ligereza en OKLCH es perceptualmente uniforme -- una ligereza de 0.5 realmente parece gris medio independientemente del matiz. Tus escalas de color se ven consistentes en todo el espectro. Todos los navegadores principales la soportan ahora.

Tokens Semánticos: Donde Ocurre la Magia

Los tokens semánticos hacen referencia a primitivos y les dan significado. Esta es la capa que hace que la tematización sea posible y que tu CSS sea autodocumentado.

/* semantic.css */
:root {
  /* Colores de superficie */
  --color-surface-primary: var(--color-white, #fff);
  --color-surface-secondary: var(--color-gray-50);
  --color-surface-tertiary: var(--color-gray-100);
  --color-surface-inverse: var(--color-gray-900);

  /* Colores de texto */
  --color-text-primary: var(--color-gray-900);
  --color-text-secondary: var(--color-gray-600);
  --color-text-tertiary: var(--color-gray-400);
  --color-text-inverse: var(--color-white, #fff);
  --color-text-link: var(--color-blue-600);
  --color-text-link-hover: var(--color-blue-700);

  /* Colores de acción */
  --color-action-primary: var(--color-blue-600);
  --color-action-primary-hover: var(--color-blue-700);
  --color-action-primary-active: var(--color-blue-800);

  /* Colores de retroalimentación */
  --color-feedback-success: var(--color-green-600);
  --color-feedback-warning: var(--color-amber-500);
  --color-feedback-error: var(--color-red-600);
  --color-feedback-info: var(--color-blue-500);

  /* Colores de borde */
  --color-border-primary: var(--color-gray-200);
  --color-border-secondary: var(--color-gray-100);
  --color-border-focus: var(--color-blue-500);

  /* Espaciado semántico */
  --space-inline-xs: var(--space-1);
  --space-inline-sm: var(--space-2);
  --space-inline-md: var(--space-4);
  --space-inline-lg: var(--space-6);
  --space-stack-xs: var(--space-1);
  --space-stack-sm: var(--space-2);
  --space-stack-md: var(--space-4);
  --space-stack-lg: var(--space-8);
  --space-stack-xl: var(--space-12);
}

Fíjate en que nada aquí es un valor codificado. Todo hace referencia a primitivos. Si quieres cambiar de marca mañana, cambias los primitivos. Si quieres ajustar cómo se siente "acción primaria", cambias los tokens semánticos. El código del componente nunca necesita saberlo.

Tokens de Componente: La Capa Final

Los tokens de componente limitan las decisiones de diseño a elementos UI específicos. Esto es opcional para proyectos pequeños pero esencial para cualquier cosa con un sistema de diseño.

/* components/button.css */
.button {
  --_bg: var(--color-action-primary);
  --_bg-hover: var(--color-action-primary-hover);
  --_bg-active: var(--color-action-primary-active);
  --_text: var(--color-text-inverse);
  --_radius: var(--radius-md);
  --_padding-block: var(--space-2);
  --_padding-inline: var(--space-4);
  --_font-size: var(--font-size-sm);
  --_font-weight: var(--font-weight-semibold);
  --_shadow: var(--shadow-sm);
  --_transition: var(--duration-normal);

  display: inline-flex;
  align-items: center;
  gap: var(--space-2);
  padding: var(--_padding-block) var(--_padding-inline);
  background: var(--_bg);
  color: var(--_text);
  font-size: var(--_font-size);
  font-weight: var(--_font-weight);
  border-radius: var(--_radius);
  box-shadow: var(--_shadow);
  transition: background var(--_transition), box-shadow var(--_transition);
  border: none;
  cursor: pointer;

  &:hover {
    background: var(--_bg-hover);
    box-shadow: var(--shadow-md);
  }

  &:active {
    background: var(--_bg-active);
  }

  &.--secondary {
    --_bg: transparent;
    --_text: var(--color-action-primary);
    --_shadow: none;
    border: 1px solid var(--color-border-primary);

    &:hover {
      --_bg: var(--color-surface-secondary);
    }
  }

  &.--ghost {
    --_bg: transparent;
    --_text: var(--color-text-primary);
    --_shadow: none;

    &:hover {
      --_bg: var(--color-surface-secondary);
    }
  }
}

La convención de prefijo --_ (con guion bajo) indica tokens de componente "privados". No se aplica por el navegador, pero es una señal clara para otros desarrolladores: estos tokens son internos de este componente.

También -- mira cómo funciona la anidación CSS aquí. Sin preprocesador necesario. Este es CSS nativo en 2026.

Modo Oscuro y Tematización Sin Framework

Aquí es donde la arquitectura de tokens realmente paga dividendos. El modo oscuro se convierte en un asunto de reasignar tokens semánticos.

/* themes/dark.css */
@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-primary: var(--color-gray-900);
    --color-surface-secondary: var(--color-gray-800);
    --color-surface-tertiary: var(--color-gray-700);
    --color-surface-inverse: var(--color-white, #fff);

    --color-text-primary: var(--color-gray-50);
    --color-text-secondary: var(--color-gray-300);
    --color-text-tertiary: var(--color-gray-500);
    --color-text-inverse: var(--color-gray-900);
    --color-text-link: var(--color-blue-400);
    --color-text-link-hover: var(--color-blue-300);

    --color-border-primary: var(--color-gray-700);
    --color-border-secondary: var(--color-gray-800);

    --shadow-sm: 0 1px 2px oklch(0 0 0 / 0.2);
    --shadow-md: 0 4px 6px oklch(0 0 0 / 0.3);
    --shadow-lg: 0 10px 15px oklch(0 0 0 / 0.4);
  }
}

/* Soporte de alternancia manual */
[data-theme="dark"] {
  --color-surface-primary: var(--color-gray-900);
  /* ... mismos cambios ... */
}

Tus componentes no cambian en absoluto. Cero clases de modo oscuro. Cero lógica condicional. Los tokens manejan todo.

¿Quieres un tema de marca para un cliente etiquetado en blanco? El mismo patrón:

[data-theme="client-acme"] {
  --color-blue-500: oklch(0.55 0.20 280); /* Su púrpura en lugar de azul */
  --color-action-primary: var(--color-blue-500);
  --radius-md: 1rem; /* Les gustan las esquinas más redondeadas */
}

Usamos este enfoque extensamente en nuestros proyectos de desarrollo Next.js donde la tematización multi-inquilino es un requisito común.

Tokens Responsivos Con Container Queries

Esto es algo que genuinamente no puedes hacer con Tailwind (al menos no elegantemente). Las container queries te permiten cambiar valores de tokens basados en el tamaño del contenedor, no solo en el viewport.

.card-grid {
  container-type: inline-size;
  container-name: card-grid;
}

@container card-grid (max-width: 500px) {
  .card {
    --_padding: var(--space-3);
    --_title-size: var(--font-size-base);
    --_gap: var(--space-2);
  }
}

@container card-grid (min-width: 501px) {
  .card {
    --_padding: var(--space-6);
    --_title-size: var(--font-size-lg);
    --_gap: var(--space-4);
  }
}

Componentes que responden a su propio contexto en lugar del viewport. Esto es particularmente poderoso al construir bibliotecas de componentes para sitios de Astro donde los componentes se reutilizan en diseños salvajemente diferentes.

Sincronizando Tokens de Diseño Con Figma

Figma Variables (lanzadas en 2023, significativamente expandidas desde entonces) se alinean directamente con nuestro modelo de tokens de tres capas. Aquí está el flujo de trabajo:

  1. Define tokens en Figma usando su panel Variables (primitivos → semánticos → componente)
  2. Exporta tokens usando el plugin Tokens Studio o la API REST de Figma
  3. Transforma a CSS usando Style Dictionary o las nuevas herramientas de Cobalt UI
  4. Confirma en tu repositorio como tu directorio tokens/

Una configuración de Style Dictionary para salida CSS se ve como:

{
  "source": ["tokens/**/*.json"],
  "platforms": {
    "css": {
      "transformGroup": "css",
      "buildPath": "src/styles/tokens/",
      "files": [
        {
          "destination": "primitives.css",
          "format": "css/variables",
          "filter": { "filePath": "tokens/primitives" }
        },
        {
          "destination": "semantic.css",
          "format": "css/variables",
          "filter": { "filePath": "tokens/semantic" }
        }
      ]
    }
  }
}

El resultado es un pipeline de CI donde los cambios de diseño en Figma fluyen automáticamente en tus tokens de CSS. Sin traducción manual, sin desfase.

Comparación de Rendimiento: CSS Vanilla vs Tailwind

Ejecuté puntos de referencia en un sitio de marketing real que reconstruimos -- mismo diseño, dos implementaciones. Aquí están los números:

Métrica Tailwind v4 Tokens CSS Vanilla Diferencia
Tamaño total de CSS (gzipped) 14.2 KB 6.8 KB -52%
First Contentful Paint 1.2s 1.0s -17%
Largest Contentful Paint 2.1s 1.8s -14%
Tiempo de análisis de CSS 3.2ms 1.4ms -56%
Tamaño de HTML (gzipped) 28.4 KB 22.1 KB -22%
Tiempo de compilación 1.8s 0.4s* -78%

*CSS Vanilla con solo bundling de @import vía Lightning CSS.

La diferencia en el tamaño de HTML es notable -- las clases de utilidad de Tailwind añaden peso significativo a tu marcado. En una página con 200+ elementos, esas cadenas de clases se suman.

Dicho esto, Tailwind v4 (lanzado a principios de 2025) hizo grandes mejoras con su motor Oxide. La brecha se ha estrechado. Pero CSS vanilla sin dependencias de compilación es difícil de superar en rendimiento bruto.

Estructura de Archivos de Tokens del Mundo Real

Aquí está la estructura real de un proyecto reciente -- un sitio de comercio sin cabeza construido con Next.js y Sanity:

src/styles/
├── tokens/
│   ├── primitives/
│   │   ├── colors.css
│   │   ├── spacing.css
│   │   ├── typography.css
│   │   ├── shadows.css
│   │   ├── borders.css
│   │   └── motion.css
│   ├── semantic/
│   │   ├── colors.css
│   │   ├── spacing.css
│   │   └── typography.css
│   ├── themes/
│   │   ├── light.css
│   │   ├── dark.css
│   │   └── high-contrast.css
│   └── index.css
├── components/
│   ├── button.css
│   ├── card.css
│   ├── input.css
│   ├── modal.css
│   ├── navigation.css
│   └── typography.css
├── layouts/
│   ├── grid.css
│   └── container.css
├── utilities/
│   └── helpers.css          /* Pocas clases de utilidad que realmente necesitamos */
├── reset.css
└── main.css

El archivo utilities/helpers.css es interesante -- aún escribo un puñado de clases de utilidad para patrones genuinamente reutilizables:

/* utilities/helpers.css */
.visually-hidden {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

.flow > * + * {
  margin-block-start: var(--flow-space, var(--space-stack-md));
}

.cluster {
  display: flex;
  flex-wrap: wrap;
  gap: var(--cluster-gap, var(--space-inline-md));
  align-items: center;
}

Nota cómo incluso las utilidades hacen referencia a tokens. Todo permanece conectado.

Herramientas que Hacen Esto Práctico

No necesitas mucho, pero algunas herramientas hacen significativamente mejor la DX:

Herramienta Propósito Notas
Lightning CSS Bundling, minificación, prefijos de proveedor Reemplaza PostCSS para la mayoría de casos. Increíblemente rápido.
Style Dictionary 4 Transformación de formato de tokens Figma → CSS, iOS, Android desde una única fuente
Cobalt UI Herramientas de tokens W3C DTCG Alternativa más nueva a Style Dictionary, alineada con especificaciones
Tokens Studio Plugin de Figma para gestionar tokens Integración con Figma mejor en su clase
CSS Utility Kit (VS Code) Autocompletado para propiedades personalizadas Muestra valores de tokens al pasar el ratón
Open Props Biblioteca de propiedades personalizadas CSS prefabricadas Gran punto de partida si no quieres construir desde cero

Lightning CSS merece una mención especial. Escrito en Rust, maneja inlining de @import, compilación de anidación para navegadores antiguos y minificación en un único paso. Es lo que usamos en la mayoría de nuestras compilaciones de CMS sin cabeza ahora.

lightningcss --bundle --minify src/styles/main.css -o dist/styles.css

Eso es. Sin configuración PostCSS. Sin cadena de plugins. Un comando.

Preguntas Frecuentes

¿Puedo usar tokens de diseño sin un paso de compilación?

Absolutamente. Si estás buscando navegadores modernos (y en 2026, deberías estarlo), las propiedades personalizadas CSS nativas funcionan sin ninguna compilación. Lo único que pierdes es el bundling de @import en un único archivo -- los navegadores manejan bien múltiples importaciones de archivos CSS, aunque querrás empaquetar para rendimiento de producción. Lightning CSS o incluso un simple comando cat pueden manejar eso.

¿Cómo se comparan los tokens de CSS vanilla con Tailwind v4?

Tailwind v4 en realidad se movió hacia propiedades personalizadas CSS internamente, lo que valida el enfoque. La diferencia está en la experiencia del desarrollador: Tailwind te da clases de utilidad para aplicar en HTML, mientras que los tokens vanilla te dan variables de diseño para usar en tu propio CSS. Los tokens vanilla producen salida CSS y HTML más pequeña, ofrecen más flexibilidad para tematización y no requieren aprender un sistema de nombres de clase. Tailwind ofrece prototipos más rápidos y cumplimiento de consistencia más fuerte para equipos más grandes.

¿Qué hay de la seguridad de tipos de TypeScript para tokens de diseño?

Si estás usando módulos CSS o CSS-in-JS, puedes generar tipos de TypeScript a partir de tus archivos de token. Style Dictionary 4 y Cobalt UI ambos soportan salida de TypeScript. Para CSS puro, las extensiones de VS Code como CSS Variable Autocomplete te dan seguridad a nivel de editor con autocompletado y validación.

¿Debería usar Open Props en lugar de construir mis propios tokens?

Open Props es un excelente punto de partida, especialmente para prototipos o proyectos más pequeños. Proporciona un conjunto bien diseñado de propiedades personalizadas CSS listo para usar. Para sistemas de diseño de producción, sin embargo, probablemente querrás definir tus propios primitivos que coincidan con tu marca. Puedes usar Open Props como referencia y cherry-pick su enfoque a cosas como funciones de facilitación o escalas de sombra.

¿Cómo manejo tokens de diseño en un monorepo con múltiples aplicaciones?

Crea un paquete tokens compartido que exporte tus archivos CSS. Cada aplicación importa el paquete de tokens y puede añadir sus propios cambios de tema. Esto funciona bellamente con espacios de trabajo en pnpm o npm. Hemos hecho esto para clientes de e-commerce multi-marca donde cada tienda frontal comparte los mismos tokens primitivos pero tiene asignaciones semánticas únicas.

¿Es CSS vanilla más lento para desarrollar que Tailwind?

Inicialmente, sí -- estás configurando infraestructura que Tailwind te da de forma gratuita. Pero después de la primera semana o dos, la velocidad es comparable o más rápida. No estás cambiando contexto entre HTML y una referencia de clase de utilidad. Estás escribiendo CSS que se lee como inglés. Y cuando necesitas cambiar algo, lo cambias en un lugar en lugar de buscar cada instancia de bg-blue-500.

¿Cómo convenzo a mi equipo de abandonar Tailwind?

No lo enmarques como abandonar Tailwind -- enmarquémoslo como adoptar tokens de diseño. Comienza introduciendo una capa de token junto con Tailwind: define tus propiedades personalizadas, hazlas referencia en un tailwind.config tema. Con el tiempo, podrías encontrar que el sistema de tokens hace la mayor parte del trabajo y Tailwind se convierte en opcional. Deja que el equipo llegue a esa conclusión orgánicamente.

¿Qué hay de bibliotecas de componentes como Shadcn/UI que dependen de Tailwind?

Shadcn/UI es fantástico, pero su dependencia de Tailwind es detalle de implementación, no arquitectura fundamental. Los patrones de componente y la lógica de accesibilidad son lo que importa. Varias bifurcaciones de la comunidad han surgido que usan tokens CSS vanilla en lugar de clases de Tailwind. También puedes migrar gradualmente componentes de Shadcn para usar tu sistema de tokens -- los primitivos subyacentes de Radix UI no se importan cómo los estilices.

¿Puedo usar este enfoque con Astro o Next.js?

Absolutamente. Ambos frameworks manejan CSS vanilla de forma nativa sin configuración. Los estilos limitados de Astro funcionan perfectamente con propiedades personalizadas CSS ya que los tokens definidos en :root naturalmente se filtran en estilos de componentes limitados. Next.js soporta módulos CSS junto con archivos de token globales. Usamos esta configuración exacta en nuestros proyectos Next.js y compilaciones de Astro regularmente. Si estás explorando esto para un nuevo proyecto, comunícate con nosotros -- nos encantaría compartir lo que hemos aprendido.