Qwik

Ouais ouais, encore un framework.
Mais pas juste “un de plus”.
Un truc chelou, bizarrement malin, qui t’fait te poser des questions du genre :
“Et si on arrêtait enfin d’envoyer une appli entière pour afficher un bouton ?”

Faut dire les choses :
On a passé 10 ans à tout rendre SPA.
À tout pré-rendre. À tout re-hydrater.
À balancer 500ko de JS juste pour faire apparaître un “Ajoutez au panier”.

Résultat ?
Des perfs dégueu, des LCP qui pleurent, et du JS qui charge, parse, compile, exécute… alors que l’utilisateur veut juste scroller.

Et là, débarque Qwik.

👉 Le pitch ? Radical :
“Zero JavaScript à charger au début. Vraiment zéro. Nada.”
Tout est pauseable. Tout est re-hydraté… à la demande.
Quand t’interagis. Pas avant.
Ils appellent ça le resumability.
Et ouais, c’est aussi fou que ça en a l’air.

Imagine.
Tu fais un site e-commerce.
Qwik va te pré-rendre toute la page côté serveur.
Le JS ? Il est suspendu. Littéralement figé dans le HTML, prêt à reprendre là où le serveur l’a laissé.
Tant que l’utilisateur clique pas, le JS bouge pas.
Pas de bundle à parser. Pas de runtime à instancier.

Et quand l’utilisateur clique ?
Qwik ne charge que le bout de code nécessaire à CETTE interaction.

C’est comme du lazy loading… mais pour TOUT.

Alors ouais, c’est pas React.
C’est pas un écosystème mature avec 50k plugins.
C’est nouveau. C’est déroutant.
Tu vas rager les 3 premiers jours.
Mais une fois que t’as capté le délire…
Tu vois le futur.

Qwik, c’est pas juste un framework.
C’est une réponse front à la crise climatique du JS.

On a surconsommé.
Maintenant faut penser sobriété.
Et Qwik, lui, te regarde et te dit :
“T’as vraiment besoin de 300ko de JS pour gérer un menu burger ? Sérieux ?” 😏

💬 Tu l’as testé ou pas encore ?
Tu crois que c’est le futur… ou juste une expérimentation de plus ?
Viens m’le dire, j’suis curieux d’avoir ton avis 👇