Qwik lleva desde 2022 defendiendo una idea concreta: la hidratación es deuda, no funcionalidad. Un sitio bien construido debería poder reanudar el estado del servidor en el navegador sin ejecutar de nuevo todo el árbol de componentes.

Detrás del proyecto está Miško Hevery, el creador de Angular. Arrancó Qwik como proyecto personal en enero de 2021 y lo llevó a tiempo completo en Builder.io desde junio de 2022, según contó él mismo en una entrevista con The New Stack[1]. El código vive en el repositorio de QwikDev en GitHub[2], donde se puede seguir el ritmo de cada versión.

Dos años y medio después de su primer estable, la serie 1.x está asentada y hay casos reales publicados por empresas que no son el autor original. Toca revisar si esa idea se sostiene cuando tocas un teclado real, si compensa la curva de aprendizaje y en qué tipo de producto pesa más ese ahorro de JavaScript en cliente.

Para elegir framework frontend, el análisis de HTMX en empresa describe la alternativa sin JavaScript de cliente. El post sobre TypeScript 5.5 tipos avanzados cubre el ecosistema de tipado donde Qwik opera. El rendimiento en cliente conecta también con el tema de accesibilidad básica WCAG, donde la carga inicial impacta la experiencia.

Puntos clave

  • Qwik serializa estado y manejadores de eventos dentro del propio HTML; el cliente reanuda desde donde paró el servidor sin reconstruir el árbol de componentes.

  • Un sitio en Qwik suele pesar 20-50 KB de JavaScript de entrada frente a los 200-500 KB habituales en una aplicación Next o Nuxt media.

  • Encaja bien en comercio electrónico, medios de comunicación y aplicaciones B2C donde el tiempo a interactivo es una métrica comercial.

  • El ecosistema joven con huecos visibles y un cambio de modelo mental real son los dos frenos principales.

  • Qwik City cubre el 80% de lo que un producto necesita sin buscar fuera.

Qué significa resumible en la práctica

React y Vue hidratan. El servidor renderiza HTML, lo envía al navegador y, cuando el JavaScript llega, el cliente vuelve a ejecutar todo el árbol de componentes para asociar handlers de eventos. Esto funciona, pero tiene un coste visible en dispositivos modestos y en redes lentas. Cuanto más grande la aplicación, más tiempo antes de que el usuario pueda interactuar.

Qwik hace algo distinto. El servidor renderiza HTML y, en lugar de enviar un árbol de componentes serializado, serializa el estado y los manejadores de eventos dentro del propio HTML. Cuando el usuario hace clic, un cargador pequeño descarga solo el código del manejador que necesita y lo ejecuta. No hay reconstrucción del árbol, no hay pase de hidratación, no hay coste inicial de JavaScript salvo el cargador mínimo.

La palabra que usan es resumibilidad y describe con precisión lo que hace la arquitectura. El servidor ejecuta una vez, pausa, serializa; el cliente reanuda desde donde quedó. Lo que en otros frameworks es ejecutar dos veces (una en servidor, otra en cliente), en Qwik es ejecutar una sola vez, con una pausa larga entre pasos.

La documentación oficial de Qwik sobre resumibilidad[3] lo describe serializando tres cosas en el HTML: los manejadores de eventos, los límites de cada componente y el estado de la aplicación. Builder.io detalla en su comparación entre resumibilidad e hidratación[4] por qué ese salto evita la re-ejecución que la hidratación obliga a pagar.

Qué empuja a usarlo

Lo que empuja a usar Qwik es una cosa concreta: aplicaciones donde el tiempo a interactivo es un problema de negocio medible:

  • Tiendas de comercio electrónico donde cada segundo más tarda la página cuesta ventas.

  • Medios de comunicación donde el tiempo hasta que el usuario puede hacer scroll es métrica central.

  • Aplicaciones B2C donde el abandono tiene coste.

Para estos casos, un sitio en Qwik suele pesar entre 20 y 50 KB de JavaScript de entrada, frente a los 200 a 500 KB que ves en una aplicación Next o Nuxt media. Esa diferencia es palpable en Lighthouse, en Web Vitals y en la experiencia percibida sobre todo en el primer minuto de una visita nueva.

Dónde vale menos la pena

Lo que empuja a no usarlo es el tamaño del ecosistema. React tiene miles de librerías maduras: tablas, gráficos, editores de texto, calendarios, componentes accesibles. Qwik tiene un ecosistema joven con huecos visibles.

Si tu producto depende de un componente de edición de texto rico con veinte plugins, lo vas a tener más fácil con React. Si tu producto es formularios, rutas y algo de estado, Qwik cubre el caso. La encuesta State of JS 2025[5] confirma esa sensación de ecosistema pequeño. Los demás frameworks frontend se mantienen estables de un año a otro, y Qwik es la excepción que sigue perdiendo puestos en la satisfacción declarada por los desarrolladores encuestados.

El segundo freno es el equipo. Qwik cambia el modelo mental lo suficiente como para que un desarrollador React no se mueva con soltura el primer mes. Las funciones que se marcan con el sufijo dólar, la manera de separar código entre servidor y cliente, los avisos del optimizador sobre dependencias no capturables: todo esto requiere entender cómo funciona la serialización. Un equipo de seis personas invierte dos o tres sprints en estar cómodo, no más, pero esa inversión es real y hay que contarla.

Caminos habituales en 2025

El camino más común en 2025 es empezar con Qwik City, que es a Qwik lo que Next es a React. Trae enrutado basado en ficheros, carga de datos en el servidor, formularios declarativos e integraciones con plataformas de despliegue como Vercel o Cloudflare Pages. Qwik City está estable y cubre el 80% de lo que un producto necesita sin buscar fuera.

