Le blog

DotJS 2024 : les retrouvailles

Publié le 01 juillet 2024

Après une pause de près de 5 ans, nous avons eu la chance ce jeudi 27 juin d’assister au grand retour d’un événement marquant de la communauté Javascript que nous affectionnons : la DotJS. Pour ne rien gâcher, cette édition 2024 se tenait dans un cadre magnifique : les Folies Bergère, au cœur de Paris, où notre coopérative tenait un stand en tant que partenaire Silver.

Retour sur cet événement prestigieux très attendu par nos devs front, et petit aperçu des conférences et des lightning talks qui nous ont marqués.

#

Thinking About Your Code: Push vs Pull par Ben Lesh

Dans ce talk, Ben a présenté une perspective originale sur notre code avec le modèle "consommateur / producteur", en abordant les concepts de "push" et "pull", illustrés par une démonstration en live avec des M&M’s.

Il a expliqué les avantages et inconvénients de chaque approche :

  • Pull : fonctions ou itérables, toujours synchrones. Inconvénient : le consommateur appelle parfois inutilement le producteur.
  • Push : callbacks, promesses, observables, synchrones ou asynchrones. Inconvénient : "backpressure", où le producteur envoie plus que ce que le consommateur peut traiter.
  • Pull-Push : données récupérées uniquement si le consommateur est prêt à les recevoir.
  • Push-Pull : signaux, qui gèrent nativement la "backpressure".
#

Dante’s Inferno of Fullstack Development par James Q. Quick

James nous a expliqué que démarrer un nouveau projet web aujourd'hui ressemble à une traversée des neuf cercles de l’enfer de Dante. Avec l’abondance de nouveaux frameworks toujours “plus rapides, plus performants, plus légers” et les innombrables “meilleures pratiques” à adopter, il est facile de s'y perdre dans cet écosystème qui semble souvent tourner en boucle.

Pour appuyer son propos, James a retracé brièvement l’histoire de JavaScript, puis énuméré les différentes “meilleures pratiques” appliquées au fil du temps, en mettant en lumière les avantages et inconvénients de chaque approche :

  • Site en HTML + JS via CDN
  • Sites en SSR (Server Side Rendering)
  • SPA (Single Page Applications)
  • Sites statiques
  • Sites en ISR (Incremental Static Regeneration)
  • Server components

James a conclu son talk en observant qu’en termes d’avantages et d’inconvénients, les server components sont finalement très similaires au SSR. Serions-nous en train de tourner en rond une fois de plus ?

#

What to test in your web app par Jessica Sachs

Dans ce talk, Jessica nous a fait voyager dans le temps, en commençant par l’époque où tester se résumait à affirmer “ça marche sur ma machine”.
Elle nous a ensuite remémoré la première et deuxième guerre des navigateurs, et a évoqué des souvenirs douloureux que beaucoup auraient préféré oublier, comme l'époque où tous les sites devaient être compatibles avec Internet Explorer 5.5. 

Elle nous a également fait découvrir ou re-découvrir d’anciens outils aux noms originaux, tels que "script.aculo.us" et "Testacular", et a souligné l’influence croissante des innovations technologiques dans les outils de testing.

A la fin de ce voyage à travers les âges, elle nous a rappelé que les tests manuels pouvaient encore suffire sur certains projets, et que même si certains frameworks ou technologies récentes sont actuellement peu adaptés aux tests, ils le seront sans doute très bientôt donc soyons patients !

#

Converging Web Frameworks par Minko Gechev

Minko a débuté ce talk en mettant en avant les similitudes entre React et Angular : pour lui, ce sont basiquement le même framework.

Comme plusieurs intervenants avant lui, il a ensuite évoqué l’émergence des signaux pour gérer la réactivité des applications, notant qu’Angular les a déjà adoptés. Il a finalement partagé un exemple concret de convergence entre deux frameworks, en expliquant le cas d’Angular et Wiz. En les combinant, Google a réussi à combiner l'interactivité d'Angular et la résolution des problèmes de latence de Wiz. Cette convergence a significativement amélioré les performances de YouTube, entre autres.

