Locomotive

Agence digitale

Le fun Retour au travail

Le fun

Retour aux articles

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

Dans la communauté web, on nous demande souvent pourquoi nous n’utilisons pas de framework front-end, car à Locomotive la grande majorité de nos sites sont bâtis sans... mais pourquoi ?

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.

Nous avons réalisé que nos outils internes et notre boilerplate front-end étaient puissants et correspondaient à beaucoup de nos besoins.

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.

Parfois dès le design ou l’UX, notre boilerplate nous permet de donner notre avis sur la faisabilité de certaines choses, puisque nous connaissons notre outil sur le bout des doigts.

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.

Retour aux articles
Pourquoi nous n’utilisons pas de frameworks front-end à Locomotive? Locomotive Scroll, le bon outil pour mon projet? C'est hot, 2ieme édition 500 jours plus tard, My Better Normal 6 piliers de la culture de travail chez Locomotive 7 façons d'améliorer la communication avec le client C'est hot, 1re édition 3 choses que votre concepteur UX peut apprendre de votre psy, style Locomotive Trois fois de suite, Locomotive est couronnée l'agence de l'année Locomotive prend d'assaut le stade IGA et remporte les honneurs au concours Idéa La révolution de l'espace de travail tel que nous le connaissons Puis-je te dire bravo? Locomotive couronnée Agence de l'année pour une deuxième année consécutive Analyse d'image et machine learning avec Google Vision API Réalité augmentée sur le web, wut? L’évolution du scroll chez Locomotive Revivez le Parté of the Year de Locomotive Les p'tits déjs Loco La zoothérapie au bureau Locomotive remporte le prix Agence de l'année Journée tempête et ski de fond Locomotive en mode avion Comment bâtir une équipe de rêve et la garder? Un bureau haut en couleurs saisonnières Les vendredis sous le soleil d'été Une équipe de rêve pour Locomotive
À propos de Locomotive À propos de Locomotive

Vous pouvez téléverser jusqu'à 3 fichiers (ZIP, PDF, DOC ou DOCX). Chaque fichier doit peser moins de 12 Mo.

C H O O C H O O