Qwik : sur le point de révolutionner le développement web ?
HTML-код
- Опубликовано: 7 фев 2025
- Qwik propose des fonctionnalités uniques qui pourraient en faire un tournant aussi important qu’Ajax puis les PWA en leur temps. Ce framework propose une DX familière aux développeurs habitués à React, Vue et Solid.js. Mais est-il fait pour vous ? Va-t-il être adopté en entreprise ou vous permettre de créer des projets perso d’une performance jusque là inconnue ?
#qwik #ssr
Coupon de réduction formation "Qwik par la pratique" :
bit.ly/qwikpra...
Formations Front, Back et FullStack :
codeconcept.te...
Liens cités dans la vidéo :
qwik.builder.io/
www.solidjs.co...
Merci pour cette découverte et ton approche claire et motivante. Je pense que, comme d'hab, si l utiliser flingue le SEO du site, ce n est pas prêt d être adopté sur des projets d envergure et on attendra une version SEO-friendly.
Merci Scalblog :)
Bah niveau SEO, c'est du tout bon, comme tout ce qui utilise le SSR : les moteurs de recherchent voient le code HTML. On peut ajouter les meta / description / name / content etc que l'on veut. Et la vitesse de TTI devrait séduire les sites de e-commerce notamment.
C'est sans doute le plus gros défi de Qwik : faire son trou dans une niche puis gagner en popularité à partir de là ;)
Intéressant, en effet. Merci du partage argumenté ! 👍
Merci M.C. :)
Gros potentiel, probablement le prochain que je vais essayer.
C'est un plaisir à utiliser. Juste quelques bricoles qui seront prises en charge par le compiler un jour, j'espère, comme l'obligation d'entourer les event handlers de $(myFunction) ;)
Superbe vidéo. C'est vrai que ça fait du bien à la commu JS de voir que des créateurs de framework prennent exemples sur d'autres framework jugés "rivaux".
Mais dis tu n'as pas abordé rapidement Qwik City leur méta framework qui permet le fullstack avec les servers actions et autres...
Merci Tawaliou :)
En fait, quand on créé une appli Qwik, on créé sans le savoir une appli Qwik City quand on choisit de générer une application avec du routage. J'ai pu constater que dans routes/index du POC de la vidéo, il y avait un import depuis qwik-city :)
Je vais jouer avec les server actions et autres Form dans d'autres POCs ;)
@@codeconcept ok ok super. Une autre vidéo nous viendra alors 😎
Pour info, on peut faire du lazy loading En vanillajs Es6.
On peut en effet :)
L'originalité de Qwik, c'est que le lazy est très granulaire : il se fait au niveaux des closures. Autrement dit, au lieu de bénéficier d'un lazy loading basé sur des routes, c'est du lazy loading basé sur les event handlers.
Tout est est préfetché par un service worker qui met en cache les nombreux bundles de très petite taille. Lorsqu'un un event se produit (comme un click de bouton), le bundle est récupéré depuis le cache grace à un pointeur passé en valeur au "on:click=pointer". Cela permet au qwik loader d'associer le bon minuscule bundle au bon bouton, puis ce JS est exécuté.
A ma connaissance, Qwik est le seul framework grand public capable de faire du lazy loading au niveau d'une closure à ce jour (juin 2023). Google a bien un framework qui fait ça, mais il n'et pas accessible aux dev en dehors de Google ;)
0 jour depuis la sortie d'un nouveau framework js
C'est pas loin de la réalité :p
Ça me fait penser à Astro dans le genre
En effet : ça fait penser aux islands d'Astro :)
La différence entre Qwik et Astro, c'est qu'Astro repose exclusivement sur les Multiple Page Applications (MPA) là où Qwik essaie de gommer la séparation entre MPA et SPA grâce à la resumability.
Le public ciblé n'est pas le même : Qwik vise les grands comptes (de e-commerce notamment). Ca se voit du fait que lors d'une démo, Misko Hevery mesurait le TTI de tous les gros sites de e-commerce. Ca ne doit être par hasard. Là où Astro vise les applications web de petite et moyenne taille comme ils le disent eux-mêmes dans la doc : "Astro was designed for building content-rich websites. This includes most marketing sites, publishing sites, documentation sites, blogs, portfolios, and some ecommerce sites."
J'aime beaucoup Astro également ;)
Personnellement, tant qu'on sera toujours tributaire de langage interprété sur le client, on pourra toujours faire des framework de folie, pousser les serveurs plus loin en ressources, ça restera toujours archaïque...
Nous développons une solution Dynamics BC qui est depuis quelques années full web et l'expérience utilisateur a chutée drastiquement par rapport à notre vieille version d'il y a 20 ans.
Fonctionnement le produit est bon et s'enrichit à chaque release majeure mais le client léger (😄 & 🤬) est une plaie.
La dépendance au moteurs des navigateurs, même quand on s'appelle Microsoft est trop forte.
On a connu un Pb il y a quelques années avec la CRM (2013) et il y a quelques mois le moteur de rendu a pété les pages (checkbox ramassées).
Il a fallu quelques semaines pour que Google ajuste et en attendant galère et nécessite de passer à du Firefox (Edge Chromium ayant suivi le même chemin que Chrome quelque jours plus tard...)
A quand une vraie révolution ??
Pourquoi ne pas steamer la page dans le navigateur, garantissant ainsi l'indépendance réelle du client et éliminant ainsi des problèmes liés aux versions du client et un paquet de sécurité ?
Ça confirme ce que je dis régulièrement aux développeurs back : le front est bien plus galère avec les emmerdes spécifiques à différents navigateurs et pire encore versions de navigateurs. Ça doit être faisable de créer un navigateur qui embarquerait un moteur pour un langage compilé. Mais ça coûterait trop cher aux entreprises de réécrire leurs applications web. Se libérer du navigateur en programmant pour le des des appli embarquées avait marché un temps : c’était les beaux jours d’ActionScript. Tué par Apple si je me souviens bien. Quant à streamer vers les navigateurs, y a bien les web sockets. Et même Qwik qui permet de streamer vers des containers indépendants. Mais on est loin de ton idée 😉