Minko a finalement conclu son talk en rappelant que les principaux critères du choix d’un framework devaient être sa stabilité, la robustesse de sa communauté et l’expérience utilisateur qu’il offre.

#

API design is UI design par Lea Verou

Qui n’a jamais souffert en utilisant une API ? Comment faire pour que la vôtre ne provoque pas des maux de tête à vos utilisateurs ? C’est ce qu’a essayé de nous apprendre Léa durant ce talk faisant le parallèle entre conception d’interface utilisateur et conception d’API, et entre l’UX (expérience utilisateur) et la DX (expérience développeur).

Lea Verou sur la scène de la DotJS" class="wp-image-9410" style="aspect-ratio:3/2;object-fit:cover

En illustrant son propos avec des exemples concrets d'APIs courantes et souvent complexes (comme la manipulation des propriétés SVG ou la personnalisation de la barre de contrôle des balises vidéo), Léa a partagé plusieurs conseils essentiels :

  • Les fonctionnalités simples doivent être faciles à implémenter, les fonctionnalités complexes doivent être réalisables.
  • L'effort requis pour utiliser notre API doit être proportionnel à la complexité du résultat attendu.
  • La complexité de l'API doit être introduite de manière progressive.
  • Nous devons baser la conception de notre API sur des cas d'utilisation réels et la faire tester par de vrais utilisateurs.
  • La syntaxe doit rester simple et intuitive
    (exemple très concret de la méthode JS pour supprimer un objet, avant ES6 : parent.removeChild(element), après ES6 : element.remove())
  • Si l’utilisateur fait des erreurs, ce n’est pas lui le responsable, c’est notre API qui n’est pas assez explicite. Nous devons faire preuve d’empathie envers nos utilisateurs.
#

Remixing the bundler par Mark Dalgleish

En nous présentant Remix et sa transformation en un plugin Vite, Mark est revenu sur la fine barrière entre les bibliothèques et les frameworks JavaScript. En prenant pour exemple Remix, qui est basé sur React Router, il a retracé le cheminement qui a transformé cet outil en plugin Vite. Dans un premier temps, le choix a été fait de passer d'esBuild à Vite, bien que ce dernier soit de base plutôt adapté aux frameworks.

Le fichier remix.config se transforme en vite.config et il suffit de lancer vite dev pour le développement : viite build && vite build-ssr

La grosse limitation de ce modèle était les deux builds différents. Que ce soit à cause de la communication entre les builds, l’ordre dans lequel les lancer, ils avaient besoin de plus de contrôle.

Grâce à la sortie de la nouvelle version de l’API Vite et le concept d’orchestration de builds, le soucis est résolu. Remix est stable depuis février et il est maintenant possible d’avoir une gestion des builds très précise et configurable tout en ayant une seule commande à lancer : remix vite:dev remix vite:build

Il conclura en expliquant que Remix et React Router vont être amenés à fusionner. Malgré cela, cet outil ne deviendra pas un framework, mais restera une bibliothèque tout en étant un plugin Vite. Il citera certains avantages, comme la possibilité de s’appuyer sur la communauté Vite, la simplicité d’utilisation et d’apprentissage, ainsi que la maintenabilité.

#

Generative UI: Bring your React Components to AI today! Malte Ubl

Le CTO de Vercel est revenu sur l'utilisation des "prompts" avec les IA, principalement textuels actuellement, en illustrant un exemple pour un site de réservation de vols. Si un utilisateur demande à changer de place pour une place côté fenêtre, la réponse de l'IA est purement textuelle, énumérant les sièges disponibles, ce qui n'est pas très convivial pour l'utilisateur.

Cependant, l'équipe de Vercel travaille sur des prompts plus interactifs. Ils imaginent un composant React représentant le plan de l'avion avec les sièges disponibles, mettant en avant les places côté fenêtre et suggérant une place particulière. En React, un composant est une fonction, tout comme un prompt, ce qui permettrait de créer des composants auto-générés par les prompts.

