Pas de TypeScript à lemlist.
Et j’ai passé plus de 10 ans à coder en C++, je n’ai pas peur des types.
Mais notre priorité chez lemlist, c’est simple :
livrer de la valeur rapidement à nos utilisateurs.
Et TypeScript ne nous aide pas à le faire.
Est-ce que TS permet de détecter des erreurs à la compilation ?
Oui.
Mais dans notre expérience, ça couvre quoi ? 1 à 2 % des bugs.
Le reste, ce sont :
– des bugs métier,
– des problèmes d’intégration,
– des effets de bord non couverts par le typage.
Et pendant ce temps-là…
On passe des heures à écrire, maintenir et refactorer des types.
TypeScript est un bon outil, dans le bon contexte :
– pour des juniors à encadrer,
– pour des projets énormes,
– pour de la banque ou de la santé, où le bug coûte très cher.
Mais dans une équipe de devs confirmés, alignés, qui bossent avec des conventions claires et des revues de code solides…
JS pur est plus rapide, plus souple, plus efficace.
Je préfère un code utile à un code “beau”.
Développeur IA | Développeur Full Stack | ISV Succès | Spécialiste DevOps
2 months ago
Mika F En un besoin a haut niveau est considéré afin de contrôler le type .Mais parfois ,les erreurs lint sont liées uniquement au TS , le JS est compilé .On peut liee des facteurs ,A savoir les fichiers (.ts.config ,.eslint.rc,…) ,La chaine des versions du bibliotheques (stable ,preview or early access ). Cepandant ,Typescript garde le controle du type au niveau du compilation d’une facon hiérarchique .Ce qui la caractérise d’autres langues de programmation.
Là où il faut être pragmatique c'est si ton client achète du temps ou s'il achète une intelligence métier.
Dans le premier tu vas avoir besoin de «ship fast, fail fast» sinon tu te fais éjecter par un autre concurrent qui n'aura pas en barrière d'entrée sur le marché la problématique métier, qui aura plus de moyen financier, humain et matériel. Le coût de résolution de bug idiot comme oublier de renommer une variable après une refactorisation est plus faible que celui d'attendre qu'un autre concurrent sorte la même fonctionnalité plus vite. Dans ce cas là pas question d'utiliser TypeScript.
Dans l'autre c'est le métier qui est clairement identifié et que tu maîtrise via un ou plusieurs homme (avec un grand H) clé qui sécurisent la compétence et que les clients viennent acheter, une expertise dans le domaine qui est difficilement reproductible par la concurrence et qui créé la barrière à l'entrée du marché. Dans ce cas là hors de question d'utiliser un langage qui peut amener un humain à faire des erreurs, TypeScript (ou un autre langage typé comme Java) est à privilégier.
Le rôle du CTO sera d'utiliser les meilleurs outils au bon moment, il n'y en a pas un qui fait tout mieux.
« Dans une équipe de dev confirmés » , j’ai l’impression qu’il n’y a plus de dev junior nulle part. Je trouve ça bizarre et inquiétant au niveau macro.