Qwik: la apuesta por la resumibilidad en lugar de hidratación

Actualizado: 2026-05-03

Hidratar una aplicación React o Vue consiste en volver a ejecutar en el navegador el mismo código que ya corrió en el servidor, solo para recuperar los manejadores de eventos y el árbol de estado que se perdieron al serializar el HTML. Es un peaje silencioso que pagamos en cada carga: el bundle se descarga, se parsea y se ejecuta antes de que el botón responda. Qwik, el framework que Misko Hevery (creador de Angular) impulsa desde Builder.io, ataca el problema por la raíz con una idea distinta — la resumibilidad: en lugar de rehidratar, el cliente reanuda la ejecución donde el servidor la dejó, y solo descarga el código cuando hace falta.

Puntos clave

• El bundle inicial de aplicación es literalmente cero kilobytes: el HTML llega completo y el runtime de Qwik (~4 KB) escucha globalmente.
• El $ marker no es azúcar sintáctico — es la frontera de lazy loading que el compilador Vite respeta para generar chunks independientes por cada evento.
• En Lighthouse, landing pages con Qwik logran TTI por debajo de 0,5 s y LCP alrededor de 0,6 s de forma consistente.
• La ventaja crece con el tamaño: en una tienda de 50 componentes, Next.js hidrata el árbol visible completo; Qwik solo descarga el handler del botón pulsado.
• No es para todos: teams con inversión en React, apps colaborativas realtime o sitios casi estáticos tienen mejores alternativas.

Resumibilidad frente a hidratación

En el modelo clásico el servidor renderiza HTML, el navegador lo pinta y luego descarga el bundle de JavaScript — entre 100 y 300 KB en aplicaciones medianas — para reconstruir el estado y enganchar los listeners. Hasta que ese proceso termina, la página parece viva pero no responde: es lo que Lighthouse mide como brecha entre First Contentful Paint y Time to Interactive.

Qwik hace otra cosa. El servidor serializa en el propio HTML todo lo necesario — estado, referencias a los manejadores, cierre de closures — dentro de atributos y un bloque JSON al final del documento. El cliente descarga HTML y nada más. Un runtime de unos pocos kilobytes escucha los eventos globalmente mediante delegación; cuando el usuario pulsa un botón, Qwik sabe qué chunk hay que pedir y lo descarga en ese instante. La página está interactiva desde el primer byte, aunque el código detrás de cada acción llegue bajo demanda.

La pieza que hace esto posible es el marcador $. Cuando escribimos onClick$ o envolvemos un componente en component$, el compilador Qwik (basado en Vite) corta ahí el grafo de dependencias y genera un chunk independiente. Ese símbolo no es azúcar sintáctico: es la frontera de lazy loading que el optimizador respeta. Por eso los componentes se ven muy parecidos a React, pero el bundle resultante no se parece en nada.

import { component$, useSignal } from '@builder.io/qwik';
import { routeLoader$ } from '@builder.io/qwik-city';

export const useUser = routeLoader$(async ({ params }) => {
  return await db.user.findById(params.id);
});

export default component$(() => {
  const user = useUser();
  const count = useSignal(0);

  return (
    <section>
      <h1>{user.value.name}</h1>
      <button onClick$={() => count.value++}>
        Visitas: {count.value}
      </button>
    </section>
  );
});

Qué dicen los números

En landing pages y blogs con algo de interactividad, los benchmarks publicados durante 2024 son consistentes:

• Lighthouse: puntuación de 100.
• TTI: por debajo de 0,5 s.
• LCP: alrededor de 0,6 s.
• Bundle inicial: cero kilobytes de JavaScript de aplicación.

Un Next.js equivalente suele moverse entre 80 y 150 KB de JS inicial y un TTI de 1 a 2 s en conexiones 4G. La diferencia no es marginal y se acentúa en móvil con red lenta — exactamente donde Google penaliza más en Core Web Vitals.

El matiz importante: esos números son sostenibles cuando la aplicación crece, porque el coste de interactividad es proporcional a lo que el usuario toca, no al tamaño total del código. Comparar con SvelteKit 1.0 y su adopción real da perspectiva: SvelteKit también tiene bundles pequeños, pero no resuelve el problema de la hidratación de la misma forma.

Qwik City y el ecosistema

Qwik City es al framework lo que SvelteKit es a Svelte: routing por ficheros, routeLoader$ para datos en el servidor, routeAction$ para formularios, SSR por defecto y adaptadores estables para Vercel, Cloudflare Pages, Netlify, Node y despliegue estático. Con Qwik 1.5, lanzado en marzo de 2024, los adaptadores dejaron de tener sorpresas en producción y la integración con Vite 5 es sólida.

El ecosistema sigue siendo pequeño comparado con React:

• Componentes: Qwik UI y Modus.
• Formularios: modular-forms.
• Estado global: los signals integrados suelen bastar.
• Testing: Vitest y Playwright.
• Interoperabilidad React: qwik-react permite islands, pero con coste de perder la resumibilidad en esos nodos.

Dónde compensa y dónde no

Qwik brilla cuando la métrica crítica es el TTI en móvil y la página tiene interactividad real pero no es una SPA de estado masivo: e-commerce, portales de contenido con comentarios, marketing sites con configuradores, dashboards públicos. En esos escenarios el bundle cero se traduce directamente en conversión — cada 100 ms de mejora en LCP mueve aguja en tiendas medianas.

Qwik no compensa en casos igual de claros. Un equipo con años de inversión en React paga un coste alto por migrar. Para apps muy cliente-pesadas — editores colaborativos, herramientas realtime — el código acaba cargándose igual y Qwik no aporta tanto frente a una buena partición de rutas en Next.js. Para sitios casi estáticos con islands puntuales, Astro sigue siendo una elección más simple con acceso directo al ecosistema React.

Adopción real

La adopción está en fase early: Builder.io usa Qwik para su propio marketing, Daily.dev lo incorpora parcialmente, hay casos reportados en shops medianos como alternativas a Shopify Hydrogen, y algunas agencias europeas lo venden como ventaja competitiva en Core Web Vitals. No es un stack mayoritario, pero el concepto de resumibilidad ya influye en otros frameworks: React Server Components persiguen un objetivo parecido por otro camino.

Conclusión

Qwik resuelve bien un problema real y lo hace con una idea que merece existir. Para un greenfield donde el rendimiento es un KPI y el equipo puede permitirse un paradigma nuevo, es una elección defendible y técnicamente superior a casi cualquier alternativa en el escenario de interactividad bajo demanda. Para el resto — la mayoría — SvelteKit, Astro o Next.js con App Router siguen siendo apuestas más seguras. Qwik no necesita ganar la guerra de los frameworks para haber dejado huella: ya ha demostrado que la hidratación no es inevitable, y eso cambia la vara de medir del resto.