Mathieu Barberot

Bonjour Benoît,

Très intéressant, comme toujours ;-)
Mais il y a une question que je me posais tout de même : quand tu as abordé l'intérêt d'utiliser le design system de Welcome to the Jungle, les invités ont indiqués qu'il y en avait des bien plus personnalisables déjà sur le marché, pourquoi alors en avoir développé un maison ?

Je me suis dit que ça pouvait peut-être permettre de ne pas se reposer sur un projet qui pourrait faire des breaking change trop souvent et ainsi permettre de migrer les sites de l'entreprise en douceur, mais non, ils nous indiquent en être à la 5e versions majeure en l'espace de 3 ans (si j'ai bien suivi), de migrations compliquées et d'un refactoring en mode "hardcore" de 6 mois !

Est-ce qu'il y a un bénéfice caché qu'ils n'ont pas mentionné et que je n'arrive pas à voir ?

Je pense qu'ils ont démarré la démarche avant que ça ne devienne mainstream.
Un peu comme ces éditeurs qui ont un framework maison : ils l'ont souvent fait avant que des projets matures émergent.

Sur le sujet du changement dans le marché de l'emploi, je ne saurais pas dire actuellement, mais il y a presque 2 ans c'était pas gagné quand on sortait des clous du temps plein sur site.

Je recherchais alors un 80% et 2j de télétravail par semaine et ça mettait fin assez facilement au process de recrutement !

D'un côté, chez les grandes entreprises, j'avais un discours du genre "2j de télétravail pour 3j sur site", donc impossible d'avoir le 2e jours si tu es en 80%. Sans compter que c'était bien souvent impensable d'être en télétravail pendant la période d'essai.

De l'autre, chez les ESN qui font de la régie, c'était généralement "nos clients veulent des ressources à 100%, ce sera trop dur de vous placer".

J'ai finalement trouvé un poste avec mes critères en quelques mois.
Avoir le marché de l'emploi de son côté est vraiment une énorme chance.

J'ai bien aimé cet épisode.
Nous avions essayé d'en s'en approcher avec un archi hexagonale + du DDD dans une de mes précédentes expériences et il y avait eu pas mal de réticences ou de frustration face à la verbosité du code lié aux différentes interfaces qui permettent d'abstraire les couches externes. J'avais alors eu pas mal de questions similaires à celles de Benoit. Hélas, je n'avais pas l'expérience de Nicolas pour y répondre.

Avec le recul, je pense que c'était un changement vraiment trop important et il aurait sûrement été plus avisé d'y aller incrémentalement. Ne serait-ce déjà que commencer par initier l'équipe à la notion de couplage du code et de son rapport gain/risque pour mieux comprendre l'intérêt des concepts qu'on applique ensuite.

Hello,

Merci à Élise pour son retour sur Vue.js.

Je suis entièrement d'accord avec elle sur la prise en main vraiment aisée de Vue.js. J'ai eu plusieurs fois l'occasion d'accompagner des devs backends à passer à Vue.js et effectivement, la montée en compétence s'est généralement bien passée, très graduelle et en découvrant au fur et à mesure toutes les fonctionnalités ES6.
Sans compter que depuis l'arrivée du Vue CLI, l'outil de ligne de commande, la gestion de la chaîne d'outillage sous-jacente est grandement simplifiée.

En revanche, bien que je n’aie pas encore essayé la version 3, je suis un peu inquiet entre l’image donnée par Benoît de Python 2 vs 3 sur l’écosystème, et l’impression qu’il repose beaucoup plus qu’avant sur une bonne connaissance de JS/ES laissant de côté la simplicité qui à fait son adoption, mais j’espère me tromper :)

Par contre, mon retour sur l’utilisation de Vue.js en entreprise est mitigé. Pour avoir travaillé sur plusieurs applications, j'ai pu constater que la vélocité baisse très vite dès que l'application commence à se complexifier.

Je pense que ça vient d’une part que Vue.js ne se suffit pas à lui-même. On se retrouve vite à ajouter une couche de gestion des données, généralement la combo Axios pour les appels REST et Vuex pour la gestion des données. Et puis on a plusieurs pages, alors on ajoute un routeur, généralement Vue Routeur. Cette liberté d'ajouter des briques au fur et à mesure du besoin, ça m'a surtout donné l'impression de réinventer la roue en me fabriquant un framework maison.

D’autre part, Vue.js ne propose aucune architecture pour le projet. On a quelques bonnes pratiques qui ont émergées comme le Props Down Events Up(1) et appliquer le bon vieux SRP pour éviter que ça parte trop en plat de spaghettis, mais c'est tout.
Du coup, on a dû expérimenter pour trouver nos propres conventions :
- un package "ui" avec les composants de base réutilisables
- des packages métier avec les composants qui font des traitements et le lien avec le store
- un package "page" pour les composants qui représentent les pages
- un package "store" pour le traitement des données
- un package "api" pour ne pas avoir du Axios partout dans le code
Tout ça consommant du temps et de l'énergie qui auraient pu être utilisés pour du développement de fonctionnalité.

Au final, j'ai du mal à voir l'avantage de cette approche sur les frameworks tel qu'Angular ou Ember.js.

Donc pour répondre à la question initiale du podcast : pour moi, oui, Vue.js est un jouet. Tout comme React d'ailleurs.
Les libs de composant, c’est parfait pour une démo ou un widget météo, mais pour faire une app, c'est vraiment insuffisant. Mon regard se porte maintenant sur les frameworks qui se construisent par dessus ces libs. Élise en a mentionné quelques-uns pour Vue.js : Nuxt et Quasar, qui me semblent également être les plus prometteurs.

(1) jasonformat.com/...

EDIT: reformulations

Hello Mathieu. Yeps, sur le sujet de la complexité pour des applications d'entreprise, je trouve que Nuxt et se conventions adressent plutôt bien ces problématiques.

Pour aller un peu plus loin, je trouve que les webcomponents ont pas mal de potentiel. Ils peuvent être écrits en vanilla js , avec vuejs ou autre. Puis être intégrés avec d'autres frameworks.
Un bon exemple chez Clever Cloud : www.clever-cloud.com/...

Hubert Sablonnière en parle par ici : www.youtube.com/...

Super épisode, on entend pas assez parler des tests dans le monde du frontend, même si personnellement, je ne suis pas un grand fan des snapshots.

Voir les snapshots passer régulièrement au rouge et devoir les ré-accepter est quand même assez pénible et à la longue ça m'a poussé à les accepter sans me poser de question, ce qui ne me convenait pas.

Au final, j'utilise l'approche des "test selectors" que j'ai découvert avec Ember.js (si vous en avez marre de réinventer la roue et de faire de la plomberie avec React/Vue, allez jeter un coup d'oeil). J'apprécie cette méthode car elle se repose uniquement sur le fait qu'un élément ciblé de manière unique est bien présent, quelque soit son emplacement dans le DOM et ça me permet de refactorer des composants sans que le test passe au rouge.

Quelques ressources sur les tests selectors :
simplabs.com/...
docs.cypress.io/...
testing-library.com/...