Vanilla JS Es el Lenguaje Ensamblador del Navegador (Y Por Eso Lo Usamos)

En febrero de 2023, Alex Russell — que pasó más de una década en el equipo de Google Chrome — publicó "The Market for Lemons", una crítica demoledora a la industria de frameworks JavaScript. Su tesis: durante una década, los "mercaderes de complejidad" vendieron frameworks pesados como el futuro de la web, mientras los productos resultantes eran más lentos, más frágiles y peores para los usuarios. Su conclusión: "Necesitamos devolver la atención a la gente que nunca abandonó el marcado semántico, CSS y la mejora progresiva." Somos esa gente. Y tenemos números que lo demuestran.

El Bloat Es Real (y Medible)

A principios de 2024, Nikita Tonsky publicó "JavaScript Bloat in 2024", una auditoría metódica de cuánto JavaScript envían los sitios populares. Los resultados son impactantes:

Sitio	Qué Hace	JavaScript Enviado
Blog de Tonsky	Contenido estático	0.004 MB
Wikipedia	Contenido estático + búsqueda	0.2 MB
Gmail	Cliente de email	20 MB
Slack	Chat	55 MB
Jira	Gestión de tareas	50 MB
LinkedIn	Social + mensajería	31 MB
Notion	Edición de documentos	16 MB
Landing de Vercel	Página estática	6 MB

Slack envía 55 MB de JavaScript — el tamaño del Quake 1 original — para una app de chat. Mientras tanto, el blog de Tonsky entrega el mismo valor fundamental (mostrar texto a humanos) con 0.004 MB. Eso es una diferencia de 13.750x en código para un output fundamentalmente similar: texto en una pantalla.

Como dijo Tonsky: "Llámame anticuado, pero creo firmemente que el contenido debería pesar más que el código. Si estás escribiendo un post de 10K caracteres, no necesitas 1000× más JavaScript para renderizarlo."

La Analogía del Ensamblador

Vanilla JavaScript y CSS puro son al navegador lo que el lenguaje ensamblador es a la CPU. Son el set de instrucciones nativo. Todo lo demás — React, Vue, Svelte, Tailwind, Sass — compila a ellos eventualmente. Cada useState se convierte en un closure. Cada className="flex items-center" se convierte en una regla CSS. Cada expresión JSX se convierte en una llamada a document.createElement.

Cuando entiendes las primitivas de bajo nivel, ganas tres superpoderes:

• Sabes qué está pasando realmente. Cuando algo se rompe, no debugueas el framework — debugueas el navegador. DevTools habla vanilla JS y CSS, no React ni Vue
• Puedes evaluar frameworks honestamente. Sabes qué están abstrayendo, cuánto cuestan y si ese coste está justificado para tu caso de uso
• Puedes construir sin ellos. Cuando un framework añade overhead que no sirve al usuario, tienes la opción de simplemente... no usarlo

Esto no significa que los frameworks sean malos. Significa que saber cuándo no usar uno es la habilidad que separa a los ingenieros de los operadores de frameworks.

The Market for Lemons: Una Década Perdida

La crítica de Alex Russell merece leerse completa, pero el argumento clave es económico. Cuando los vendedores tienen más información que los compradores, los productos de baja calidad dominan el mercado — la teoría de los "limones" de Akerlof. Aplicado al frontend:

"Los partidarios de frameworks lentos y complejos han vendido con éxito limones como lo último, a pesar de los fracasos generalizados que dejan a su paso, desplazando opciones de mayor calidad en el proceso."

— Alex Russell, The Market for Lemons (2023)

Los frameworks nacieron en Facebook y Google — empresas con equipos dedicados de rendimiento, gates de lanzamiento, presupuestos de latencia y cientos de ingenieros para gestionar la complejidad. Cuando se trasplantaron a un equipo típico de 3-10 developers, estas herramientas se convirtieron en fracasos caros: lentas de cargar, frágiles de mantener y requiriendo un ecosistema entero de abstracciones (SSR, code splitting, hydration, streaming) para mitigar problemas que ellas mismas habían creado.

Jeremy Keith, una de las voces más respetadas en estándares web, lo dijo sin rodeos en noviembre de 2023: "A estas alturas React es tecnología legacy, como Angular. Mucha gente sigue usándolo, pero nadie recuerda bien por qué."

The Great Gaslighting

Jared White de The Spicy Web capturó lo que muchos de nosotros sentimos durante años:

"Nos dijeron que construir apps con una mentalidad HTML-first, SSR-first, con mejora progresiva estaba anticuado y era malo para los usuarios. Eso era mentira. Nos dijeron que construir apps completamente con JavaScript frontend nos haría la vida más fácil. Eso también era mentira."

