Qwik Lazy Loading

En la lección anterior hemos visto como el SSR es el defecto, y como algunos scripts son cargados on demand solamente si se necesitan. Tiene mucho sentido: al fin y al cabo, ¿para qué cargar scripts de JavaScript que no son requeridas por el usuario?

Es aquí donde entran en juego dos conceptos importantes de entender: hydration y serialization o resumability. Mientras que los frameworks a los que estamos acostumbrados optan por una estrategia de hydration, Qwik apuesta fuerte por serializar su código. Veamos qué es esto a lo que nos referimos:

• Una estrategia de hidratación hace que la misma lógica que se corrió en el servidor se vuelva a correr en el cliente. Esto supone un gran coste en cuanto a rendimiento ya que, en el caso de una aplicación por ejemplo, implica descargarse todos los componentes, todos sus scripts de JavaScript, parsear ese JavaScript y vincular los listeners a los elementos.
• Serializar el código implica, en palabras de los creadores de Qwik, poder pausar la ejecución en el servidor, y reanudarla en el cliente, pero solo si así se requiere.

La documentación de Qwik lo ejemplifica de maravilla de la siguiente forma:

Cuando hablamos de serializar el código, hablamos también de cómo Qwik conecta el componente con el script que tiene que cargar. Compara lo que escribimos en el JSX y lo que se renderiza en el DOM (utilizaremos el ejemplo del botón de la lección del SSR).

   // Path: src/routes/index.tsx
   import { component$ } from "@builder.io/qwik";
   
   export default component$(() => {
     console.log("SERVIDOR: Cuando me monto, aparezco 🐴");
     return (
       <div>
         <button onClick$={() => console.log("CLIENTE: me cargo on demand 👨‍🍳")}>
           Hazme click
         </button>
       </div>
     );
   });
          

Aquí os dejo otra forma de contemplarlo, según lo explica Miško Hevery, creador de Builder.io/Qwik y Angular, en un hilo de Twitter: