Retour d’expérience sur Quasar

Quasar est un meta-framework Vue.js. Il permet de faire facilement du SSR, et apporte toute une bibliothèque de composants pour développer une UI en Material Design.

Pourquoi avoir choisi Quasar

Nous avions pour les Geeking Days chez Slickteam le projet de création d’un site de recherche d’emploi. Des employeurs pourraient publier des offres d’emploi, renseigner les informations de leur entreprise, et des candidats pourraient envoyer leur CV en ligne, postuler à des offres…

Pour la partie front, nous étions partis sur du Vue.js : une technologie utilisée par plusieurs développeurs chez Slickteam, et que nous sommes plusieurs à connaître. Le site ayant besoin d’être indexable par les moteurs de recherche ou les réseaux sociaux, il nous fallait du pre-rendering ou du ServerSide Rendering (SSR). Des utilisateurs du site pouvant publier eux-mêmes du contenu, via les offres d’emploi, nous sommes plutôt partis sur le SSR.

Vue.js propose un module permettant d’ajouter du SSR sur son site, que l’on peut implémenter manuellement. On a déjà tenté, c’est compliqué… On s’orientait sur du NuxtJS, que l’on connaissait, mais qui n’était pas encore disponible avec Vue.js en version 3. A côté, Quasar proposait déjà l’intégration de la version 3 de Vue.js. Ne connaissant pas ce framework, on a décidé de tester. C’est aussi le but des Geeking Days !

Présentation de Quasar

Comme NuxtJS, Quasar permet de faire du Vue.js en SSR plus simplement, mais ce n’est pas tout. Il permet également de faire des PWA, des applications mobile avec Cordova, du multi plateforme via Electron, ou encore des extensions de navigateur.

Mais là où Quasar se démarque de Nuxt, c’est qu’il intègre directement une bibliothèque de composants, reposant sur du Material Design. L’inconvénient, c’est que le framework est prévu pour fonctionner avec sa librairie front. Il est sans doute possible de l’utiliser uniquement pour la partie SSR, et d’utiliser une tout autre librairie pour gérer la UI, mais ce n’est pas trivial.

Le positif

Comme dit précédemment, Quasar embarque une bibliothèque de composants plutôt complète, et qui répond à pas mal de besoins génériques.

Par exemple, pour l’inscription d’un utilisateur, nous avons un formulaire assez long, et il a été très simple de le diviser en plusieurs étapes via un Stepper . Dans ce même formulaire, on a un champ adresse avec une autocompletion faite via une API externe. Là encore, le composant Select de Quasar permet de faire ça assez simplement.

Par ailleurs, ces composants reprennent les règles du Material Design, ce qui permet d’avoir sans trop d’effort un design assez propre.

Pour l’expérience développeur, l’installation de Quasar se fait très simplement via une commande npm, et la plupart des outils sont préconfigurés automatiquement, des linters au live reloading. Il faudra juste modifier les configurations de lint à ses préférences personnelles (les tabulations, c’est la vie !)

Le négatif

Cependant, le fait que Quasar fasse un peu tout, fait qu’on est un peu obligé de s’en accommoder sur certains points…

Côté CSS, première chose qu’on fait quand on commence à développer l’interface du site : un layout général et de page… Et là… Il faut s’accrocher : Quasar propose un composant Layout qui en “facilite” la création. Cela permet de choisir si on veut un header et footer fixe ou non, des menus à gauche et à droite qui passent par-dessus les menu et footer ou pas… Tout ça dans une syntaxe à première vue obscure : on passe toute cette configuration dans un paramètre unique sous forme d’une chaine de caractère. Au final, pour avoir un menu en haut fixe, un footer qui apparait au scroll, un menu à gauche qui ne passe pas par-dessus le menu du haut ni le footer… La valeur de ce paramètre ressemble à ceci : “hHh Lpr fff”. Voila.

Par ailleurs, comme sur certains autres points, la doc n’est pas forcément très claire sur ce sujet.

A côté de ça, le framework peut sembler incomplet sur les classes CSS proposées : on n’a par exemple pas de classe permettant de faire un container responsive, et chaque classe css proposée par Quasar est préfixée par “q-”, ce qui est parfois un peu lourd.

Il aurait été sans doute préférable que l’installation de Quasar permette de choisir plus simplement son propre framework CSS comme le fait Nuxt par exemple.

Côté accessibilité, beaucoup de composants montrent de sérieuses lacunes, ce qui demanderait des efforts aux développeurs pour proposer une utilisation de leurs site via des lecteurs d’écran.

Enfin, en comparaison à du Nuxt ou du Vuetify, Quasar est bien moins utilisé, il sera donc potentiellement plus compliqué d’obtenir de l’aide en cas de difficultés à utiliser le framework.

Côté infra

Du côté de l’infra, pour une application intégrant le module de SSR, il s’agit de déployer une application Nodejs. Cela dit, quand on est habitué à du Nuxt, la procédure peut sembler un peu étrange : le build du projet en mode prod va générer un répertoire contenant son propre package.json avec uniquement les dépendances requises pour faire tourner le serveur. C’est ce dossier qui doit être déployé et qui contient le server.js à exécuter, et dans lequel il faudra au préalable faire le npm install.

Aussi, la gestion des variables d’environnement n’est pas nativement aussi bien faite que chez Nuxt, et il faudra avoir recourt à quelques “bidouilles” pour avoir une commande de build qui utilise des variables d’environnement, et un mode dev reposant sur des fichiers .env, pour facitliter l’expérience développeur.

Conclusion

Globalement nous somme mitigés dans l’équipe : si Quasar permet de faire du SSR assez facilement, le fait qu’il embarque en plus sa propre bibliothèque front complique un peu les choses, là où on était déjà habitués à d’autres librairies, là ou Nuxt propose plus de liberté.

Cependant, n’oublions tout de même pas qu’à ce jour, Nuxt ne propose toujours pas dans sa version stable l’utilisation de Vue.js en version 3, qui est sorti il y a plusieurs mois, contrairement à Quasar.