Deno, ce n’est pas pour tout de suite…

Je vois beaucoup de jeunes développeurs se jeter sur Deno.

C’est vrai que c’est tentant, une nouvelle technologie apparaît, avec elle la promesse de gommer les erreurs de jeunesse de ses prédécesseurs…

Ça, c’est le discours marketing.

Je dois avouer que je trouve Deno assez intéressant.

Le projet a été lancé par le créateur de Node.js lui-même, je pense que Ryan Dahl est très bien placé pour poser les bases d’un nouveau projet de grande ampleur.

Le problème avec les nouvelles technologies, c’est toujours la vitesse d’adoption du marché.

Le délai minimum d’adoption

Il y a un toujours un délai minimum entre le buzz d’une technologie et son adoption par le marché.
La question qu’on est en droit de se poser : à quel moment doit-on investir du temps ?

Tu verras que la question n’est pas si vite “répondue”...

Tout dépend du type de projet dans lequel la technologie peut être utilisée.
Prenons l’exemple de Moment.js qui vient de passer en mode legacy.

Il n’aura plus de nouvelles fonctionnalités de développées sur le projet.
Une alternative très solide est date-fns.

Si le code est propre, changer cette dépendance ne devrait pas être très long.

Un développeur consciencieux aura pris le soin d’encapsuler la librairie afin de ne pas dépendre directement de la librairie.

Il y aura alors qu’un seul module à mettre à jour, les méthodes exposées par l’abstraction ne devraient pas changer…

Une libraire aussi “petite” se remplace en un laps de temps ultra court : on parle de quelques heures à une semaine de travail selon les projets.

Ici l’adoption du marché peut se faire en quelques semaines voir quelques mois.


Pour les plateformes c’est beaucoup plus long

Deno est un runtime réécrit de A à Z.
Il ne propose pas de compatibilité avec Node.js et c’est tant mieux !

Pas question de se trimbaler les défauts de Node.js…
Le problème est que pour passer à Deno, il faudra créer de nouveaux projets, faire face à des bugs inconnus, le tout en utilisant un outils peu documenté (Stack Overflow, blogs, etc).

Tu l’as bien compris même si Deno était prêt aujourd’hui, il faudrait attendre le démarrage d’un nouveau projet.
C’est ce délai moyen qu’il faut avoir en tête.

D’expérience, cela se fait sur 1 à 3 ans.
J’ai entendu parler de Flutter à la fin de l’année 2017.

Ma veille s’est limitée à quelques articles Medium et un parcours de la documentation.

Depuis le début, je suis fan du projet.

Pourtant ce n’est qu’à la fin de l’année 2020 que j’ai décidé de plonger plus sérieusement dans le projet.

Parce que je sais qu’être le premier sur Flutter n’est pas forcément un avantage pour moi.

Je préfère attendre de voir si le projet prend de l’ampleur (c’est le cas pour Flutter), si l’entreprise derrière à savoir Google croit au projet…

Google est réputé pour avoir le courage de stopper net des projets et ce peu importe la taille de la communauté.

Si Google ne croit pas à un projet, il le tuera dans l’oeuf sans hésiter.

Observer les facteurs clés d’adoption

Premièrement la gestion des versions.

Mis à part Facebook qui n’en a que faire, un suivi scrupuleux du Semantic Versioning permet de savoir si l’utilisation du projet en production est viable.

Deuxièmement, l’évolution de la communauté.

Attention, il ne suffit pas d’avoir 50K étoiles sur Github.
Je parle d’articles de blog, de vidéos tutoriel sur YouTube, de posts Reddit, de retours d’expériences de développeurs, de meetups…

Pour faire le lien avec Deno, à l’heure où j’écris ces lignes, on se contente de projets assez simples…

L’adoption de Node.js a pris un nouveau tournant quand on a fini par se rendre compte que la technologie était utilisée par les géants du Web : Paypal, Netflix et bien d’autres…

Troisièmement, les offres d’emploi

C’est bien beau d’être expert Deno en 2020, mais si personne ne t’embauche ça ne sert à rien.

En 2015, je me battais pour l’adoption de React au sein de mon équipe.
Très peu de collègues y croyaient, pour la plupart, c’était juste un framework Javascript de plus.

5 ans plus tard, React.js est le framework frontend le plus demandé sur le marché…

Je ne suis pas devin, j’ai investi sur une techno à laquelle je croyais, j’aurais pu me tromper comme ça a été le cas pour Meteor.js…


Ce qu’il faut retenir

C’est très important de faire de la veille technique.
C’est même selon moi indispensable.

Tu peux devenir un early adopter sur la technologie de ton choix.
Construire des projets complexes et en parler autour de toi.

Si tu es trop en avance et que trop peu de gens s’y intéressent, ne le prends pas personnellement.

Prends le recul nécessaire et ne sois pas frustré si tu ne trouves pas d’offres, c’est juste une question de timing.

A demain,

Captain Dev