Su punto central es demoledor: "JavaScript no es necesario para construir un sitio web simple. HTML, CSS y JavaScript. No JavaScript, JavaScript y JavaScript."

La web es políglota por diseño. A HTTP no le importa qué lenguaje genera el HTML. Al navegador no le importa qué herramienta escribió el CSS. Al usuario no le importa tu DX — le importa la velocidad, la fiabilidad y si el maldito botón funciona.

Los Web Components Sobrevivirán a Tu Framework

Jake Lazaroff escribió uno de los posts más importantes de 2023 sobre este tema. Su argumento: si quieres que tu trabajo perdure, construye sobre estándares web, no sobre APIs de frameworks.

"Llevo construyendo en la web casi 20 años. Es tiempo suficiente para presenciar el nacimiento, auge y caída de jQuery. Backbone irrumpió en escena y fue rápidamente reemplazado por AngularJS, que fue reemplazado por React, que lleva solo la mitad de ese tiempo y ya ha pasado por unas cinco formas diferentes de escribir componentes."

La web original de Space Jam de 1996 sigue renderizando perfectamente en navegadores modernos. La primera web jamás creada — más cercana a la formación de los Beatles que al día de hoy — sigue funcionando. Mientras tanto, proyectos React de 2018 a menudo no compilan sin cirugía mayor de dependencias.

Los estándares perduran. Los frameworks no. Elige en consecuencia.

El Caso htmx: 67% Menos Código, 50% Más Rápido

La teoría está bien, pero ¿qué hay de resultados reales? En DjangoCon 2022, Contexte presentó su migración de React a htmx. Los números hablan solos:

Métrica	React	Después (htmx)	Cambio
Tamaño del código	21.500 LOC	7.200 LOC	-67%
Dependencias JS	255	9	-96%
Tiempo de build	40 segundos	5 segundos	-88%
Time to interactive	2-6 segundos	1-2 segundos	-50-60%
Uso de memoria	75 MB	45 MB	-46%

Pero el cambio más revelador fue organizacional: todo el equipo se convirtió en desarrolladores full-stack. Con React, había una división dura entre frontend y backend. Sin él, cada desarrollador podía ser dueño de una feature de principio a fin. Menos coordinación, entregas más rápidas, ingenieros más contentos.

Nuestro Enfoque: Conocer el Bajo Nivel, Elegir el Nivel Correcto

No somos haters de frameworks. No construimos todo en vanilla JS por dogma. Somos ingenieros que entienden las primitivas de bajo nivel y eligen la abstracción correcta para cada trabajo. Así se traduce en nuestro stack:

Vanilla JS + CSS Puro (cero dependencias)

• cookie-consent.js — Nuestro sistema completo de cookie consent: IIFE, inyección CSS autocontenida, localStorage, UI bilingüe, gating de analytics. 4KB total, cero dependencias. Un equivalente React con librería UI pesaría 50-200KB mínimo
• Perspectiva Studio — ~15 módulos (audio, video, chat, embeddings, publicaciones, gestión de modelos) en vanilla JS puro. Sin build step. Abre index.html en un navegador y funciona. Lleva años funcionando sin una sola actualización de dependencias
• Landings de clientes (Vall, NutriNen, etc.) — HTML estático, CSS puro, Alpine.js para toques de interactividad. Cargan en menos de 1 segundo en 3G

Astro (SSG — generación de sitios estáticos)

• cadenceslab.com — Esta misma web. Astro genera HTML estático en tiempo de build. El blog que estás leyendo es un archivo HTML pre-renderizado. Cero JavaScript enviado al cliente para páginas de contenido. Astro se gana su lugar porque hace una cosa magistralmente: convertir componentes en HTML estático y quitarse de en medio
• GoViajes, GoStorm — Plataformas de viajes y eventos donde el contenido es mayormente estático pero el modelo de datos se beneficia de las colecciones e i18n routing de Astro

React (islands interactivos)

• Plataforma Cadences — El producto principal es una app interactiva compleja: gestión de proyectos en tiempo real, chat con IA, integración de voz, constructores de workflows, exploradores de datos. React se gana su lugar aquí porque la UI es genuinamente stateful, interactiva y compleja
• Componentes interactivos del blog — Cuando un post necesita una demo en vivo o widget interactivo, usamos React como island de Astro: se hidrata solo cuando es visible, envía JS solo para ese componente, y la página circundante sigue siendo HTML estático

El árbol de decisión es simple:

¿Es contenido estático? → HTML + CSS. Listo.
¿Necesita un toque de interactividad? → Vanilla JS o Alpine.js
¿Necesita SSG con routing/i18n? → Astro
¿UI interactiva genuinamente compleja? → React (como island o SPA)
¿Podría ser más simple? → Vuelve al paso 1

Lo Que Realmente Enviamos (Con Números)

