Le lundi 5 décembre dernier s’est tenue la 5e édition de dotJS au Dock Pullman situé à Courbevoie. Cette conférence a pris de l’ampleur au fil des années pour devenir la plus grande d’Europe en ce qui concerne JavaScript et elle accueille désormais des stars de la communauté comme Evan You (créateur de Vue.js) et Igor Minar (lead developpeur d’Angular.js). On salue l’équipe de dotJS qui a évité la catastrophe de dernière minute, la salle initialement prévue ayant brûlé quelques mois plus tôt.
Cette journée riche fut animée de main de maître par Sylvain Zimmer. Il introduisait chaque speaker puis, après le déroulement de la présentation, passait au salon pour discuter tranquillement avec lui au coin du feu (virtuel bien sûr) !
Cet échange avec chaque interlocuteur était vraiment intéressant et permettait de sortir du cadre unique de la présentation pour élargir sur d’autres problématiques. Mais revenons à nos moutons et voyons ensemble nos coups de cœur de la journée :
Service Worker and the Appification of the Web – Nolan Lawson
Nolan Lawson travaille chez Microsoft dans l’équipe développant le navigateur Edge et c’est également le créateur de Pokedex.org, qui constitue probablement l’exemple le plus abouti actuellement de Progressive Web App. Il revient dans sa présentation sur l’histoire des applications Web et commence en 2004, lors du tout début de ces applications. En effet, il était impossible à l’époque de réaliser des interfaces riches simplement avec du HTML. C’est pourquoi des solutions comme Flash (Macromédia) et Silverlight (Microsoft) ont émergé car elles permettaient de développer facilement des interfaces plus fluides et plus dynamiques. L’arrivée du HTML 5 fut la réponse à ces solutions propriétaires car cette évolution du langage apporta les animations, l’upload de fichiers, les vidéos, les canvas, etc. Le HTML 5 finit par gagner définitivement et enterra Flash et Silverlight mais Nolan Lawson nous met en garde que cela n’était aucunement garanti et qu’on aurait pu se retrouver aujourd’hui avec des sites portant la mention « Best viewed with Flash », bref un Web fermé.
Il fait ainsi le parallèle avec la situation aujourd’hui car un autre danger guette actuellement le Web : les applications natives. De plus en plus de sites portent la mention « Download on App Store » ou « Get it on Google Play » et si les réseaux sociaux ou les sites d’actualité sont consommés via le Web en utilisation bureau, ils sont consommés a contrario via des applications en utilisation mobile. Il est vrai que celles-ci gèrent très bien l’offline, les notifications et la synchronisation en arrière-plan par exemple. Donc, tout comme le HTML 5 fut la réponse à Flash/Silverlight, Nolan Lawson nous explique que les Progressive Web Apps (PWA) et notamment les Service Workers sont la réponse aux applications natives. Un Service Worker est simplement un proxy tournant en tâche de fond entre le site web et le serveur. Il va intercepter n’importe quelle requête (image, HTML, CSS, …) et répondre avec une ressource qui peut être contenue dans un cache. Il peut également « pousser » des notifications. Bref, il répond à l’ensemble des cas d’utilisation du mobile.
Nolan Lawson conclue sa très belle présentation par un plaidoyer en faveur du Web libre. En effet, le Web doit rester disponible pour tout le monde, tourner sur tous les supports et rester ouvert et multiple.
Bringing VR into the Web – Ada Rose Edwards
Ada Rose Edwards travaille chez Samsung sur la réalité virtuelle et notamment le casque Samsung Gear VR. Selon elle, la réalité virtuelle n’en est qu’à ses balbutiements, tout comme le mobile dans les années 80, et pourrait potentiellement rentrer dans notre quotidien dans quelques années. Il faut donc concevoir dès maintenant une solution permettant d’accéder à des contenus adaptés sur Internet. Samsung a développé pour ça le navigateur Samsung Internet for Gear VR permettant la navigation depuis un casque de réalité virtuelle. Voici un exemple d’utilisation dans la vidéo ci-dessous :
Mais pouvoir naviguer sur Internet ne suffit pas. Il faut aussi pouvoir afficher du contenu adapté, accéder aux mouvements de la tête, gérer la distorsion nécéssaire à l’affichage. C’est pourquoi la WebVR API a été créée. On peut grâce à elle capturer l’orientation courante de l’utilisateur, sa vélocité, etc. pour gérer l’affichage du monde dans lequel on veut l’immerger. Seulement, la modélisation 3D est gourmande en ressources et peut engendrer de longs temps de chargement. Ada Rose nous explique donc que, comme n’importe quel autre site Web, il faut une réponse immédiate sous peine d’abandon de la visite. Heureusement, les Services Workers et leur système de cache peuvent répondre en partie à cette problématique. L’exemple donné a été le site http://gun.playcanvas.com qui utilise des modèles 3D sommaires pour un chargement initial rapide, télécharge les modèles 3D détaillés en tâche de fond puis les affiche pour un rendu final haute qualité.
En conclusion, Ada Rose nous dit que la réalité virtuelle et les techniques pour l’utiliser efficacement n’en sont qu’à leurs débuts et que n’importe quel développeur intéressé peut participer à la rédaction des spécifications et contribuer à façonner le prochain médium du Web.
Navigating userland – Zeke Sikelianos
Zeke Sikelianos travaille actuellement chez GitHub sur le framework Electron (qu’il a même utilisé pour programmer ses slides !), mais ayant longtemps travaillé chez npm, il connait bien la galaxie de packages existant et admet qu’il est difficile de s’y retrouver devant une telle abondance. Problème : comment faire pour discerner les packages de qualité ? Voici quelques outils présentés par Zeke Sikelianos qui peuvent aider à séparer le bon grain de l’ivraie, mais aussi nous faciliter la tâche dans notre quotidien de développeur :
- Github : même si ce ne sont pas des indicateurs sûrs à 100 %, le nombre de « stars », le nombre de contributeurs, la date du dernier commit, le nombre de « forks » et le nombre d’issues ouvertes sont des bons indices qui peuvent montrer l’utilisation et donc la qualité d’un package
- Ghub.io : ce site redirige automatiquement vers la page GitHub d’un package passé dans l’url (exemple : http://ghub.io/cheerio)
- npm-hub : cette extension pour Chrome permet d’afficher l’ensemble des dépendances d’un package lorsque l’on navigue sur Github
- OctoLinker : cette autre extension permet de cliquer directement sur une dépendance lorsque l’on navigue dans un fichier package.json ou dans n’import quel fichier .js avec des imports. Assez bluffant !
- libraries.io : un site incontournable pour qui veut trouver rapidement une dépendance dans n’importe quel repository (npm, Maven…) ainsi que des statistiques d’utilisation
- ntl : un petit outil en ligne de commande qui permet de lister l’ensemble des tâches présentes dans le package.json et d’en sélectionner une pour l’exécuter
How Things Happen in Frontend JavaScript Frameworks – Evan You
Evan You est une véritable personnalité de la communauté JavaScript, très présent sur les réseaux sociaux et connu pour travailler à plein temps sur Vue.js grâce à une campagne Patreon réussie. Le titre de sa présentation, au départ « Reactivity in Frontend JavaScript Frameworks », se simplifie devant la diversité des définitions de la programmation réactive. La simplicité était ainsi le maître mot de cette présentation : comment représenter le fonctionnement d’un framework Frontend ? La réponse tient en trois lignes de code :
onStateChanged(() => {
view = render(state)
})
Quand l’état change, on repeint la vue en fonction du nouvel état. Mais comment chaque framework implémente-t-il cette simple fonction ? Deux méthodes principales divisent les frameworks : en push ou en pull.
Pull
La méthode Pull est celle utilisée par React/Redux et Angular (1 et 2). Un signal explicite est lancé pour mettre à jour le système complet (par exemple $scope.$apply en Angular 1, exécuté automatiquement dans les event handlers).
On a ainsi un cycle complet de recalcul et de redessin au moindre changement de l’état. Ce cycle peut être optimisé en utilisant du one-way binding, ce qui induit un arbre de composants et permet une propagation du changement et du recalcul uniquement dans les composants enfants (ce qui est fait dans React et Angular 2). On peut aussi éviter l’update de composants enfants qui n’utilisent pas une propriété modifiée, ce qui est implémenté avec la fonction shouldComponentUpdate dans React et changeDetectionStrategy.onPush dans Angular 2 pour chaque composant.
D’autres optimisations peuvent être faites comme l’utilisation d’un Virtual DOM, solution popularisée par React, ou l’utilisation de données immuables, qui permet au système d’avoir certaines garanties et d’optimiser plus facilement.
Push
La méthode Push est notamment utilisée par Vue.js, Knockout, Meteor et MobX, et s’inspire du pattern Observateur. Dès qu’une propriété accède à une valeur, elle souscrit automatiquement à tout changement de cette valeur. Une fois la valeur modifiée, tous les observateurs sont notifiés. On a ainsi un tracking fin des dépendances, où le système connait exactement ce qui a changé; il peut donc être extrêmement confiant sur les optimisations à effectuer.
Cette méthode implique par contre un overhead en mémoire lié à l’enregistrement de tous les observateurs, mais qui peut être réduit en utilisant des données immuables, évitant le tracking de leurs propriétés.
Pour conclure, chaque méthode implique ainsi certains trade-offs, et on voit souvent un mélange des deux apparaître (React + MobX, Vue.js 2 + données immuables).
Keep your minds open – Igor Minar
Lead développeur d’Angular chez Google, Igor Minar nous refait un historique du framework, et des raisons pour lesquelles Angular est ce qu’il est aujourd’hui.
Angular 1 nous paraît aujourd’hui totalement dépassé, mais le web il y a cinq ans était bien différent : jQuery, Flash et GWT régnaient en maître, et Angular apportait son lot de nouveautés pour l’élaboration de Single Page Applications. On a ainsi eu droit à une timeline de sortie des différents frameworks et spécifications qui ont inspiré Angular 2 : on pourrait croire aux premiers abords que les relations avec les équipes de frameworks concurrents soient tendues, mais en réalité elles s’entraident et se rencontrent régulièrement. Ainsi, l’idée d’intégrer TypeScript est venue d’une rencontre avec les développeurs de Microsoft, et les maintainers d’Ember CLI ont apporté leur aide au développement d’Angular CLI.
D’après Igor, c’est cette ouverture d’esprit face aux solutions reconnues qui fait qu’Angular 2 est si différent d’Angular 1 : afin de rester dans l’air du temps, il devenait évident de devoir se séparer de sa précédente version, en reprenant par exemple le one-way binding de React et en se reposant sur le standard des Web Components. Il finit par nous inviter aussi à rester ouverts d’esprit lorsque l’on juge un framework, en prenant en compte ses forces, ses faiblesses ainsi que le contexte dans lequel il est sorti.
Conclusion
Notre avis sur cette édition de dotJS est assez mitigé : globalement la qualité des présentations était très hétérogène. La plupart étaient très généralistes et philosophiques et peu axées code et utilisation de tous les jours; on sent que les organisateurs veulent faire de dotJS une conférence prestigieuse en invitant des têtes de pont de la communauté, mais ceux qui sont venus pour apprendre et progresser sont un peu mis de côté. Les lightning talks étaient quant à eux plutôt décevants. Heureusement, certaines présentations, comme celle d’Evan You, ont réussi à trouver un bon équilibre et nous ont énormément plu.
PS : les vidéos sont en cours de publication mais certaines sont déjà disponibles sur le site de dotJS