Dot JS 2017 — Compte Rendu

Vendredi 1er Décembre 2017 se tenait la cinquième édition de Dot JS au Dock Pullman de la Plaine Saint-Denis, l’occasion pour une partie de l’équipe Front-End de MeilleursAgents de venir assister aux différentes conférences afin de découvrir les dernières tendances en termes de développement JavaScript mais également pour échanger avec les acteurs de l’écosystème puisque pas moins de 1 400 personnes issues de 37 nationalités différentes participaient à l’évènement.

Cette édition fut animée par Christophe Porteneuve, qu’on ne présente désormais plus et qui pour l’occasion s’est mis sur son 31 afin de présenter dans un anglais irréprochable les nombreux speakers, qui avaient un temps imparti de 18 minutes pour effectuer leurs talks et étaient ensuite conviés à poursuivre une discussion d’une dizaine de minutes avec Christophe autour de diverses sujets liés à leur actualité.

Il y avait également plusieurs lightning talks de 4 minutes entre ces différentes sessions de talks.


Async/Await par Wes Bos

Wes Bos a ouvert le bal avec un talk énergique pour réveiller l’audience en nous présentant les nouveautés apportées par Async/Await afin d’écrire du code asynchrone de façon synchrone.

Il en a profité pour nous rappeler comment nous sommes passés de la callback hell aux Promises afin d’introduire les changements apportés par Async/Await.

Async/Await étant construit sur les promesses, ces dernières permettent d’attendre la résolution de promesses et ainsi d’écrire du code asynchrone de façon plus élégante en évitant d’utiliser le then spécifique aux promesses. Combiné à la gestion d’erreur à travers l’utilisation d’un try/catch et d’high order functions, Async/Await s’avère être la meilleure option pour gérer du code asynchrone en JS !

Si vous souhaitez en apprendre davantage sur le sujet, vous pouvez consulter les slides de ce talk à l’adresse suivante: 
ASYNC + AWAIT / I PROMISE YOU’LL LIKE THIS TALK

Le futur des tests web par Trent Willis

Trent Willis, UI Engineer Senior chez Netflix et porteur du projet QUnit, nous a exposé sa vision des tests pour le web et quels outils utiliser en 2017 pour accomplir cette mission.

Selon lui, une application web qui fonctionne correctement doit être:
- Accessible
- Performante
- Nécessaire

Afin de tester ces différents points, Trent nous a recommandé différentes solutions tel que Chrome Headless qui est apparu lors de la sortie de la version 59 de Chrome et qui permet de parcourir une page web grâce à la librairie Puppeteer. Il en va de même pour QUnit-In-Browser, un plugin de QUnit qu’il a développé.

Cependant, ces solutions ne pouvant tourner que dans Chrome, l’usage de cette librairie n’est pas adapté à certains projets et Nightwatch reste encore la solution la plus adaptée si vous souhaitez effectuer des tests end to end fonctionnant sur tous les browsers. C’est cet outil, couplé à Browserstack que nous utilisons chez MeilleursAgents.

En ce qui concerne les tests d’accessibilité, la librairie axe-core peut être utilisée en complément de QUnit.

Du côté des performances, il est possible de réaliser des macro benchmarks comme c’est la cas sur Ember avec la librairie ember-macro-benchmark ou encore en utilisant la Performance tab présente au sein des Devtools de Chrome. Un très bon article sur le sujet a d’ailleurs été rédigé par Ben Schwarz pour analyser les performances d’une application React.

Enfin, il est possible de déterminer si le code chargé par une page web est réellement nécessaire via l’utilisation de Chrome headless et des fonctionnalités apportées par la Protocol Devtool.
Paul Irish a partagé un gist illustrant ce type de tests.

Slides: Working Well: The Future of Web Testing

Expérimentations et accessibilité par Suz Hinton

Suz Hinton, Technical Evangelist à Microsoft est également streameuse sur Twitch où elle partage avec ses fans la programmation de sa librairie open source avrgirl-arduino qui est une librairie NodeJS permettant de flasher sur un micro contrôleur Arduino des fichiers sketchs compilés.

Elle est également une fervente défenseuse de l’accessibilité sur le web et c’est pourquoi elle a décidé de sensibiliser l’auditoire à ce sujet en commençant par nous parler de la représentation du handicap à travers le symbole international d’accessibilité qui correspond au caractère unicode U+267F.

Ce symbole a récemment été redesigné par l’artiste Sara Hendren afin de lui donner un look and feel plus dynamique. Elle n’a d’ailleurs pas hésité à taguer les panneaux de stationnement avec ce nouveau symbole afin de le promouvoir et de sensibiliser le grand public.

Sara Hendren devant un panneau de stationnement recouvert du nouveau symbole

Suz a donc décidé de suivre l’exemple de Sara et d’appliquer ce type de démarche à travers le développement d’application web diverses.

