Why BPL DS

Qué es BPL DS

BPL DS tiene dos capas con responsabilidades distintas.

El core es la plataforma. Define el lenguaje visual completo — colores, espacio, tipografía, radio, sombras, motion — como variables CSS nativas. No sabe nada de componentes. Es estable, rara vez cambia, y es la única dependencia obligatoria.

Los componentes son patrones de UI concretos construidos sobre el core: botón, modal, tabs, accordion. No son la librería — son el vocabulario. El consumidor los adopta tal cual, los adapta vía su Public API (las custom properties --<name>-*), o los usa como referencia para construir los suyos.

Core  ·  tokens · reset · grid · utilities   →  lenguaje visual
Componentes  ·  button · modal · tabs · ...  →  patrones de UI
Producto  ·  tu interfaz                     →  lo que construís

El core es lo único obligatorio. Los componentes son opt-in — importás solo los que usás.

Una sola definición, cualquier contexto

BPL DS define cada componente una sola vez como HTML + CSS. Ese mismo HTML funciona en React, Vue, Svelte, Astro, PHP, Rails, o email HTML sin adaptadores ni wrappers.

<!-- exactamente esto, en cualquier entorno -->
<button class="bp-btn bp-btn--primary">Acción</button>

Los frameworks de mercado tienen esta cadena:

Diseño → Token → Componente React → Wrapper Vue → Wrapper Web Component → ???

Cada capa agrega fricción, rompe en actualizaciones mayores, y excluye un entorno. BPL DS no tiene capas — el HTML es la API.

Ventajas

Sin setup, sin dependencias de runtime

Un <link> a index.css y los componentes funcionan. Sin npm install, sin bundler, sin configuración de build. En producción: cero KB de JS de framework.

La customización no requiere tocar el CSS fuente

Cada componente expone una Public API de CSS custom properties. Para cambiar la apariencia, el consumidor define sus valores en su propio CSS:

.mi-boton-cta {
  --btn-bg: var(--bp-color-success);
  --btn-radius: var(--bp-radius-full);
}

No hay que hacer fork del DS, no hay que recompilar nada, no hay riesgo de perder cambios en una actualización.

Dark mode incluido

data-theme="dark" en el root — todos los tokens cambian automáticamente. No hay que agregar nada más a los componentes.

Los tokens son la fuente de verdad visual

Las variables CSS en el core son las mismas que el código de producción usa. No hay traducción de decisiones de diseño a código — el token es el código. Si el valor de un token cambia, todos los componentes lo reflejan sin tocar nada.

Integración natural con Figma Variables

Figma Variables usa el mismo concepto que las CSS custom properties: un nombre, un valor, un modo (light/dark). La integración no requiere plugin ni sincronización automática — es un contrato de nomenclatura.

Si en Figma nombrás tus variables con los mismos nombres que los tokens del DS (bp-primary, bp-color-bg, bp-space-4), el diseño y el código comparten la misma fuente de verdad por convención. Cuando un diseñador describe un componente usando esos nombres, el dev sabe exactamente qué variable CSS usar — sin traducción, sin ambigüedad.

Lo que toca hacer: en Figma, crear las Variables con los nombres del DS y asignarles los valores correspondientes como defaults. A partir de ahí, cada decisión de diseño que usa esas variables mapea 1:1 al código.

Custom Elements para comportamiento puntual

Cuando un componente necesita JS — navegación por teclado, gestión de foco, sincronización de ARIA — BPL DS lo implementa como Custom Element nativo del browser, no como componente de framework.

<bp-dropdown>, <bp-table> son Web Components: funcionan en React, Vue, Svelte, Astro, o HTML puro sin adaptadores. El CSS sigue manejando todo lo visual via atributos DOM ([data-open], [aria-selected]); el Custom Element solo agrega el comportamiento que CSS no puede representar.

<!-- funciona en cualquier entorno, sin imports de framework -->
<bp-dropdown class="bp-dropdown">
  <button class="bp-btn bp-dropdown__trigger">Acciones ▾</button>
  <ul class="bp-dropdown__panel" role="menu">…</ul>
</bp-dropdown>

Custom Elements es Baseline widely available desde 2020. No es una abstracción — es la plataforma.

Longevidad por estándares

CSS custom properties, @container, <dialog>, scroll-snap son estándares web. El DS no depende de que ninguna librería de terceros siga siendo mantenida. Lo que funciona hoy funciona en 5 años.

Curva de aprendizaje baja

El único requisito es saber HTML y CSS. No hay API propia que memorizar, no hay sistema de theming con su propia lógica, no hay CLI de generación.