Producto	Tech	JS Enviado al Cliente	Por Qué Esta Elección
cadenceslab.com	Astro + islands	~15KB (Alpine + consent)	Web de contenido, necesita cero JS para contenido
Cookie consent	Vanilla JS	4KB	Autocontenido, sin dependencias que mantener
Perspectiva Studio	Vanilla JS	~80KB (15 módulos)	Sin build step, funciona para siempre
Landings de clientes	HTML + CSS + Alpine	~12KB	Máximo rendimiento, mínima complejidad
App Cadences	React	~350KB	UI interactiva compleja que justifica el coste

Compara nuestra web de contenido (15KB) con la landing de Vercel (6MB). Eso es una diferencia de 400x. Nuestro sistema completo de cookie consent es más pequeño que la página del tutorial promedio de React useState.

CSS Puro: El Superpoder Olvidado

El mismo principio aplica al CSS. Mientras la industria se ocupaba inventando CSS-in-JS, CSS Modules, Styled Components, Emotion y diecisiete sabores de clases utility, el navegador estaba silenciosamente lanzando features que hacen la mayoría de esas herramientas innecesarias:

• CSS Custom Properties — Variables nativas con herencia en cascada. Sin build step necesario
• CSS Grid + Flexbox — Layout resuelto nativamente. Sin grid de Bootstrap, sin utilities de flexbox
• Selector :has() — El "parent selector" que esperamos 20 años. Ahora puedes estilizar según los hijos sin una línea de JS
• @container queries — Diseño responsive a nivel de componente, nativamente
• @layer — Gestión nativa de cascada. Se acabaron las guerras de !important
• Nesting — Anidamiento CSS nativo, sin necesidad de Sass
• color-mix(), oklch() — Manipulación avanzada de color sin preprocesadores

Nuestras páginas de clientes usan CSS puro con custom properties para tematización. Cada marca (Vall Inmobiliaria, NutriNen, GoViajes) tiene su propio archivo CSS con una paleta de custom properties — sin config de Tailwind, sin build step, sin PostCSS. Cambia --brand-primary y toda la web cambia de marca. Es CSS haciendo lo que CSS fue diseñado para hacer.

El Argumento de la Longevidad

El punto de Jake Lazaroff sobre longevidad merece repetirse. Nuestros módulos de Perspectiva Studio — escritos en vanilla JS hace años — siguen funcionando perfectamente hoy. Sin alertas de npm audit. Sin breaking changes de actualizaciones de dependencias. Sin "este proyecto usa React 16 y necesita migrarse a 18." Abres el archivo HTML, funciona.

TypeScript es maravilloso, pero incluso él tiene breaking changes en cada release. Como notó Lazaroff: "las últimas 15 versiones de TypeScript han tenido breaking changes." Para código de larga vida que no planeas mantener activamente, vanilla JS es la apuesta más segura. Es la única tecnología garantizada de no romperse, porque los fabricantes de navegadores se han comprometido a nunca romper la web.

La primera web, construida en 1991, sigue funcionando. ¿Puedes decir lo mismo de tu app React de 2019?

Conclusiones Clave

1. Vanilla JS y CSS puro son el set de instrucciones nativo del navegador. Todo lo demás compila a ellos. Entenderlos en profundidad no es "old school" — es la base que te permite evaluar y elegir (o rechazar) cualquier otra herramienta. Los ingenieros que conocen el bajo nivel siempre tienen la ventaja.

2. El impuesto del framework es real y medible. 55MB de JS para una app de chat. 20MB para un cliente de email. 6MB para una landing page. Los "mercaderes de complejidad" vendieron mejoras de DX que degradaron la UX. Como documentó Alex Russell, la industria perdió una década con the market for lemons.

3. No somos anti-framework — somos anti-framework-por-defecto. React impulsa nuestra plataforma Cadences porque las UIs interactivas complejas genuinamente se benefician de ello. Astro genera este blog porque la generación de sitios estáticos es genuinamente útil. Pero el cookie consent no necesita React. Una landing page no necesita Next.js. La herramienta correcta para el trabajo a veces es ninguna herramienta.

4. Los estándares web sobreviven a todo. jQuery vino y se fue. AngularJS vino y se fue. React ha tenido cinco patrones diferentes de componentes en 10 años. HTML, CSS y vanilla JS de 1996 siguen funcionando perfectamente. Construye sobre el sustrato, no sobre la capa de abstracción que estará deprecated el año que viene.

5. La mejor DX es infraestructura invisible. Nuestro cookie-consent.js tiene cero dependencias, cero build steps, y no ha necesitado una actualización desde que se escribió. Los 15 módulos de Perspectiva Studio funcionan abriendo un archivo HTML. Eso no es deuda técnica — es libertad técnica. Cuanto menos depende tu código, menos se puede romper.