Gaëtan nous parle des bibliothèques d’interface utilisateur (UI Libraries) pour ses applications et pourquoi il a cessé de les recommander systématiquement. Bonne lecture ! 
 
 

Depuis que je suis développeur front-end, j’ai toujours utilisé des bibliothèques d’interface utilisateur. 
Selon moi, elles sont géniales, faciles à utiliser et très utiles. Plus de composants de bas niveau, plus de responsive design à faire (ou beaucoup moins). Parfait ! 
 
Mais depuis quelques temps, j’ai tendance à moins les utiliser qu’auparavant… 
 
 

Nous voyons beaucoup d’articles passés sur le bon côté des UI Libraries mais beaucoup moins sur leurs mauvais côtés. C’est pourquoi j’ai décidé de vous partager mon expérience. 

Parfaites pour les applications internes, beaucoup moins pour les applications publiques 

Lorsque vous travaillez sur une application interne, vous ne vous souciez pas vraiment du design (enfin si, mais pas autant). Vous voulez quelque chose qui fonctionne rapidement, et c’est tout.
 
Il y a une préoccupation sur l’UX/UI, mais pour la plupart, ces questions sont résolues avec l’UI Library que vous utiliserez. 
La plupart de ces bibliothèques d’interface utilisateur sont des sources ouvertes, et une communauté massive y contribue.

En travaillant sur une application publique, les choses sont totalement différentes. Vous devez être unique. Il faut être différent. Si votre application ressemble à une autre, vous ne marquez aucun point. Un autre Bootstrap ? Ennuyeux ! Un autre Material ? Ennuyeux aussi !

La plupart du temps, vous vous appuierez sur un système de conception. Et vous aurez besoin de tordre les librairies d’interface utilisateur pour les adapter à vos besoins.
 
Cela ne fonctionnera probablement pas toujours, vous devrez remplacer un style qui entre en conflit avec d’autres de la bibliothèque d’interface utilisateur (lorsque c’est possible). Un vrai cauchemar.

Les UI Libraries, une plaie lors des mises à jour des versions majeures des frameworks

Ce problème est un peu plus personnel, car il est peut-être lié à l’écosystème Vue avec lequel je travaille depuis plusieurs années maintenant. Mais il est important pour moi de le partager car il a vraiment perturbé les différents projets que nous avons essayé de mettre à jour. 

Ces kits d’interface utilisateur sont profondément liés à votre framework principal. Ils s’appuient sur un cycle de vie spécifique, des crochets spécifiques, des composants spécifiques.
Et en faisant cela, vous liez votre application à une version spécifique du framework.

Je me souviens de l’époque où nous avons essayé de passer de Vue 2 à Vue 3. C’était un véritable calvaire. En fait, dans presque la moitié des projets que nous avons essayé de mettre à niveau, nous avons dû abandonner la bibliothèque d’interface utilisateur et repartir de zéro.

Pourquoi ? Parce qu’il ne s’agissait pas d’un changement en douceur. Il s’agissait de changements massifs, avec des modifications fondamentales. Et si le passage de Vue 2 à Vue 3 est relativement facile, le passage de la bibliothèque d’interface utilisateur que nous utilisions (Vuetify) a été un véritable cauchemar : 

• Les composants ne fonctionnent pas toujours (ou seulement sur quelques appareils) ; 
• Les composants n’existent plus ;
• Certains composants n’ont pas été portés au moment de la sortie de la version ;
• Manque de documentation (et la documentation est la raison pour laquelle j’ai commencé à utiliser Vuetify, elle était très complète) ;
• La signature des composants change, ce qui nécessite une réécriture complète.

Si votre application est massive, tous ces défauts entraînent des retards considérables dans les délais. 
Parfois, le gel de la feuille de route du projet pour ce type de raisons est beaucoup trop important pour que l’entreprise l’accepte.

Vous oubliez comment les choses fonctionnent en mode natif…

C’est quelque chose que j’ai remarqué lorsque j’ai commencé à travailler sans UI Kits. Toujours en train de se demander : « Mais comment dois-je faire ça ? Cela va être pénible ». Même pour des choses triviales : les scrolls, les animations, les événements… en utilisant ces kits d’interface utilisateur, vous ne prêtez pas attention aux nouvelles versions du noyau.

Vous oubliez comment les choses fonctionnent. Vous oubliez comment faire un design réactif. Vous oubliez comment gérer le défilement, les animations et les transitions… 

Ce schéma d’abstraction est génial car il stimule la productivité. Mais le piège réside dans le fait que lorsque quelque chose ne fonctionne pas, vous n’êtes pas en mesure de le réparer de vos propres mains… Vous aurez besoin d’un « dirty fix/hack » pour le faire fonctionner (quand vous pouvez le faire fonctionner). 

Vous devez savoir comment les choses fonctionnent pour améliorer vos compétences.

Pour conclure

Je ne dirai pas que les bibliothèques d’interface utilisateur sont une mauvaise chose. Elles vous permettent de démarrer votre projet rapidement, de vous concentrer sur la productivité. C’est vraiment génial, surtout pour les projets internes.

Mais les inconvénients peuvent vous coûter cher, surtout dans un écosystème qui évolue rapidement comme notre écosystème JS. Cela peut vraiment ralentir votre livraison, et même geler votre application.

Réfléchissez à votre choix, et arrêtez d’utiliser une bibliothèque d’interface utilisateur pour chaque projet comme solution par défaut. Prenez le temps d’écrire du code. Prenez le temps de comprendre les comportements. Cela peut sembler une perte de temps, mais au bout du compte, vous gagnerez beaucoup de temps lors de la mise à jour des versions de vos projets (et vous améliorerez aussi vos compétences) !

– 

Crédits : Gaëtan Wichlacz