Qué pasó en el frontend mientras no estabas mirando

kciter1 · 2026-07-20T02:12:58+09:00

Un texto dirigido a desarrolladores que dejaron el frontend alrededor de 2008, explicando los cambios de los últimos 20 años La tesis general es que todas las herramientas son tejido cicatricial que se formó sobre problemas reales (heridas), y que las soluciones de cada capa fueron acumulándose al crear los problemas de la siguiente capa A lo largo de todo el texto se toma un solo como muestra para seguir cómo fue cambiando un botón en cada época Capa I — jQuery (2006–2010) Surgió de la necesidad de cambiar solo partes de la página sin recargarla completa jQuery eliminó las diferencias entre navegadores y masificó AJAX, pero apareció el problema de que los datos existían tanto en variables de JS como en la UI, y el desarrollador tenía que sincronizarlos manualmente Esa manipulación manual del DOM es el "pecado original" que todas las capas posteriores intentan resolver Capa II — Frameworks (2010–2015) UI declarativa: en vez de describir el procedimiento para actualizar la pantalla, se describe cómo debe verse según los datos y el framework se encarga de la actualización React lideró la época con componentes + JSX + Virtual DOM, seguido por Vue/Angular/Svelte/Solid Hoy todos los frameworks convergen hacia el concepto de signals, que rastrea dependencias para actualizar solo lo necesario También existe una corriente que vuelve a enviar HTML desde el servidor, con opciones como htmx, Alpine.js y Hotwire Capa III — Build (2012–2018) Como JS no tenía sistema de módulos, CommonJS y ES Modules compitieron, y para compatibilidad con navegadores antiguos se volvió necesario usar transpilation con Babel y bundling con webpack El build incluye minify, tree-shaking, code splitting y generación de source maps A cambio apareció node_modules, y hasta un proyecto starter vacío instala alrededor de 250 mil archivos Capa IV — Competencia de tooling (2018–2024) Fue la era de resolver los builds lentos y la complejidad de la configuración de webpack reescribiendo herramientas en Go/Rust esbuild (Go) hizo el bundling entre 10 y 100 veces más rápido, y SWC (Rust) reemplazó a Babel Vite se consolidó como herramienta por defecto, y el bundler de producción está siendo reemplazado por Rolldown, basado en Rust, mientras el stack relacionado se integra bajo VoidZero (adquirida recientemente por Cloudflare) Los package managers también siguieron la misma tendencia con pnpm, Bun y otros Capa V — El regreso del renderizado en servidor (2014–2026) En las SPA, el servidor solo enviaba un div vacío, así que en la carga inicial aparecía una pantalla vacía y para los buscadores también parecía una página vacía La solución fue volver a renderizar HTML en el servidor, un regreso al enfoque de 2008 Aparecieron SSR (render por solicitud), SSG (pre-render en build) e ISR (SSG que se actualiza automáticamente), y meta-frameworks como Next.js, Astro, SvelteKit y Nuxt se encargan de eso El costo de hydration para reactivar ese HTML del servidor en el navegador se volvió un nuevo problema, y surgieron Islands (Astro), Resumability (Qwik) y React Server Components como formas de reducir esa hydration Capa VI — Herramientas de ingeniería (2015–2026) TypeScript aseguró estabilidad en refactors con su sistema de tipos y se volvió el estándar de facto Tailwind lideró el styling con su enfoque de clases utilitarias, mientras CSS nativo también evolucionó con nesting, variables y container query, reduciendo la necesidad de tooling tradicional shadcn/ui consolidó un modelo en el que copias y posees el código fuente en vez de instalar componentes, y TanStack Query, Zustand, Zod, Vitest y Playwright forman el vocabulario básico de una app en 2026 Capa VII — Despliegue (2015–2026) En vez de subir por FTP, conectas un repositorio Git a Vercel/Netlify/Cloudflare y cada push dispara build y despliegue automáticos, además de generar una URL de preview en vivo por cada PR También se consolidaron los conceptos de funciones serverless y edge (ejecutar código en cientos de centros de datos cerca del usuario) Capa VIII — IA (2023–2026) Si describís algo en lenguaje natural a v0, Lovable o Bolt, generan un frontend funcional, y Cursor, Claude Code y Copilot escriben código por vos Incluso ingenieros de backend o de sistemas ya pueden hacer un frontend en un día, lo que difumina las fronteras entre áreas de ingeniería Aun así, el código generado da por sentado el conocimiento de estas 8 capas, y cerrar esa brecha es el objetivo de este texto Bedrock — Conclusión La dirección de la vanguardia en 2026 es renderizar HTML en el servidor, enviar casi nada de JS y aprovechar la plataforma web La conclusión es que, tras 20 años, la industria trazó un gran círculo y volvió a un punto que se parece a los archivos que antes se subían por FTP

