Qwik 2 : et si le frontend devait simplement en faire moins ?
Qwik fait partie de ces technologies que j'avais découvertes un peu par curiosité.
C'était en 2025. J'avais pris le temps de le tester simplement pour comprendre ce qu'il proposait et pourquoi son approche du frontend était différente de ce que je connaissais déjà.
À l'époque, une idée m'avait particulièrement intrigué : ne pas demander au navigateur de refaire tout le travail effectué par le serveur.
Je n'avais pas vraiment suivi les évolutions du projet depuis.
Puis récemment, je vois passer Qwik 2.0 RC.
Forcément, ça m'a donné envie de retourner voir ce qui avait changé.
Pas seulement pour lire une liste de nouveautés, mais pour répondre à une question :
Est-ce que Qwik 2 continue dans la direction qui m'avait intéressé en 2025 ?
Pour comprendre ça, il faut revenir rapidement sur le problème que Qwik cherche à résoudre.
Une page peut être affichée sans être vraiment prête
Quand une page apparaît dans notre navigateur, on peut facilement penser que tout est terminé.
Pourtant, dans une application web moderne, le navigateur peut encore avoir pas mal de travail à faire.
Le serveur peut générer le HTML et l'envoyer :
La page est alors visible.
Mais pour la rendre interactive, il faut généralement encore télécharger et exécuter du JavaScript : les boutons doivent fonctionner, les menus doivent réagir, les formulaires doivent pouvoir être utilisés, etc.
C'est notamment là qu'intervient l'hydration.
L'hydration, c'est quoi ?
On peut voir l'hydration comme l'étape où le navigateur prend le HTML déjà affiché et lui rattache la logique JavaScript nécessaire pour que l'application puisse réellement fonctionner.
En simplifiant :
Ce processus fonctionne très bien et peut être optimisé.
Mais Qwik pose une autre question :
Et si on pouvait éviter cette étape ?
C'est là qu'arrive Qwik
Qwik repose notamment sur la resumability, ou « reprise » de l'application.
L'idée est assez simple : le serveur ne se contente pas de produire le HTML. Il laisse également au navigateur les informations nécessaires pour reprendre l'application là où le serveur s'est arrêté.
Le navigateur n'a donc pas besoin de reconstruire toute l'application au démarrage.
C'est le cœur de l'approche de Qwik : rendre l'application interactive sans passer par une hydration complète.
Et c'est probablement ce qui m'avait le plus marqué lors de mes premiers tests.
Qwik ne cherche pas seulement à accélérer le travail du navigateur.
Il cherche surtout à ne charger et exécuter que ce qui devient nécessaire.
Mais le JavaScript ne disparaît pas
C'est une précision importante.
Qwik n'est évidemment pas un framework « sans JavaScript ».
Une application interactive en aura besoin. La différence se trouve plutôt dans le moment où ce JavaScript est chargé et exécuté.
Imaginons un tableau de bord avec une recherche, des filtres, un profil et plusieurs graphiques.
L'utilisateur arrive, consulte ses données et ne touche à aucun filtre.
Pourquoi faudrait-il que le navigateur prépare immédiatement toute la logique de ces filtres ?
Avec Qwik, le principe est plutôt de laisser certaines parties tranquilles jusqu'à ce qu'elles deviennent utiles.
C'est ce que Qwik met notamment en avant avec son lazy loading automatique.
Le chargement du code devient ainsi davantage lié à l'utilisation réelle de l'application.
Alors, qu'est-ce qui change avec Qwik 2 ?
C'est ici que mon intérêt revient.
Qwik 2.0 RC a été annoncé le 1er octobre 2026. L'équipe le présente comme une réécriture complète du framework, et pas simplement comme une version apportant quelques fonctionnalités supplémentaires.
Ce qui m'intéresse surtout, c'est que la philosophie de départ reste là, tout en essayant de réduire certains coûts internes de Qwik 1.
Dans Qwik 1, des marqueurs étaient présents dans le HTML afin de permettre au framework de retrouver certaines informations nécessaires à la reprise de l'application.
Avec Qwik 2, ces informations sont davantage regroupées et encodées à la fin du HTML.
L'objectif est notamment de réduire le coût de cette représentation tout en conservant la possibilité de reprendre l'application côté navigateur.
L'équipe annonce ainsi jusqu'à 30 % de réduction de la taille de l'état sérialisé dans le HTML, selon les cas.
Ce détail peut sembler assez technique, mais il illustre bien la direction prise :
Qwik 2 ne cherche pas seulement à conserver son idée originale. Il cherche aussi à réduire le coût de cette idée.
Le streaming devient encore plus intéressant
Qwik 2 introduit également un support expérimental du out-of-order streaming.
L'idée est plus simple à comprendre avec un exemple.
Imaginons une page composée de plusieurs blocs :
Si un bloc prend plus de temps à être récupéré, pourquoi faudrait-il nécessairement attendre ce bloc pour envoyer le reste de la page ?
Le out-of-order streaming permet justement au serveur d'envoyer ce qui est déjà prêt, puis de compléter la partie manquante lorsqu'elle devient disponible.
L'idée est finalement assez cohérente avec le reste de Qwik :
ne pas faire attendre toute la page à cause d'une partie qui n'est pas encore prête.
Qwik 2 apporte également des évolutions autour des états asynchrones avec <Pending> et <Catch>, ainsi que des loaders pouvant être mis en cache individuellement.
Et côté développeur ?
Une architecture peut être intéressante sur le papier. Mais si elle rend le développement pénible, ça devient rapidement un problème.
Qwik 2 apporte notamment une nouvelle base autour de Vite 8 et Rolldown, ainsi qu'un HMR capable de conserver l'état des signals et des stores pendant les modifications.
Il y a également des évolutions autour du debugging, des tests et de la réactivité.
Je ne vais cependant pas transformer l'article en catalogue de fonctionnalités.
Ce qui m'intéresse davantage, c'est de voir comment ces changements servent la même direction :
rendre le framework plus efficace sans abandonner le modèle qui fait son originalité.
Qwik n'est évidemment pas seul
Il serait assez facile de transformer cet article en « Qwik contre tout le monde ».
Ce n'est pas vraiment le sujet.
D'autres frameworks cherchent eux aussi à réduire le travail effectué côté navigateur, mais avec des stratégies différentes.
Astro mise notamment sur les islands : une page peut rester principalement en HTML et seules certaines parties deviennent interactives.
Svelte déplace une partie du travail vers la compilation.
React explore davantage le rendu serveur avec les Server Components.
Qwik choisit une autre voie avec la resumability.
Les approches sont différentes, mais une question commence à devenir commune :
> Est-ce qu'on a réellement besoin d'envoyer et d'exécuter autant de code côté navigateur ?
Et c'est probablement cette question qui m'intéresse davantage que le choix d'un framework particulier.
Alors, Qwik 2 vaut-il le détour ?
Je ne vais pas dire que Qwik 2 va remplacer React, Svelte ou Astro.
Ce serait facile à écrire, mais pas forcément très intéressant.
Qwik 2 est encore en release candidate, et certaines fonctionnalités doivent encore être stabilisées avant la version 2.0 finale.
Mais pour faire de la veille technologique, c'est justement un bon moment pour regarder.
On peut tester, lire le code, comprendre les choix d'architecture et surtout comparer avec ce qu'on utilise déjà.
Personnellement, ce que je retiens de Qwik après mes premiers tests en 2025 et ce retour sur Qwik 2, ce n'est pas une fonctionnalité particulière.
C'est une manière différente de poser le problème.
On cherche souvent à optimiser une application en se demandant :
« Comment faire ce travail plus rapidement ? »
Qwik pousse plutôt une autre question :
« Est-ce qu'on a vraiment besoin de faire ce travail maintenant ? »
Et finalement, c'est peut-être ça que je trouve le plus intéressant.
Pas forcément Qwik lui-même.
Mais le fait qu'un framework nous oblige à reconsidérer certaines choses que l'on finit par prendre pour acquises dans le développement frontend.
Pour aller plus loin
Si vous voulez vous faire votre propre idée, voici quelques ressources utiles :
- Documentation officielle de Qwik
- Comprendre la resumability
- Documentation de migration vers Qwik 2
- Annonce de Qwik 2.0 RC
- Dépôt GitHub de Qwik
Et surtout, si vous avez déjà utilisé Qwik, la meilleure manière de comprendre Qwik 2 reste probablement de le tester.
Pour essayer la release candidate :
pnpm create qwik@rc
La documentation propose également un playground pour expérimenter directement avec Qwik.