Retours conférence DotJS 2017

Ce vendredi 1 Décembre, un petit groupe d’homo-Intechus composé d’Aymeric, Julien D., Stéphane et Clément s’est rendu à la conférence DotJS à Paris.

C’est non sans mal que nous sommes arrivés vendredi matin au Dock Pullman à Aubervilliers, ceci grâce à ces quelques premiers flocons de neige qui sont venus perturber une nouvelle fois notre chère et tendre SNCF <3

Au moins, on peut vous confirmer que ce n’est pas parce que l’on prend un TGV que l’on est forcément épargné ! Notre train ayant finalement circulé avec un retard de 40 minutes.

On a presque eu peur de ne pas profiter du petit-dej avant la keynote !

 

Nous voici donc embarqué dans cette conférence parisienne, qui comme son nom l’indique est consacrée à l’univers JavaScript et qui a regroupé environ 1400 participants en cette année 2017.

Nous avons commencé avec le petit-déjeuner dans le hall d’entrée, dans lequel se tenaient un certain nombre de stands de diverses entreprises telles que Google, Microsoft, Zalando ou Vente-privée. Nous avons pu profiter de différentes démonstrations tout en récoltant de nombreux goodies durant les pauses.

L’ensemble des conférences étaient tenues dans une seule grande et unique salle avec une mise en scène en grande pompe.

Concernant les conférences auxquelles nous avons assisté :

Trent Willis (Netflix) – Working Well: The Future of Web Testing

Pour ceux d’entre vous qui ont tenté d’effectuer des tests fonctionnels automatisés d’un front-end avec WebDriver et Selenium, la frustration est un sentiment qui ne leur est pas inconnu. Car en effet, l’accès aux données techniques, (l’état du navigateur, les performances, etc.) étaient des informations qui n’étaient pas accessible.

Mais récemment, Google a créé Pupeteer une api permettant de manipuler Chrome Headless (headless signifiant sans interface graphique).

Pupeteer permet donc de :

  • jouer des scripts dans le contexte de la webpage chargée
  • recueillir des informations du debugger
  • générer des screenshot et PDF nativement depuis la webpage chargée
  • tester les performances (% de code vraiment utilisé, temps de chargement) en plus de tests unitaires classiques
  • diagnostiquer les temps et la chronologie de chargement dans le navigateur

 

Suz Hinton – New Tools for Old Problems