Un texto dirigido a desarrolladores que dejaron el frontend alrededor de 2008, explicando los cambios de los últimos 20 años
La tesis general es que todas las herramientas son tejido cicatricial que se formó sobre problemas reales (heridas), y que las soluciones de cada capa fueron acumulándose al crear los problemas de la siguiente capa
A lo largo de todo el texto se toma un solo <button> como muestra para seguir cómo fue cambiando un botón en cada época

Capa I — jQuery (2006–2010)
- Surgió de la necesidad de cambiar solo partes de la página sin recargarla completa
- jQuery eliminó las diferencias entre navegadores y masificó AJAX, pero apareció el problema de que los datos existían tanto en variables de JS como en la UI, y el desarrollador tenía que sincronizarlos manualmente
- Esa manipulación manual del DOM es el "pecado original" que todas las capas posteriores intentan resolver
Capa II — Frameworks (2010–2015)
- UI declarativa: en vez de describir el procedimiento para actualizar la pantalla, se describe cómo debe verse según los datos y el framework se encarga de la actualización
- React lideró la época con componentes + JSX + Virtual DOM, seguido por Vue/Angular/Svelte/Solid
- Hoy todos los frameworks convergen hacia el concepto de signals, que rastrea dependencias para actualizar solo lo necesario
- También existe una corriente que vuelve a enviar HTML desde el servidor, con opciones como htmx, Alpine.js y Hotwire
Capa III — Build (2012–2018)
- Como JS no tenía sistema de módulos, CommonJS y ES Modules compitieron, y para compatibilidad con navegadores antiguos se volvió necesario usar transpilation con Babel y bundling con webpack
- El build incluye minify, tree-shaking, code splitting y generación de source maps
- A cambio apareció node_modules, y hasta un proyecto starter vacío instala alrededor de 250 mil archivos
Capa IV — Competencia de tooling (2018–2024)
- Fue la era de resolver los builds lentos y la complejidad de la configuración de webpack reescribiendo herramientas en Go/Rust
- esbuild (Go) hizo el bundling entre 10 y 100 veces más rápido, y SWC (Rust) reemplazó a Babel
- Vite se consolidó como herramienta por defecto, y el bundler de producción está siendo reemplazado por Rolldown, basado en Rust, mientras el stack relacionado se integra bajo VoidZero (adquirida recientemente por Cloudflare)
- Los package managers también siguieron la misma tendencia con pnpm, Bun y otros
Capa V — El regreso del renderizado en servidor (2014–2026)
- En las SPA, el servidor solo enviaba un div vacío, así que en la carga inicial aparecía una pantalla vacía y para los buscadores también parecía una página vacía
- La solución fue volver a renderizar HTML en el servidor, un regreso al enfoque de 2008
- Aparecieron SSR (render por solicitud), SSG (pre-render en build) e ISR (SSG que se actualiza automáticamente), y meta-frameworks como Next.js, Astro, SvelteKit y Nuxt se encargan de eso
- El costo de hydration para reactivar ese HTML del servidor en el navegador se volvió un nuevo problema, y surgieron Islands (Astro), Resumability (Qwik) y React Server Components como formas de reducir esa hydration
Capa VI — Herramientas de ingeniería (2015–2026)
- TypeScript aseguró estabilidad en refactors con su sistema de tipos y se volvió el estándar de facto
- Tailwind lideró el styling con su enfoque de clases utilitarias, mientras CSS nativo también evolucionó con nesting, variables y container query, reduciendo la necesidad de tooling tradicional
- shadcn/ui consolidó un modelo en el que copias y posees el código fuente en vez de instalar componentes, y TanStack Query, Zustand, Zod, Vitest y Playwright forman el vocabulario básico de una app en 2026
Capa VII — Despliegue (2015–2026)
- En vez de subir por FTP, conectas un repositorio Git a Vercel/Netlify/Cloudflare y cada push dispara build y despliegue automáticos, además de generar una URL de preview en vivo por cada PR
- También se consolidaron los conceptos de funciones serverless y edge (ejecutar código en cientos de centros de datos cerca del usuario)
Capa VIII — IA (2023–2026)
- Si describís algo en lenguaje natural a v0, Lovable o Bolt, generan un frontend funcional, y Cursor, Claude Code y Copilot escriben código por vos
- Incluso ingenieros de backend o de sistemas ya pueden hacer un frontend en un día, lo que difumina las fronteras entre áreas de ingeniería
- Aun así, el código generado da por sentado el conocimiento de estas 8 capas, y cerrar esa brecha es el objetivo de este texto
Bedrock — Conclusión
- La dirección de la vanguardia en 2026 es renderizar HTML en el servidor, enviar casi nada de JS y aprovechar la plataforma web
- La conclusión es que, tras 20 años, la industria trazó un gran círculo y volvió a un punto que se parece a los archivos que antes se subían por FTP

Qué pasó en el frontend mientras no estabas mirando

Lecturas relacionadas

4 comentarios