Pourquoi nous n’utilisons pas de frameworks front-end à Locomotive?

Un framework front-end est une boîte à outils qui possède une certaine structure, des fichiers et des dossiers déjà organisés avec un certain nombre d’outils qui facilitent beaucoup le développement front-end, notamment pour la gestion des composants, des transitions et des routes. Plusieurs frameworks front-end sont très utilisés, comme VueJS, ReactJS ou encore Angular — chacuns étant différents et adaptables aux besoins de tous les développeurs. 

Chez Locomotive, notre boilerplate front-end (projet vide prêt à être commencé) est comme un “mini framework”. Comme il a été bâti en interne, il est adapté aux besoins d’une petite équipe et à un contexte plus restreint et ciblé. Effectivement, les développeurs front-end ayant tous des projets (clients) en cours, les évolutions de notre boilerplate ne peuvent pas se faire rapidement.

Quelques projets avec ReactJS et VueJS

Dans les 5 dernières années, nous avons eu quelques projets qui se prêtaient vraiment à l’utilisation de framework front-end. À l’époque, ReactJS était bien à la mode, alors quand nous avions compris que nous allions développer une application web, c’était un choix qui faisait du sens. 

Pour vous en dire plus sur nos expériences avec des framework front-end: nous avons utilisé ReactJS pour l’application web de Report.Cards et principalement pour notre solution citoyenne Agora. Dernièrement, nous devions travailler avec VueJS (Nuxt) pour développer le site Fontshare.com. Ces projets étaient plus du type “application”, avec beaucoup de composants possédant chacun des variations avec beaucoup de données à gérer. Un autre aspect important de ce type de projets est le changement dynamique de données, les routes front-end, la paramétrisation par API, etc. Toutes ces contraintes rendent donc ce type de framework un choix technique très intéressant.

Beaucoup de concepts ont dû être réappropriés: Comment gérer les vues, les composants, le CSS, les routes et la gestion de données. Comme les besoins techniques des projets étaient en phase avec un framework de ce type, le développement s’est très bien déroulé. Au fur et à mesure d’utiliser React et Vue, nous avons réalisé que nos outils internes et notre boilerplate front-end étaient puissants et correspondaient à beaucoup de nos besoins.

Travailler sans framework ?

Depuis les 6 dernières années, notre boilerplate front-end a beaucoup évolué selon nos besoins, nos habitudes et les envies de chacun. 

Vous savez, c’est un peu comme cette vieille paire de chaussures que vous mettez tout le temps; elles ne sont peut-être pas neuves, ne sont pas les plus belles, elles n’iront pas aussi bien à tout le monde, mais vous êtes tellement bien dedans et avez l’impression de pouvoir faire le tour du monde avec, que c’est compliqué pour vous de vous en séparer. Ça reste une technologie, donc nous gardons l’esprit ouvert aux changements en étant les premiers à reconnaître nos limites, parfois dès le design ou l’UX en donnant notre avis sur la faisabilité de certaines choses, puisque nous connaissons notre outil sur le bout des doigts. 

Alors, que nous réserve l'avenir? Selon moi, nous devons continuer de faire évoluer notre boilerplate pour suivre les nouveautés en terme de performance et d’accessibilité, mais est-ce que l’on a vraiment besoin d’une grande boîte à outils faite pour plaire à tout le monde alors que nous avons fabriqué la nôtre qui fonctionne pour nous, avec simplement les outils dont nous avons besoin? Sans doute que non, mais gardons en tête que la technologie dépend du projet et de son cahier des charges. Les technologies évoluent tellement vite qu’il faut rester à l’affût et garder l’esprit ouvert à l’utilisation d’un framework front-end.