Para la capa de UI, la comunidad se ha asentado en pocas opciones: Qwik UI para componentes sin estilo y Tailwind para la apariencia. Tailwind no depende del framework; las clases viven en el HTML y Qwik serializa sin sorpresas. Otros sistemas de componentes que dependen de inyección CSS en runtime tienen peor encaje.

La carga de datos se hace con rutas de servidor que devuelven objetos serializados. El patrón habitual es usar routeLoader$ para leer datos en el servidor antes del render, y server$ para funciones que se exponen como RPC al cliente. Estas dos primitivas cubren los casos de comunicación habituales y tienen un modelo de error razonable.

Integración con servicios existentes

La integración con servicios externos rara vez es un problema. Qwik sirve como cualquier servidor web estándar, habla HTTP, puede consumir APIs REST o GraphQL sin diferencias frente a React.

Lo que cambia es cómo se reparte el trabajo entre servidor y cliente. En React suele ser más común hacer fetch en cliente con un spinner mientras llega la respuesta. En Qwik el patrón por defecto es hacer fetch en servidor y servir HTML ya completo, con el cliente reanudando solo la interactividad.

Un punto donde hay que pensar es la autenticación. Si la aplicación depende de un flujo OAuth con Authentik o Keycloak, Qwik City incluye mecanismos para gestionar cookies y sesiones en rutas de servidor de forma similar a como lo haría Next. No hay sorpresas, pero el patrón es un poco distinto y hay que leer la documentación una vez antes de no tener que volver a leerla.

Lo que aparece con meses de uso

Con meses de uso aparecen detalles que la documentación no cuenta:

  • La serialización del estado obliga a disciplina: cualquier cosa que no se pueda pasar a JSON genera avisos del optimizador. Esto fuerza a escribir estado más simple, lo cual acaba siendo bueno para el mantenimiento, pero cuesta al principio.

  • La trazabilidad de un error en producción es diferente: como el código se descarga en trozos, las trazas de pila en el navegador están más fragmentadas. Sentry y similares funcionan, pero la primera vez que depuras un error así tardas más de lo esperado.

  • El coste de compilación para producción es lento porque el optimizador analiza todas las fronteras de carga diferida: en proyectos medianos, compilaciones de un minuto o dos. No es drama para CI pero vale la pena saberlo.

Mi lectura

Qwik es una apuesta coherente a un problema real. El coste de JavaScript en cliente es una deuda silenciosa que casi todos los sitios modernos arrastran. La resumibilidad es la primera respuesta arquitectónica que he visto capaz de reducir esa deuda sin pagarla en otra parte.

No es magia: hay disciplina que aceptar, un ecosistema joven con el que convivir, una curva corta pero real. Pero los beneficios son medibles y visibles.

No creo que Qwik desplace a React, porque React tiene inercia y ecosistema. Creo que va a ocupar el hueco de productos donde el rendimiento en cliente es una métrica comercial: comercio electrónico, medios, landing pages de alto tráfico, aplicaciones B2C donde el abandono tiene coste. Mi criterio práctico es simple: si el equipo tiene apetito por aprender y el producto sufre por peso de JavaScript, Qwik es una apuesta sensata. Si el equipo es grande, el producto es complejo y el rendimiento no es métrica dura, React o Svelte siguen siendo la opción por defecto.

Este artículo también está disponible en inglés.

Fuentes:

  1. Qwik Documentation — Resumable (concepts)[3]
  2. Builder.io Blog — Resumability vs Hydration[4]
  3. The New Stack — Misko Hevery on Why Qwik Will Improve JavaScript Frameworks[1]
  4. GitHub — repositorio QwikDev/qwik[2]
  5. State of JS 2025 — Front-end Frameworks[5]

Preguntas frecuentes

¿Cuánto JavaScript descarga un sitio hecho con Qwik frente a uno en Next o Nuxt?

Un sitio en Qwik suele pesar entre 20 y 50 KB de JavaScript de entrada, frente a los 200 a 500 KB habituales en una aplicación Next o Nuxt media. La diferencia viene de la resumibilidad: el servidor serializa el estado, los límites de componente y los manejadores de eventos dentro del propio HTML. El cliente solo descarga el código del manejador cuando el usuario interactúa, sin pase de hidratación. El ahorro se nota en Lighthouse, en Web Vitals y sobre todo en el primer minuto de una visita.

¿Cuánto tarda un equipo React en trabajar con soltura en Qwik?

Un equipo de seis personas invierte dos o tres sprints en estar cómodo, no más, pero esa inversión es real. El cambio de modelo mental es suficiente para que un desarrollador React no se mueva con soltura el primer mes. Las funciones con sufijo dólar, la separación de código entre servidor y cliente y los avisos del optimizador sobre dependencias no capturables exigen entender cómo funciona la serialización. Cualquier estado que no se pueda pasar a JSON genera avisos, lo que obliga a escribir estado más simple.

¿Qué problemas aparecen con Qwik tras meses en producción?

Tres que la documentación no cuenta. La serialización obliga a disciplina, porque todo lo que no sea convertible a JSON genera avisos del optimizador. Las trazas de pila en el navegador están más fragmentadas, ya que el código se descarga en trozos; Sentry y similares funcionan, pero la primera depuración tarda más de lo esperado. Y la compilación de producción es lenta porque el optimizador analiza todas las fronteras de carga diferida: uno o dos minutos en proyectos medianos, asumible en CI pero conviene saberlo.

Fuentes

  1. una entrevista con The New Stack
  2. repositorio de QwikDev en GitHub
  3. documentación oficial de Qwik sobre resumibilidad
  4. Builder.io detalla en su comparación entre resumibilidad e hidratación
  5. State of JS 2025