Evolución de los frameworks frontend

No cabe duda de que en los últimos cinco años el panorama del desarrollo web ha experimentado una transformación significativa y, como ecosistema vivo, continúa evolucionando constantemente. Quizás en la era actual de los LLMs, este cambio parece más pronunciado (aunque en realidad no es tan drástico como podría percibirse). Lo que sí es innegable es que hemos presenciado un salto cualitativo en nuestra forma de trabajar como ingenieros de software. Han surgido numerosas herramientas que nos han permitido reducir considerablemente las horas de trabajo, algo que sin duda agradecemos; otras, sin embargo, simplemente viven de las rentas y seguimos manteniéndolas hasta que los productos para los cuales se utilizan completen su ciclo de vida.

El ecosistema Javascript continúa demostrando un gran dinamismo entre 2020 y 2025. Lejos de estancarse, ha experimentado una expansión notable con la aparición de nuevas herramientas. Hemos presenciado el surgimiento de empaquetadores más eficientes, herramientas de testing más robustas, y frameworks tanto para frontend como backend que han revolucionado las prácticas de desarrollo dentro de este ecosistema.

El panorama actual: dominación y erosión de React

React continúa dominando el panorama de frameworks frontend con aproximadamente un 82% de adopción entre los desarrolladores web. Esta librería ha revolucionado el desarrollo de UI durante los últimos 10 años, esto no lo hace cualquiera, pero mientras que su uso sigue siendo masivo, las métricas en satisfacción y positividad han descendido, la tasa de retención ha bajado del 92% al 75% en los últimos dos años y las búsquedas de "alternativas a React" aumentaron en un 47% en el último año.

Existen algunos factores que han contribuido a esta situación: 

• Complejidad y claridad: Concurrent Mode y Server Components, dos enfoques novedosos e interesantes, pero que añaden complejidad. Especialmente los Server Components que actualmente solo podemos utilizarlos dentro de Next.js u otro framework SSR. 
• Ecosistema: React tiene probablemente el mayor ecosistema de herramientas de su categoría, algo muy positivo, pero para nuevos desarrolladores supone acceder a un entorno confuso y con una mayor curva de aprendizaje. 
• Bundle y rendimiento: otras herramientas han conseguido superar a React, dejando atrás algo que en su momento fue innovador, el DOM virtual. Y finalmente el tamaño de nuestras aplicaciones crece y crece cuando empezamos a instalar dependencias. 

Estas razones han abierto espacios para otros frameworks, que lejos de distanciarse de React, se han inspirado de esta librería, como Vue con sus composables y Svelte con sus runas (aunque internamente funcionan de manera distinta, la forma de escribir nos resulta familiar), Solid (mejorando el rendimiento) o Astro (con su enfoque "cero JS por defecto")

La guerra de convergencias - React, Vue y Svelte

Es innegable la influencia la convergencia en cómo los principales frameworks abordan la composición y reutilización del código: 

• React introdujo los Hooks (2018), revolucionando su propio ecosistema al permitir lógica stateful en componentes funcionales. 
• Vue respondió con la Composition API (2020), un enfoque notablemente similar que abandona el modelo Options API tradicional 
• Angular adoptó signals y un enfoque más funcional, alejándose de su tradicional arquitectura basada en clases 
• Svelte adoptó las Runas (2024), inspirándose en los sistemas reactivos de Solid y Angular, pero manteniendo su enfoque declarativo y su sintaxis concisa. Este cambio representó una evolución desde su sistema reactivo basado en asignaciones hacia un modelo más explícito y de composición. 

La similitud no es coincidencia: representa una evolución colectiva hacia paradigmas más funcionales y composables.

Veámoslo con un sencillo ejemplo:

React (Hooks)

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    document.title = `Contador: ${count}`;
  }, [count]);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicks: {count}
    </button>
  );
}

Vue (Composition API):

<script setup>
import { ref, watchEffect } from 'vue';

const count = ref(0);

watchEffect(() => {
  document.title = `Contador: ${count.value}`;
});
</script>

<template>
  <button @click="count++">
    Clicks: {{ count }}
  </button>
</template>

Svelte:

<script lang="ts">
  let count = $state(0);

  function increment() {
  count += 1;
  }
</script>

<button on:click={increment}>
  clicks: {count}
</button>

La convergencia de paradigmas ha creado una inesperada ventaja: 

• Los conceptos fundamentales (estado, efectos, ciclo de vida, props) son transferibles entre frameworks. 
• Los patrones de arquitectura como la composición y la separación son universales. 
• Las herramientas del ecosistema como TypeScript, testing y build tools son compartidas. 
• La curva de aprendizaje para cambiar entre frameworks se ha reducido significativamente. 

