Qwik : l'avenir des frameworks ?

Quel est le problème que Qwik tente de résoudre ?

En tant que développeurs web, nous voulons développer la meilleure expérience utilisateur (UX) possible. L'expérience utilisateur se résume à deux choses : rendre les sites web interactifs et les rendre réactifs. Mais ces objectifs sont naturellement contradictoires : l'interactivité implique le téléchargement de JavaScript et le téléchargement de JavaScript rend les sites web plus lents et moins réactifs.

React est une excellente solution pour créer des interfaces complexes ... mais dans React autonome, vous devez télécharger tout le code avant d'afficher une interface. Du point de vue de l'utilisateur, votre site web est lent. Et du point de vue d'un bots de moteur de recherche, votre site web est cher à lire.

La solution développée par Next JS (en collaboration avec React) est de faire le ** rendu initial sur le serveur** — c'est ce qu'on appelle le Server Side Rendering (ou SSR). De cette façon, le client voit l'interface et le texte avant que l'application ne télécharge le moindre code, et les bots des moteurs de recherche ont beaucoup plus de facilité à indexer la page.

Cependant, une fois que le navigateur a reçu le code HTML, il télécharge le JavaScript depuis le serveur et redémarre l'application dans une phase appelée "hydratation". Une fois l'hydratation terminée, le navigateur prend la responsabilité du rendu.

Pour ce faire, il redémarre l'application et se synchronise avec le serveur.

Mais cela signifie que le navigateur effectue le même travail de rendu que le serveur a juste fait avant d'être interactif. Le même travail est effectué deux fois. Une fois sur le serveur, et une fois pour que le client rattrape le serveur.

Au lieu de télécharger le framework et d'exécuter le même rendu que le serveur, Qwik fait quelque chose de différent. La sortie de Qwik ne contient presque pas de JavaScript et ne procède à aucune hydratation, ce qui se traduit par des performances ultra-rapides.

Comment Qwik réussit-il cet exploit ? En d’autres termes :

Pourquoi Qwik est-il révolutionnaire ?

Qwik a deux tours dans son sac. Il fait du Tree Shaking dynamique et du rendu Resumable. Comment ? Parlons de la façon dont une page se retrouve sur le navigateur.

Tree shaking dynamique

Comme Svelte, le premier endroit où la magie opère est la phase de compilation. Ici, Qwik divise toute la logique de l'application en petits paquets. Dans Qwik, chaque “closure” — chaque bloc de code, en quelque sorte — peut devenir un “chunk”, un morceau. Cela se fait à l'aide d'un compilateur écrit en Rust, qui identifie quand chaque bout de code est appelé.

Les bouts de code jamais appelés et les commentaires sont mis de côté. Il s'agit d'un "Tree Shaking" de base, que tous les compilateurs effectuent.

Cependant, le compilateur de Qwik identifie également les morceaux de code qui ne sont appelés que lors du rendu initial et ceux qui sont nécessaires à une interactivité supplémentaire. Que fait-il de ces “chunks” ? Et bien avant de s’en occuper, il effectue le rendu de la page. Comment Qwik fait-il cela ?

Resumabilité

Quelques points méritent d'être soulignés ici. Tout d'abord, comme React et Solid, Qwik utilise la syntaxe JSX pour définir la sortie HTML.

Cependant, contrairement à React, Angular, Solid ou Svelte, Qwik est un framework côté serveur. Dans un sens, Qwik est plus proche de Next JS que de React. Comme NextJS, Qwik effectue un rendu de la sortie HTML en utilisant le code JavaScript.

Cependant, contrairement à NextJS, Qwik ne se préoccupe pas que du rendu. Il se préoccupe également de Lazy Loading, des Chunks, des points d'entrée, de la sérialisation de l'état et de sa reprise en main par le client.

Parlons de ce dernier point. Comparé à NextJS, Qwik envoie plus d'informations dans la sortie HTML et envoie moins de code JavaScript. Qwik enregistre l'état du framework dans le HTML envoyé au client, c'est le premier pas vers la “résumabilité”. Cet état sérialisé comprend les limites des composants, les listeners d'événements et l'état de l'application.

