DotJS 2024: retours et impressions

Le 27 juin dernier se tenait la première conférence Dotjs depuis le Covid : pour celles et ceux qui ne les connaissent pas, les dot conférences sont une série de conférences annuelles nées en 2012 sur différents sujets/langages et mises sur pause pendant 4 ans après le Covid. Clairement, cette année, le mot d’ordre était de renforcer la communauté javascript autour de différents talks qui se tenaient aux Folies Bergères à Paris.

(moi, la dernière fois que j’étais aux Folies Bergères, c’était pour la tournée de de Drag Race France, donc autant vous dire que ce n’était pas la même ambiance…)

En préambule, en tant qu’ancienne organisatrice d’événements professionnels et plus particulièrement de conf, je tiens à saluer l’organisation globale : perso j’ai aimé le rythme des talks que j’ai trouvé vraiment bien pensé, avec une alternance de talks de 20’, de 5’ et des temps de discussion; le fait d’avoir un seul track de conf est aussi particulièrement appréciable et nous force finalement à suivre la journée et à vivre tous ensemble la même expérience de conf.

Mon objectif n’est pas de vous rendre compte des conférences unes à unes. Elles sont disponibles sur leur chaine Youtube et je vous invite à aller les regarder en entier. Cet article a juste pour objectif de relever sous forme de pensum-memento les éléments qui m’ont le plus marqués, qui m’ont fait réfléchir ou qui m’ont donné envie de creuser certains sujets. Pour tout vous dire, cet article est la transcription quasi littérale du résumé de ma journée à mon compagnon développeur (il pourrait donc s’intituler “fresh abstract from a tired but satisfied junior dev to a senior dev who no longer gives a shit about talks".)

💖 Mon talk préféré

Deux conférences m’ont conquise, ex aequo: celles de Ben Lesh et de Lea Verou.

I can do both : Ben Lesh et comment voir son code sous un nouveau jour

Le premier a introduit la conf et on ne va pas se mentir, c’était un peu corsé pour des novices. Merci pour la métaphore avec le M&M’s cependant, car ça a rendu le propos vraiment plus abordable pour des novices comme moi et je pense que c’est aussi à ça qu’on reconnait les bons talks. Tous les niveaux s’y retrouvent : ce n’est pas jargonnant donc on comprend la base et on peut repartir avec quelque chose, mais c’est aussi pointu techniquement et conceptuellement donc n’importe quel dev experimenté peut aussi en retirer quelque chose (sans être forcement d’accord).

Le propos de Ben partait d’un constat relativement simple : dans notre code, il y a des “consumers”, qui “pull”, et des “producers” qui “push”. Chaque ligne de code "push" ou "pull”. Le “consumer” reçoit la valeur. Par exemple dans :

const value = getValue();
console.log(value);

value et console.log sont les consumers, car ils reçoivent la valeur et appellent la fonction. Le producer ici c’est getValue() car c’est lui qui va apporter la valeur.

Problème : "pull" - donc consommer - est une action synchrone. L’avantage de "pull", c’est qu’il peut prendre les infos à son rythme. Mais si le producer n’a plus d’infos (par exemple, le sachet de M&Ms est fini, so sad), il devra attendre. "Push", au contraire, est synchrone OU asynchrone. Avantage : il peut aller construire toute une entreprise de M&M’s s’il n’en a plus, mais par contre s’il va trop vite, son consumer va subir une “back pressure” et, éventuellement, être surchargé.

La force du talk de Ben, c’était de nous faire comprendre tout ça de manière assez absolue, mais ensuite de prendre des cas concrets avec différentes fonctions (une boucle for, une promesse, etc.) pour montrer explicitement qu’est-ce qui "push" et qu’est-ce qui "pull". Il a exposé différents types de "pull" (une fonction, un itérable) et différents types de push (callback, promesses, observable) avec des cas moins simples à lire, comme dans les fonction async-await ou iterable.forEach((value) = < /*...*/>) (forEach "push", tout ce qui est entre "pull").

Fort de ces concepts, il est possible de relire du code sous cet angle pour voir quels sont les élèments qui produisent et quels sont les élèments qui consomment, mais surtout comment ils s’articulent entre eux. Les différentes articulations peuvent être à leur tour typologisées, ce qu’a fait Ben en insistant sur le fait aussi, qu’il n’y avait pas uniquement du push et uniquement du pull, mais qu’on pouvait “do both”.

J’en suis ressortie avec une nouvelle ressource pour lire du code et des concepts à creuser davantage, comme les signals et les observables que l’on a d’ailleurs retrouvés dans beaucoup d’autres talks durant la journée, comme par exemple celui de Ruby Jane Cabagnot.

Lea Verou : les développeurs ne sont-ils pas des users comme les autres ?

La conférence de Lea Verou portait sur un tout autre sujet - le design d’API - avec une hypothèse plutôt solide : le design d’API, c’est du design. Ça implique donc d’appliquer toutes les règles qui s’appliquent au design général d’une app pour des users particuliers, sauf qu’ici, les users - souvent - ce sont des dev. La dev experience n’est-elle au final pas simplement de l’user experience ? Les dev ne sont-ils pas au final des users, qui cherchent des outils faciles à utiliser, efficaces et compréhensibles ?

Par exemple, prenez l’API des SVG (quelle idée, mais pourquoi pas, allons-y) : pour obtenir le radius d’un objet cercle, il faut passer par trois objets différents, car toute la complexité des cas qu’on pourrait éventuellement peut-être croiser ou dont on pourrait avoir besoin est proposée… monolithiquement. BAM.

Pour Lea, cette API ne rentre pas dans le paradigme de design qu'elle défend :

les choses simples doivent être faciles, les choses difficiles doivent être possibles.

Cela implique de révéler la complexite d’une interface de manière progressive et de bien connaitre les cas d’usage de son API, pour savoir quelles sont les choses simples qui doivent être faciles à faire et les choses plus complexes, mais plus rares.

Je suis ressortie de cette conf avec, mis à part pas du tout l’envie d’utiliser l’api SVG, quelques tips utiles pour concevoir des api:

1. encapsuler la complexité (et une bonne façon de faire ça est de se reposer sur une hiérarchie de la complexité),
2. pas de boilerplate,
3. faire du layering,
4. tester (si on teste pour les users pourquoi ne pas tester pour les dev, qui sont a priori des users comme les autres :).

🥞 En vrac

Parmi les autres conférences de la journée, Minko Gechev a essayé de me convaincre qu’Angular et React se ressemblaient mais je n’en suis encore pas très sure (certes, Trump et moi sommes deux êtres humains, sommes-nous pareils pour autant…), James Quick et Jessica Sachs m’ont rejoint dans ma passion de l’histoire de JS me rendant toujours plus sûre que c’est important et en plus assez fun de comprendre d’où l’on vient pour savoir où l’on va. Même en voyant le projet d’Alex Moulineuf (Mario Kart en javascript...) pour la millième fois, je le trouve toujours aussi ouf et il réussit l’exercice de nous convaincre que travailler à plusieurs dev sur un même projet est un pari gagnant.

🔒 Privacy et responsabilités : There is no privacy in the software if we don’t build it

Le moment de la “big question” était un beau moment et j’ai particulièrement apprécié le fait que des speakers puissent avoir des avis divergents et partager la même scène, comme par exemple au sujet des passkeys : l’avenir de la sécurite pour Maud Nalpas, peut être pas pour Eleanor McHugh.

Cette dernière a démontré que l’on pouvait marquer les esprits même en 5 minutes : son engagement politique en faveur de la privacy et de la responsabilisation des dev sur ces sujets relève quasiment du service public. Le travail qu’elle abat a ce sujet est dantesque (comme l’a relevé James au sujet du metier de fullstack dev) et je vais en prendre connaissance avec beaucoup d’attention.

Son talk a aussi montré que, davantage que d’enseigner beaucoup de choses, une bonne conférence redirige surtout vers les ressource pertinentes pour continuer d’apprendre, de découvrir et de s’améliorer. Moins qu'une série d'assertions, les bons talks sont des tremplins.