Esta transferibilidad de conocimientos representa un cambio fundamental en el desarrollo frontend: los desarrolladores podemos ahora elegir la herramienta adecuada para cada proyecto sin necesidad de casarnos con un único framework, aprovechando sus fortalezas específicas mientras mantenemos la misma experiencia relevante en todo el ecosistema.

Vite y la guerra de los bundlers

Durante años, webpack ha dominado el ecosistema de desarrollo frontend como el empaquetador por defecto. Esto parece estar cambiando en el último par de años.

En 2020 aparece Vite, creado por Evan You, cambiando el enfoque, para dividir procesos entre desarrollo y producción, carga bajo demanda y pre-empaquetación de dependencias utilizando esbuild (Go). Este cambio supone una reducción drástica de tiempos de arranque de minutos a segundos. A partir de aquí hemos ido viendo como la adopción de Vite ha ido en aumento, primero Vue, React, Svelte, Angular (con compatibilidad experimental), Solid, Qwik, Astro, Remix, etc…

Esta convergencia es inédita en el ecosistema frontend, donde en el pasado cada framework tendía a desarrollar su propio stack.

Pero es probable que veamos una nueva guerra de herramientas, porque a Vite sigue teniendo competidores como Webpack y Parcel, SWC y otros más nuevos como Turbopack, RSPack, o Rolldown (creado por Evan You también). Curiosamente estos tres últimos están programados en Rust, que empieza a ser un lenguaje muy utilizado para construir herramientas para trabajar con Javascript.

Todo esto ha supuesto enormes beneficios a la hora de mejorar la experiencia de desarrollo, teniendo características como fast refresh, estados, mejores mensajes de error, y un cambio en el flujo de trabajo, acortando los ciclos de desarrollo, menores distracciones, configuración simplificada, e incluso brindándonos espacio para la experimentación y democratizando herramientas avanzadas para que puedan ser accesibles a desarrolladores menos experimentados.

La nueva generación. Signals, hidratación y rendimiento

Vaya, no hemos mencionado a Angular hasta ahora, pero este framework que mucha gente considera estancado ha renacido, introduciendo signals (puedes leer más acerca de esto aquí), reduciendo de forma drástica el tamaño del runtime, contemplando la hidratación parcial y mejorando su compilador.

Podemos observar cómo las soluciones técnicas están convergiendo entre frameworks aparentemente dispares:

Esto no es coincidencia sino resultado de limitaciones del DOM y Javascript, priorización de métricas de rendimiento y necesidades de mejoras en aplicaciones modernas (mobile o con bajo ancho de banda).

Arquitecturas modernas como "Islands", "Resumability" de Qwik o los Server Components de React comparten un objetivo común:

• Renderizar en servidor la mayor parte del contenido posible 
• Hidratar selectivamente solo los componentes interactivos 
• Cargar código bajo demanda cuando sea necesario para la interacción 
• Preservar HTML estático sin procesamiento Javascript innecesario 

Y esto ha supuesto un resultado en mejoras de métricas en Tiempo de Interacción (TTI), reduciéndola a un 70%, First Input Delay (FID) casi eliminado, o Interaction to Next Paint (INP) mejorado.

Conclusiones. ¿Hacia dónde se dirige el desarrollo frontend?

Las tendencias apuntan a frameworks basados en compilación, poniendo hincapié en tiempos de construcción, menor código runtime (esto se trasladaría a compilación) u optimizaciones especificas por componente.

El renderizado predictivo parece también un objetivo interesante, ya que permite precargar recursos basados en patrones de navegación (mejorando enormemente la experiencia de usuario), y las transiciones (dando soporte a View Transition API) entre estados de la aplicación.

Además, estamos viendo como aparecen arquitecturas híbridas adaptativas que cambian entre cliente/servidor según el contexto (atendiendo a capacidad del dispositivo, red disponible, etc…), por ejemplo, en conexiones lentas, habría más contenido renderizado en el servidor.

También atenderemos a métricas mucho más centradas en el usuario y en su experiencia real por encima de tecnicismos, priorizando la UX continua sobre una carga inicial rápida.

Todas aquellos frameworks que liderarán la próxima generación, serán aquellos que logren equilibrar experiencia de desarrollo intuitiva, rendimiento óptimo por defecto, flexibilidad para casos de uso y adherencia a la plataforma (estándares de la web).

Fuentes relacionadas:

• Frontend Frameworks – State of JS 2024
• Developer Survey – Stack Overflow