La deuxième étape est que chaque élément interactif de l'interface contient une référence aux petits morceaux de code que nous avons mentionnés précédemment. Cette référence est un lien vers le code JavaScript.

La dernière pièce du puzzle de la "resumabilité" est un petit bout de code d’un kilooctet, le Qwik Loader. Il utilise les web workers pour télécharger les petits morceaux de JavaScript produits dans la première phase par le compilateur. Les petits bouts dont la page a besoin pour être interactive. Le Loader télécharge en arrière-plan sans utiliser le thread principal. C'est similaire à la façon dont Partytown fonctionne. Mais ce n'est pas une surprise puisque Partytown est développé par Builder.io, tout comme Qwik. Et non seulement le code JavaScript est chargé de manière différée, ou Lazily Loaded, mais il est également exécuté de manière différée.

C'est exactement comme si le JavaScript nécessaire était streamé vers le navigateur à la demande, plutôt que téléchargé en un seul (gros) bloc. En fait, cela me rappelle la différence entre télécharger et streamer un film.

Il existe un protocole de streaming vidéo appelé HLS. Ce protocole consiste à découper un film en petits morceaux qui sont ensuite servis via HTTP. Streamer un film, c’est télécharger de cette séquence de petits morceaux du film. Et il n’y a besoin de télécharger que les morceaux qui viennent après la tête de lecture, l’endroit où on en est dans le film. On peut reprendre la lecture à n’importe quel endroit. Le compilateur, l'"Optimizer", est ce qui produit les petits morceaux. Le Qwik Loader est le lecteur qui récupère les morceaux dont il a besoin.

C'est ça qui permet à Qwik d'être si rapide et réactif.

Alors... Qwik vaut-il la peine d'être appris ?

Il y déjà des milliards de frameworks qui se battent pour des parts de cerveaux des développeurs. Est-ce vraiment utile d'en apprendre un nouveau ? Je veux dire, j'ai déjà un score de 97% sur mon site web basé sur NextJS. Ai-je vraiment besoin d’une nouveau framework pour passer à 100 ?

J'ai deux réponses à cette question.

Tout d'abord, je suis déjà très satisfait de mon 97%. Bien sûr, Qwik m'apportera 3 points de pourcentage de plus. Mais NextJS s'accompagne d'un riche écosystème. C'est l'implémentation de référence de React. NextJS dispose en plus de nombreuses bibliothèques qui me permettent de faire tout ce dont j'ai besoin. La documentation va en profondeur, et il y a de nombreuses ressources... Tout cela manque à Qwik. Je ne pense donc pas utiliser Qwik pour des projets sérieux, du moins pas pour l'instant.

Mais, et c'est un grand mais : je crois que la façon dont Qwik fait les choses c’est l'avenir. C’est donc important de comprendre comment Qwik fonctionne. Comment le framework est structuré. Où se trouve la magie. Et ce que cela implique en termes de codage — en particulier, ce qui se passe avec nos variables lorsque le code est divisé en petits morceaux.

Je ne pense pas qu’on utilisera tous Qwik à l'avenir. Mais c’est probable que React et NextJS seront, disons, inspirés par les innovations de Qwik. Et apprendre Qwik vous donnera une longueur d'avance. Et une nouvelle perspective sur la façon dont les frameworks fonctionnent.

Alors oui, je crois que c'est une bonne idée d'utiliser Qwik. Ce qui m'amène au point suivant :

Comment apprendre Qwik ?

Si (comme moi) vous souhaitez en savoir plus, je vous recommande le cours gratuit créé par Qwik et mettant en scène Miško Hevery, où il explique pourquoi Qwik existe, et comment l'utiliser. Vous pouvez le trouver sur qwikschool.com. La documentation du site web de Qwik est également très instructive. La section sur la resumabilité vs hydratation est particulièrement intéressante. Il existe également plusieurs podcasts intéressants, l'un intitulé Qwik est un nouveau type de framework, et un autre Qwik a la bonne dose de magie .