Malte s'est tenu rassurant auprès de celles et ceux qui craignent que l'IA ne remplace les développeurs, en soulignant que les devs front-end seront toujours nécessaires pour développer les interfaces de ces nouveaux outils.

#

Les lightning talks

En plus des conférences au format “classique” de 20 minutes, cette édition 2024 de la dotJS proposait également tout au long de la journée des conférences de 5 minutes, au format beaucoup plus court mais au contenu tout aussi intéressant. Voici ceux qui ont retenu notre attention :

#
Embracing Reactivity: Signals unveiled in Modern Web Frameworks par Ruby Jane Cabagnot

Ruby Jane a évoqué les défis liés à la gestion de l'état d'une application. Après un bref historique des différentes méthodes traditionnelles de gestion de la réactivité (Knockout.js, AngularJS avec son double data binding, et React avec son DOM virtuel), elle a présenté les frameworks plus modernes utilisant les signaux : SolidJS, Svelte, et Vue.js. Elle a ensuite listé les avantages des signaux, notamment en termes de performance, simplicité, efficacité, et leur capacité à permettre de se concentrer uniquement sur la logique métier de l'application. En résumé, selon Ruby Jane, "les signaux, c’est super, utilisez-les !"

#
Mario Kart 3.js: pushing the limits of JS together par Alex Moulinneuf

Dans ce talk inspirant, Alex nous a parlé de son incroyable projet : un Mario Kart en JS. Il a expliqué comment il a partagé publiquement et quotidiennement l'évolution du projet, et comment celui-ci est devenu viral grâce au soutien de grandes figures de l'écosystème JS. Il a également souligné l'importance de l'aide de la communauté, qui a permis au projet de se développer et de s'améliorer. Pour conclure, il nous a tous vivement encouragés à partager nos idées, et à nous lancer dans l’open source.

#
Your app crashes my browser par Stoyan Stefanov

Lors de ce lightning talk, Stoyan a abordé un problème courant en JavaScript : les fuites de mémoire. Il nous a présenté Memlab, son outil open-source de détection de fuites de mémoire, ainsi que l'extension Chrome associée, Memlab Scenario Recorder.

Il nous a également rappelé quelques exemples classiques de fuites de mémoire, comme les variables globales et l'oubli de suppression d’écouteurs d'événements. Stoyan a conclu en soulignant qu'il est bien plus difficile de détecter l'origine d'une fuite de mémoire que de la corriger.

#
Encrypt all transports par Eleanor McHugh

Plutôt que de simplement nous fournir des techniques de cryptage de données, Eleanor utilise les 5 minutes de ce talk pour souligner l'importance cruciale de la vie privée et de la protection de nos données. Elle insiste sur le fait que nous ne pouvons pas faire aveuglément confiance à une application dont nous ne maîtrisons pas le développement, en termes de respect de la vie privée.

#

Conclusion

C'est assez rare pour notre équipe de participer en masse à des événements spécialisés JavaScript dans l'Hexagone. Alors, dès que nous avons appris que l'événement était de retour, nous nous sommes rués sur la billetterie ! Ces retrouvailles dans ce lieu haut de gamme à l'architecture art déco nous ont plus que ravis. Nous avons apprécié l'ambiance sur place ainsi que les animations communautaires, notamment le jeu de 7 familles qui nous a permis de rencontrer et sympathiser avec les participants. Si nous devions donner quelques axes d'amélioration pour la prochaine édition prévue le 3 avril 2025, ce serait peut-être de prêter attention à la redondance de certains sujets, ou à ceux un peu (trop ?) orienté marketing.

Côté sponsor, nous avons été ravis de (re)voir quelques visages familiers, de présenter nos services et nos offres d'emploi à pourvoir en JavaScript. Encore un grand bravo et merci à Nessrine et Anne-Sophie pour l'organisation de cet événement. À l'année prochaine !

Le blog

Pour aller plus loin