Elle a par exemple réalisé une petite librairie permettant d’ajouter une description aux photographies présentent sur Instagram via l’utilisation de l’API de Computer Vision d’Azure.

Afin de rendre son stream Twitch plus accessible, elle y a également rajouté des sous titres qui sont retranscrit en direct. Pour cela, elle a tout d’abord du entrainer le modèle du Custom Speech Service de Microsoft puisque celui-ci reconnaissait mal sa voix à l’accent Australien. Elle a donc créé une librairie permettant de processer de nombreux enregistrements audio de sa voix. Puis elle a fait un wrapper Node JS pour la Microsoft Translator Speech API afin de pouvoir plus facilement diffuser le transcript sur Twitch.

Comment agacer un spammer par Feross Aboukhadijeh

Lorsqu’il ne développe pas des projets Open Source, tel que le célèbre WebTorrent, Feross aime bien décortiquer les différentes API des navigateurs afin de repérer les failles lui permettant de créer des hacks pour duper l’utilisateur.

À l’époque de Flash, il a par exemple créé un site web qui activait la webcam de l’utilisateur après que celui-ci ai effectué une série de cliques dans le navigateur.

Il a expliqué sa démarche à travers le blog post suivant:
HOW TO: Spy on the Webcams of Your Website Visitors

Suite à l’apparition de HTML5 et des nouveaux standard de Web Storage, qui autorisent maintenant les sites web à stocker jusqu’à 10Mb de données dans le localstorage, Feross a remarqué que cette limite ne s’appliquait qu’à un domaine en particulier et qu’il était possible de bypasser cette limite en utilisant de nombreux sous domaines. Il a donc créé FillDisk.com qui exploite cette vulnérabilité afin de remplir le disque dur de l’internaute.

Pour une explication plus détaillée de cette méthode, vous pouvez consulter son blog post: Introducing the HTML5 Hard Disk Filler™ API

Ces hacks s’avèrent être plutôt divertissants et sans réelles conséquences pour l’utilisateur, ce qui n’est pas le cas du hack lié à la fullscreen API, puisque comme il l’a démontré à travers un blog post, il est possible d’utiliser ce dernier pour réaliser des attaques de type phishing comme c’est le cas ici avec Bank of America: Using the HTML5 Fullscreen API for Phishing Attacks

Cette fois-ci, Feross étant un peu fatigué à l’idée de recevoir des mails de la part de scammers, il a décidé de leur répondre et de les diriger vers The Annoying Site sur lequel il prend un malin plaisir à utiliser l’objet window afin de créer de nouvelles fenêtres et de déplacer ces dernières dès lors que l’utilisateur souhaite les fermer, le tout accompagné par la douce mélodie de Mr. Trololo et de Dubstep Cat. En bonus, le site fini par vous logout de tous les sites sur lesquels vous êtes connecté, histoire de vous énerver encore un peu plus.

JavaScript Patterns plutôt que Frameworks par Adrian Holovaty

Adrian Holovaty est co-créateur du framework Django ainsi que du site Soundslice qui à l’étonnement de beaucoup de personnes n’utilise aucun framework ! Lassé de se voir demander quel framework il utilise, il a décidé de réaliser un talk afin d’expliquer pourquoi il est préférable d’utiliser des patterns issues de vanilla JavaScript plutôt que de célèbres frameworks.

Selon lui, les frameworks sont destinés à répondre à un problème spécifique comme ce fut le cas pour Django qui était au départ destiné à développer des features rapidement pour The Atlanta Journal-Constitution. Django a ensuite été rendu disponible en Open Source et Adrian a continué à maintenir le projet pendant 3 ans avant de ne céder la place à d’autres développeurs.

Durant cette période, il s’est rendu compte que beaucoup de features ont été ajoutés au framework alors que celles-ci ne répondaient qu’à des problèmes spécifiques rencontrés par une ou quelques personnes mais dont vous n’aurez peut être pas besoin pour votre projet.

Afin d’éviter d’embarquer dans votre site une pléthore de features dont vous n’avez pas l’utilité, Adrian recommande plutôt de coder en JavaScript natif et d’utiliser des librairies répondant à un problème spécifique lorsque vous en avez besoin.

Recevoir des données du ciel par Thomas Watson

Thomas Watson, développeur chez Elastic et Open Source Hacker sur son temps libre, a réalisé le talk le plus étonnant et controversé de cette édition de DotJS.

Il a tout d’abord commencé par nous expliquer comment les avions communiquent leur identité aux tours de contrôles mais également entre eux grâce au protocole ADS-B. Ce protocole n’étant pas chiffré, il est possible via l’utilisation d’un dongle équipé d’une puce RTL2832U de recevoir les signaux émis par ces avions.

Pour y parvenir, il a créé un Node JS wrapper de la librairie rtl-sdr qui permet de hacker le dongle afin de recevoir les ondes radios. Il a ensuite codé une librairie permettant de décoder les messages Mode S utilisés par le protocole ADS-B afin de retourner un object JavaScript facile à manipuler.