Suz(e) [ désolé ¯\_(ツ)_/¯ ], qui aime passer ses Dimanche à faire du livecoding sur Twitch, nous a présenté une idée pour améliorer l’accessibilité sur le web. Beaucoup de contenu multimédia (notamment vidéos et images) ne contiennent pas forcément des informations textuelles descriptives. Elle nous montre à travers une galerie Instagram que les descriptions ne sont pas souvent remplies par les utilisateurs (#NoFilter #NoCaption). En utilisant une API de Machine Learning, et en seulement 25 lignes de code JS, elle parvient à ajouter une description à chacune des photos se trouvant dans la galerie. Cela créé de nouvelles opportunités pour garantir une qualité de contenu sur différents médias.

 

Thomas Watson – Getting Data From The Sky

Vous avez toujours voulu savoir ce qui se passe au dessus de vos têtes ?

Pour cela, rien de plus simple. Cette conférence de haut vol nous montre qu’il suffit d’acheter une antenne radio avec un adapteur RTL2832U et vous serez en mesure de collecter les données des avions en temps réel ! Pas de chiffrement, pas d’authentification, juste des données tombées du ciel.

Antenne radio pour scan les avions: https://github.com/watson/rtl-sdr

 

Marcy Sutton – Enabling Users in Client-Rendered Applications

Marcy nous sensibilise à l’accessibilité et aux différentes pratiques à mettre en place pour leur offrir un confort de navigation.

 

Marcy a mis en avant les points suivants :

  • respect de la structure et de la sémantique des pages (nav, button, header, article, section, aside, footer, ….)
  • garantir un contraste des couleurs équilibré
  • gérer le focus TOUJOURS ! Bye bye  * { outline: none }
  • penser aux utilisateurs avec lecteur d’écran et interaction limitée avec le clavier. C’est-à-dire, garantir la navigation par tabulation avec l’utilisation de l’attribut tabindex
  • utiliser ARIA pour les personnes utilisant des lecteurs d’écran (notamment sur les icônes de bouton afin de décrire leur fonctionnalité)

 

Elle nous a également montré l’utilisation d’un plugin Chrome qui est un outil de testing d’accessibilité qui liste toutes les règles non respectées dans les éléments de notre page web aussi bien dans le DOM que dans le Shadow DOM.

Ce plugin repose sur le module NPM axe-core, qui lui est utilisé pour effectuer des tests automatisées

Le plugin Chrome aXe : https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd

Sa version avec les dernières fonctionnalités expérimentales, aXe-Coconut : https://chrome.google.com/webstore/detail/axe-coconut/iobddmbdndbbbfjopjdgadphaoihpojp

Stas Vilchik – Make your TypeScript compiler smarter! (Lightning Talk)

Si vous trouvez que les règles de tslint sont encore beaucoup trop laxistes à votre goût (ce qui fait de vous un véritable Grammar Nazi), vous avez la possibilité de très facilement créer des nouvelles règles en créant un simple module Node : https://github.com/stas-vilchik/dotjs-linter

 

Tom Dale (LinkedIn) – Bytecode Rendering on the Web

Si vous en avez assez d’attendre de voir votre navigateur afficher encore une fois cette page blanche gênante sur votre smartphone, alors, vous allez apprécier Glimmer.

Pour arriver à l’apparition des éléments dans le DOM, il faut passer par les étapes suivantes :

  • le téléchargement des fichier statiques (CSS, JS, images)
  • le parsing du JS
  • le rendu

 

Avec l’arrivée de React, un premier pas vers le chemin de la rapidité a été fait grâce au Virtual DOM.

 

Mais faut-il obligatoirement passer par ces 3 étapes ?

Est-ce qu’on peut agir sur le téléchargement ? A travers la minification oui … mais le véritable entonnoir reste le réseau.

Le parsing JS est-il vraiment incontournable ? La complexité pourrait être déplacé vers le compilateur (oui, vous avez bien lu, il est écrit compilateur) On pourrait compiler en bytecode et interpréter celui-ci dans une machine virtuelle se trouvant dans le navigateur.

Un outil permettant une telle magie noire existe et il se nomme : Glimmer !

 

Faire tourner du bytecode dans les navigateurs GlimmerJs : https://glimmerjs.com/guides/installing

Faire joujou avec : https://glimmer-playground.netlify.com/

 

Brendan Eich – A Brief History of JavaScript

Le créateur de JavaScript lui-même nous a fait l’honneur de sa présence.

A travers des slides tout à fait lolesque (oui, Brendan aime mettre des “lol” sur ses slides … et surtout à côté de “Webpack”), Brendan nous a compté l’épopée de la naissance et de l’évolution du langage qu’il a créé en 10 jours. Après avoir passé un moment à nager dans la nostalgie, il nous montra rapidement une liste des futurs améliorations prévues :

 

Slides : https://brendaneich.com/wp-content/uploads/2017/12/dotJS-2017.pdf

 

En espérant avoir su vous donner envie d’assister à votre tour à cette conférence dans les années à venir;  vous pourrez trouver ci-dessous un lien vers les différentes présentations que vous pourrez consulter pour avoir de plus amples détails : https://goo.gl/y6hqKn

 

N’hésitez pas à nous contacter si vous avez des questions !

 

Aymeric, Clément, Julien D. , Stéphane

 

About clement.brunel

Mail User
This entry was posted in conférence and tagged , , . Bookmark the permalink.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*