Durante años vivimos en la ilusión de que el cliente web debía procesar absolutamente todo. Llenamos los navegadores con bundles gigantescos de JavaScript, delegando la lógica de negocio, las peticiones en cascada y la renderización al dispositivo del usuario. Sin embargo, cuando las aplicaciones crecen en complejidad —pensemos en dashboards industriales con telemetría en tiempo real o plataformas SaaS de alta densidad de datos— el cliente colapsa. El problema era evidente: latency-to-first-paint por las nubes, consumo desmedido de memoria RAM en el navegador y un renderizado que dependía directamente de la potencia de la máquina de cada visitante.
(más…)Hace años, si le decías a un programador de C++ o Java que trabajabas con CSS, probablemente te lanzaba una mirada de condescendencia mientras murmuraba: «Eso no es programar, es pintar cuadraditos». Y aunque nos doliera en el orgullo, parte de la razón no les faltaba. Durante décadas, CSS ha sido un lenguaje puramente declarativo, una lista de deseos visuales que el navegador interpretaba como buenamente podía. Si querías lógica, reutilización o variables reales, tenías que huir hacia SASS, LESS o Stylus. Teníamos que instalar Node.js, configurar Webpack o Vite, y esperar a que un transpilador escupiera el código que el navegador realmente entendía. Era como tener que montar una fábrica de pinceles cada vez que querías pintar un cuadro.
(más…)