Lors de sa présentation, il nous a montré à travers plusieurs démos comment il est possible d’afficher en direct sur une map les différents avions volant au dessus de nos têtes mais également comment récupérer des informations relatives au modèle de l’avion et au numéro de vol.

Il a avoué être assez étonné par le fait que ce mode de communication n’ait pas connu d’évolution majeure, notamment en matière de chiffrement, puisqu’une personne mal intentionnée pourrait très bien utiliser ce protocole afin de transmettre de fausses informations dans le but de perturber le trafic aérien.

Vous pouvez retrouver l’app permettant d’afficher les avions sur une map à l’adresse suivante: https://github.com/watson/airplanejs

Les entrailles de Webpack par Sean Larkin

Sean Larkin, membre de la core team Webpack et Developper Advocate pour Microsoft, nous a présenté Tapable lors d’un pure show à l’américaine.

Tapable est un module regroupant de nombreux packages qui exposent des Hooks afin de permettre le bon fonctionnement de Webpack mais également de créer des plugins pour ce dernier.

Ce fut un talk très technique où il a expliqué les différentes possibilités offertes par ce module tout en détaillant les nouveautés à venir avec la version 4 de Webpack.

Accessibilité et débogage par Marcy Sutton

Marcy Sutton, développeuse web et Accessibility Advocate chez Deque où elle maintient le projet Axe Core, nous a expliqué comment rendre le web accessible au plus grand nombre et quels outils peuvent nous le permettre.

Elle considère l’accessibilité au sens large puisque selon elle, de nombreux facteurs peuvent influencer l’expérience de l’utilisateur, tel que son handicap, son emplacement, son âge, sa capacité de lecture, ses revenus, le terminal qu’il utilise pour naviguer sur votre site ainsi que sa connexion Internet.

Afin de nous montrer quels outils elle utilise pour rendre un site accessible, Marcy a live codé une application en commençant tout d’abord par l’auditer avec l’extension Chrome aXe-Coconut. Il est également possible d’auditer via la Chrome Accessibility Developer Tools.

Suite à cet audit, elle s’est occupée de :

  • utiliser la bonne sémantique pour les éléments du DOM. 
    Par exemple, un button dans le cas d’un bouton et non pas une div
    De même pour les labels en utilisant l’élément label.
  • garder l’information de focus sur ce bouton en évitant d’utiliser la propriété CSS outline: none
  • permettre la navigation uniquement via des tabulations
  • rendre les différents éléments accessibles avec ARIA
  • utiliser l’attribut inert afin de rendre accessible le burger menu présent dans l’application

Pour davantage d’informations, vous pouvez consulter les slides à l’adresse suivante: Enabling Users in Client-Rendered Applications

La course aux performances par Tom Dale

Tom Dale, ingénieur logiciel chez Linkedin et co-créateur du framework Ember, nous a présenté le gain de performances apporté par Glimmer.

Glimmer s’installe bien entendu avec Ember-CLI et render en live des templates Handlebar qu’il compile en bytecode afin de permettre un temps de premier affichage mais également d’update très rapide lorsque les données changent. Le tout est interprété par une machine virtuelle afin d’afficher les données sur le navigateur.

Tom nous a montré plusieurs vidéos comparatives entre React et Glimmer sur un vieux téléphone Android et il faut bien avouer que le résultat est assez bluffant dans certains cas.

Vous pouvez utiliser l’espace de playground pour constater ce gain de performances par vous même. Et si vous souhaitez aller plus loin, je vous encourage à effectuer le Getting Started.

Historique du JavaScript par Brendan Eich

Brendan Eich, créateur emblématique du langage JavaScript, a clôturé cette cinquième édition de DotJS en nous parlant des moments clés de l’évolution du langage ainsi que des fonctionnalités à venir.

Malgré les nombreuses critiques envers sa création de la part de personnes dubitatives, Brendan a toujours cru au langage et c’est avec cette citation de Ian Ickson, éditeur de la spec HTML5, qu’il a débuté sa présentation:

Things that are impossible just take longer

Il a ensuite décrit les différents jalons qui ont permis l’évolution du langage tel qu’on le connait aujourd’hui et nous a présenté les futures fonctionnalités proposées par le Ecma TC39 (Technical Committee 39 — ECMAScript), tel que BigInt ou encore les nouvelles possibilités offertes par RegExp.

Pour plus d’informations au sujet de ces améliorations, vous pouvez consulter les slides à l’adresse suivante: A Brief History of JavaScript

Conclusion

En conclusion, cette édition de Dot JS fut riche et variée, aussi bien au niveau des sujets abordés (accessibilité, développement JS, hack, …) que de la qualité des talks. Si je devais ne vous conseiller que trois talks à regarder, ma sélection serait la suivante: