Introduction à Qwik : un framework JavaScript ultra-rapide

Qwik est une refonte audacieuse de comment fonctionnent les interfaces utilisateur réactives. Le principe de base est que le framework est construit à partir de zéro pour fournir du HTML avec un minimum de JavaScript, juste assez de JavaScript pour introduire progressivement l’interactivité selon les besoins.

Qwik utilise un modèle à grain fin pour isoler les segments de l’application qui sont hydratés en fonction des besoins. En partant des premiers principes, Qwik permet des performances autrement inaccessibles et représente une voie alternative pour l’évolution du JavaScript frontal.

État de Qwik

Qwik en est encore aux premières versions, mais il a parcouru un long chemin depuis la première je l’ai regardé. Il y a maintenant un exemple complet sur StackBlitzun Aire de jeux REPL, et un outil de ligne de commande. Qwik a également évolué pour prendre en charge une syntaxe de type React plus conviviale pour les développeurs. Sous le capot se trouve toujours un moteur réactif avancé et unique en son genre qui définit les limites réactives en fonction de l’état, des modèles et des écouteurs.

Possibilité de reprise

Qwik utilise une combinaison de rendus intelligents côté serveur et côté client pour éviter le type de double imposition dont souffrent les frameworks contemporains en effectuant le travail d’hydratation deux fois, une fois sur le serveur, et de nouveau sur le client.

En tant que créateur de Qwik Misko Hevery écrit:

L’idée de base derrière Qwik est qu’il peut être repris. Il peut continuer là où le serveur s’est arrêté. Il n’y a qu’une infime quantité de code à exécuter sur le client.

Ou, en d’autres termes : laissez le serveur configurer une page HTML aussi pleinement fonctionnelle que possible et autorisez le client à effectuer le moins de travail possible pour continuer ou reprendre le processus pour l’utilisateur.

Le flux typique dans les frameworks réactifs avec SSR (rendu côté serveur) consiste à générer d’abord une version de l’application sur le serveur, puis à l’expédier au client, qui rend l’application échafaudée. À ce stade, l’application côté client prend le relais, devant essentiellement redémarrer la même application afin de connecter un client fonctionnel.

Ce processus est connu sous le nom d’hydratation. Il existe plusieurs façons intelligentes d’essayer de rendre l’hydratation plus efficace, mais Qwik les abandonne pour un nouveau processus appelé possibilité de reprise.

La capacité de reprise signifie que le client peut reprendre là où le serveur s’est arrêté, sans avoir à reconstruire l’application sur le client.

Temps d’interactivité

La mesure que Qwik s’efforce d’améliorer est le temps d’interactivité (TTI). Il s’agit du temps qui s’écoule entre le moment où l’utilisateur fait une demande sur une page Web et le moment où la page devient réactive à l’interaction de l’utilisateur.

Alors que le temps de chargement (TTL) suit le temps qu’il faut au client pour finir de recevoir toutes les données requises (et est donc une mesure déterminée en grande partie par la taille des fichiers et la vitesse du réseau), TTI prend en compte un fait important des frameworks JS modernes : une fois les données sont téléchargées, le client doit alors décompresser et exécuter le code JavaScript nécessaire pour rendre la page interactive.

Il y a beaucoup de travail qui va dans un moteur réactif. Le moteur doit démêler/analyser tout ce balisage (comme JSX) parcouru avec des variables et des expressions qui modifient ce qui est affiché en fonction de l’état changeant, et comment il se comporte en fonction du code.

À l’autre extrémité du spectre se trouve une page HTML simple. Une fois que le navigateur s’en est emparé, la page est prête à basculer. C’est pourquoi PageSpeed ​​Insights de Google donne à une page comme Reddit.com un 32 sur 100 score, tandis que le HTML brut obtient un score de 100.

Fermetures et auditeurs

L’obstacle technique pour accélérer le TTI est décrit par Hevery comme “la mort par fermeture”. En bref, le fait que chaque fermeture doit conserver l’univers d’informations englobant signifie que l’application d’exécution est un gâteau en couches de code chargé avec impatience.

La solution employée par Qwik consiste à utiliser un écouteur d’événements global qui interagit avec des écouteurs sérialisés. En d’autres termes, un écouteur d’événement universel est utilisé pour orchestrer les écouteurs qui sont réalisés à la demande, au lieu que les écouteurs soient téléchargés et enveloppés dans des fermetures (qu’ils s’exécutent ou non).

Qwik vise à offrir une réactivité en ligne avec le HTML, le rendant entièrement sérialisable. Seul un petit exécutable est nécessaire pour manifester ensuite la réactivité au moment de l’exécution, en fonction des informations encapsulées dans le balisage.

Division du code, finement réglée

Une autre façon de voir cela est que Qwik effectue un fractionnement de code affiné. Il charge le code interactif selon les besoins, lorsque l’utilisateur le demande. Les bundlers sont alors en mesure de regrouper ces morceaux en morceaux plus gros si cela a du sens.

Qwik est construit à partir de zéro avec trois fonctions distinctes pour créer un état, un modèle et des écouteurs. Cela permet au framework de charger uniquement ce qui est nécessaire pour la tâche à accomplir. Vous pouvez en savoir plus sur cet aspect de segmentation ici.

Les trois limites de l’état, du modèle et de l’écouteur étaient à un moment donné directement codées par les développeurs. Grâce à un nouveau Outil d’optimisation qui convertit la syntaxe de type React en ces limites dans les coulisses, vous obtenez un DX assez familier. Et l’optimiseur fait le travail de transformer le code réel en un ensemble de minuscules stubs qui peuvent reprendre l’application en petits morceaux si nécessaire.

Avec l’optimiseur, les modèles et les écouteurs sont indiqués par un signe dollar, tandis que l’état est géré par le useStore accrocher. Vous verrez cette syntaxe dans un instant.

La sortie finale du code Qwik ne ressemble pas à celle des autres frameworks, mais l’utilisation de Qwik avec l’optimiseur le met à parité avec d’autres frameworks. Qwik a également introduit QwikCity, un ensemble de fonctionnalités d’ordre supérieur telles que le routage qui facilitent la création d’applications à grande échelle.

Pratique avec Qwik

Maintenant que vous avez compris les concepts derrière Qwik, essayons de coder avec. Le listing 1 montre un composant simple écrit en Qwik. (Cet exemple provient du FAQ Qwik.)

Listing 1. Composant Qwik simple

import  component$  from '@builder.io/qwik';
export const App = component$(() => 
  console.log('render');
  return <p onClick$=() => console.log('hello')>Hello Qwik</p>;
);

Le listing 1 montre qu’un composant dans Qwik est défini comme une fonction anonyme, transmise au component$ fonction de la bibliothèque Qwik. Chaque fois que vous voyez un signe dollar $ dans Qwik, il fait savoir à l’optimiseur qu’il doit faire du travail. Les parties de l’application signées en dollars sont celles où Qwik instrumentera ses limites de chargement paresseux à grain fin.

La onClick$ dans le Listing 1 est un autre exemple de la syntaxe spéciale de Qwik. Qwik utilisera quelques astuces pour charger uniquement le JavaScript nécessaire pour prendre en charge la fonctionnalité lorsqu’elle est réellement requise.

Le code de la liste 1 sera divisé par l’optimiseur en plusieurs segments, comme indiqué dans la liste 2.

Listing 2. Composant Qwik après compilation

// The app.js file itself
import  componentQrl, qrl  from "@builder.io/qwik";
const App = /*#__PURE__*/ 
componentQrl(qrl(()=>import('./app_component_akbu84a8zes.js'), "App_component_AkbU84a8zes"));
export  App ;
// app_component_akbu84a8zes.js
import  jsx as _jsx  from "@builder.io/qwik/jsx-runtime";
import  qrl  from "@builder.io/qwik";
export const App_component_AkbU84a8zes = ()=>
    console.log('render');
    return /*#__PURE__*/ _jsx("p", 
        onClick$: qrl(()=>import("./app_component_p_onclick_01pegc10cpw"), "App_component_p_onClick_01pEgC10cpw"),
        children: "Hello Qwik"
    );
;
// app_component_p_onclick_01pegc10cpw.js
export const App_component_p_onClick_01pEgC10cpw = ()=>console.log('hello');

Vous pouvez voir dans le Listing 2 qu’au lieu d’inclure la fonctionnalité réelle du composant, Qwik inclut une référence, en utilisant le componentQrl() fonction de la bibliothèque. Cette fonction prend un qrl() fonction qui utilise une fonction anonyme pour importer le fichier de composant généré. Cette association entre composants est entièrement gérée sous le capot par l’Optimizer. Le développeur n’a pas besoin d’y penser directement.

QRL signifie Qwik URL, qui est la façon dont Qwik fait référence à quelque chose qui sera chargé paresseusement. Fondamentalement, chaque fois que le framework doit différer le chargement de quelque chose, il insère une QRL, enveloppée par un consommateur spécifique à la QRL (comme un composant, un état ou une fonction de modèle).

Par exemple, le componentQRL peut se charger au bon moment dans le code présent dans le composant enfant tandis que le parent peut afficher rapidement sa mise en page. De même avec le onClick handler : Il peut être évalué lorsque le clic se produit.

CLI Qwik

L’outil de ligne de commande est disponible auprès de npm et possède les fonctionnalités de base que vous attendez, notamment la création, le mode de développement et la génération de production. La CLI Qwik utilise Vite comme outil de génération. Vous pouvez démarrer une nouvelle application avec npm create qwik@latestqui lancera une invite interactive.

Si vous créez une application simple et exécutez la version de production, vous obtiendrez un dist répertoire où vous pouvez voir tous les morceaux séparés à chargement différé de l’application que nous avons décrits précédemment.

Un ajustement Qwik

Un endroit intéressant pour se faire une idée de la syntaxe Qwik est le Aide-mémoire Qwik, qui propose des comparaisons côte à côte du code Qwik et React. Vous verrez que dans l’ensemble, la transition n’est pas si difficile. Certains domaines sont assez similaires, et certains nécessitent surtout un changement de mentalité. Le plus gros avantage est que le système réactif dans Qwik est radicalement différent des frameworks de type React, malgré la similitude de syntaxe obtenue avec l’optimiseur.

L’approche innovante de Qwik en matière de fractionnement de code et de chargement paresseux offre une nouvelle voie pour le JavaScript frontal. Il sera intéressant de voir où les choses vont à partir d’ici.