Perfil	Tiempo estimado al primer componente
Dev frontend (HTML/CSS)	< 30 min
Dev fullstack con CSS básico	~1 hora
Dev backend sin experiencia en CSS moderno	~medio día (leer tokens + un componente de referencia)
Dev React acostumbrado a component libraries	~1 hora (desorientar el instinto de buscar props)

El onboarding es: leer la página del componente, copiar el HTML, agregar la clase CSS.

Peso en producción

Control total sobre cuánto CSS llega al navegador.

Core

Archivo	Raw	Gzip
Tokens	7.9 KB	1.8 KB
Reset	1.2 KB	0.6 KB
Grid	2.6 KB	0.9 KB
Utilities	0.2 KB	0.2 KB
Total core	12.2 KB	3.5 KB

Componentes (opt-in)

Componente	Raw	Gzip
carousel	7.6 KB	2.2 KB
nav	8.1 KB	1.7 KB
theme	4.6 KB	1.6 KB
toast	4.2 KB	1.2 KB
accordion	3.4 KB	1.2 KB
modal	3.4 KB	1.1 KB
badge	4.3 KB	1.1 KB
button	3.0 KB	1.0 KB
hero	2.8 KB	1.0 KB
card	2.8 KB	0.9 KB
input	2.4 KB	0.9 KB
tabs	2.4 KB	0.8 KB
footer	2.6 KB	0.8 KB
header	2.0 KB	0.8 KB
Promedio por componente	~3.7 KB	~1.1 KB
12 componentes completos	54.8 KB	15.7 KB

Comparativa de peso vs. alternativas

	CSS (gzip)	JS (gzip)	Total (gzip)	Requiere build
BPL DS core	3.5 KB	0 KB	3.5 KB	No
BPL DS completo (12 componentes)	19.2 KB	0 KB	19.2 KB	No
Bootstrap 5	~22 KB	~16 KB	~38 KB	Sí (Sass)
Tailwind base (purgeado)	~5–15 KB	0 KB	~5–15 KB	Sí (PostCSS)
MUI (React, solo CSS-in-JS)	—	~50 KB	50+ KB	Sí (webpack/vite)
shadcn/ui (React, mínimo)	~5 KB	~10 KB	~15 KB	Sí (Tailwind + Next)

Un producto con core + 5 componentes típicos (button, card, input, nav, modal) envía ~8.5 KB gzip de CSS — sin JS de framework, sin build pipeline, sin dependencias de runtime.

Comparativa honesta

Cada herramienta tiene un contexto donde es la mejor opción. Esta comparativa incluye los casos donde BPL DS no es la respuesta correcta.

vs. Tailwind CSS

Tailwind es un sistema de utilidades; BPL DS es un sistema de componentes. Son herramientas con objetivos distintos.

	BPL DS	Tailwind
Unidad de diseño	Componente con semántica	Clase de utilidad
Consistencia visual	Enforced por el componente	Requiere disciplina del equipo
Customización por instancia	`.mi-btn { --btn-bg: red }`	Clase directa en el elemento
Modo oscuro	`data-theme` en el root	`dark:` en cada elemento
Legibilidad del HTML	Alta	Baja con muchas clases
Velocidad de prototipado	Media	Alta
Diseños muy personalizados	Requiere CSS propio	Nativo — es el punto fuerte
Ecosistema y comunidad	Pequeño	Masivo
IDE tooling (autocomplete)	Básico	Excelente (Tailwind IntelliSense)

Cuándo Tailwind gana: proyectos con diseño muy variado entre páginas, equipos grandes donde la velocidad de prototipado importa más que la consistencia, o proyectos donde cada componente es suficientemente único como para que una abstracción sea friction.

Cuándo BPL DS gana: productos con identidad visual consistente, proyectos multi-stack donde el mismo HTML se usa en varios entornos, o cuando la velocidad de implementación agéntica importa.

Se pueden usar juntos. Las clases BPL conviven con utilidades de Tailwind en el mismo elemento.

vs. shadcn/ui

El approach más cercano en filosofía: código que el consumidor posee, sin dependencia de librería externa. Las diferencias son de paradigma.

	BPL DS	shadcn/ui
Paradigma	HTML + CSS	React + Radix UI
Accesibilidad out-of-the-box	Buena (manual, ARIA explícito)	Excelente (Radix maneja todo)
Comportamiento complejo (combobox, date picker)	Requiere implementación custom	Incluido y probado
Funciona sin React	Sí	No
Customización	CSS custom properties	Tailwind + tokens
Componentes disponibles	12 (y creciendo)	50+
Tiempo para un form complejo funcional	Más	Menos

Cuándo shadcn/ui gana: proyectos React donde la accesibilidad de componentes complejos (combobox, date picker, command palette) es crítica y no hay tiempo para implementarla desde cero.

Cuándo BPL DS gana: proyectos no-React, cuando se necesita el mismo DS en múltiples stacks, o cuando los componentes son suficientemente simples para no necesitar la abstracción de Radix.

vs. MUI / Chakra / Ant Design

Component libraries completas para React con sistemas de theming propios.

	BPL DS	MUI / Chakra
Requiere React	No	Sí
Componentes disponibles	12	50–100+
Bundle JS	0 KB	50–200 KB
Curva de aprendizaje	Baja (HTML/CSS)	Alta (API propia)
Theming	CSS custom properties	Sistema propio (sx prop, theme)
Funciona en email HTML	Sí	No
Enterprise-ready out-of-the-box	No	Sí (data grids, charts, etc.)

Cuándo MUI/Chakra ganan: aplicaciones enterprise en React que necesitan data grids, date pickers complejos, rich text editors, o dashboards con docenas de componentes especializados.

Cuándo BPL DS gana: cuando el lock-in de React es un problema, cuando se necesita control total sobre el bundle, o cuando la interfaz no necesita los 100 componentes del catálogo.

vs. Bootstrap 5

El precursor conceptual más cercano — clases CSS sobre HTML semántico, sin lock-in de framework.

	BPL DS	Bootstrap 5
Tokens	CSS custom properties nativas	Variables CSS + Sass
Responsive	`@container` (por componente)	`@media` (por viewport)
Theming	Runtime con custom props	Requiere recompilar Sass
Bundle CSS	Solo lo que se importa	~22 KB todo incluido
Semántica de estado	Atributos ARIA	Clases JS (`.active`, `.show`)
Documentación y ejemplos	Este sitio	Extensa, con años de ejemplos
Comunidad	Pequeña	Enorme
Madurez	v1.0	v5 estable

Cuándo Bootstrap gana: cuando se necesita una referencia documentada y testada en producción con comunidad activa. Bootstrap 5 es una elección válida y pragmática para la mayoría de proyectos web.

Cuándo BPL DS gana: cuando se quiere customización sin Sass, responsive basado en el componente en lugar del viewport, o cuando la identidad visual es suficientemente específica para que los defaults de Bootstrap sean friction.

Desventajas

Ser honesto sobre las limitaciones es parte de tomar buenas decisiones de arquitectura.

Catálogo pequeño. 12 componentes cubre los patrones más comunes, pero deja fuera componentes complejos que en otros ecosistemas son estándar: date picker, combobox con búsqueda, data table con sorting/filtering, rich text editor, command palette.

Sin gestión de estado de UI compleja. Un combobox con búsqueda async, drag-and-drop, o un calendario multiselect requieren JS no-trivial. BPL DS no opina sobre cómo manejarlo. shadcn/ui o Radix UI resuelven esto mejor.

Accesibilidad manual. La accesibilidad de cada componente es tan buena como la implementación. No hay una librería que maneje automáticamente edge cases de ARIA. Radix UI tiene años de trabajo en esos edge cases que BPL DS no replica.

Sin ecosistema. No hay plugins, no hay integración oficial con herramientas de diseño, no hay third-party components construidos sobre BPL DS. El consumidor está solo cuando sale del catálogo.

Requiere conocimiento de CSS moderno. @layer, @container, @starting-style, clamp(), CSS custom properties son APIs modernas. Un equipo que no las conoce va a tener friction al extender o debuggear el DS.

No es la respuesta correcta para todos los proyectos. SPA React con componentes complejos de datos → shadcn/ui + Radix. Velocidad de prototipado máxima → Tailwind. Catálogo grande con comunidad → Bootstrap.

Desarrollo agéntico

BPL DS fue diseñado desde su origen para desarrollo agéntico. La arquitectura de contrato único, la API verificable mecánicamente y la separación dura CSS/JS no son adaptaciones posteriores — son decisiones tomadas para que los agentes de IA produzcan código correcto de forma consistente.

Las mismas características que eliminan las desventajas de ecosistema para el humano eliminan la ambigüedad para el agente:

Sin props, sin hooks, sin build — el agente genera HTML + clases CSS leyendo la documentación de este sitio. No hay framework que aprender, no hay abstracción que inferir.
API verificable mecánicamente — la estructura del CSS tiene invariantes concretos (@layer, BEM, --_* privado, --<name>-* público). Un agente revisor puede verificar cumplimiento sin juicio subjetivo.
Estado en el DOM — el CSS lee atributos ARIA y propiedades nativas. El patrón fuerza la separación CSS/JS; el agente no puede colapsarla.
Verificación visual, sin test runner — pnpm dev + browser. Sin mocks de DOM, sin setup de Jest.

El resultado: un agente con las reglas correctas puede implementar interfaces completas con BPL DS de forma consistente — y otro agente puede revisar ese trabajo contra un checklist mecánico.

Para configurar tu agente con las reglas concretas, ver Agentic Development.