Retour sur dotJS 2016

Publié le 13 décembre 2016 par Vincent Billey | actualité

Cet article est publié sous licence CC BY-NC-SA

Cette année, dotJS a failli ne pas pouvoir arriver car le théâtre prévu pour accueillir les quelques 1200 participant a brûlé 3 mois avant l’évènement. C’est finalement une autre salle qui a été réservée rapidement et qui a permis d’innover un peu sur la présentation de la conférence (des fauteuils, des canapés, une fausse cheminée pour les discussions après les talks…).

C’est donc non sans plaisir que j’ai pu participer à cette 5e édition et voici un résumé des différents talks de la journée.

Service Workers and the Appification of the web

Nolan Lawson - slides

Une présentation des Service Workers qui revient sur la raison d’être de HTML5 : répondre à la menace que Flash et Silverlight représentait pour lui. Ce talk fait remarquer que le W3C ne répond pas à ce genre de problématique de façon monolithique mais propose des solutions séparées pour tous les problèmes (copier/coller, upload multiple, vidéos, canvas, animations…).

Le Web a maintenant un nouvel “ennemi” : les applications mobiles natives. Les Service Workers sont un des éléments de réponse et permettent notamment de gérer le mode hors ligne et les notifications push (et PeriodicSync est en cours de création, Chrome a déjà une version). La bataille est loin d’être gagnée cependant car l’implémentation de toutes ces technologies rend le développement plus ardu mais bien que le Web soit rarement le premier à proposer des fonctionnalités, c’est souvent une très bonne façon de les gérer et souvent une meilleure approche : les Services Workers ne fonctionnent qu’en HTTPS, ils sont fait pour être éphémères, doivent pouvoir se relancer n’importe quand et ont besoin de permissions pour être exécutés.

Pour résumer, le web est comme David Bowie, il évolue en restant lui même et il n’hésite pas à prendre les idées pour les améliorer.

“In a sense, the web is kind of like David Bowie.

Bowie changed wildly from decade to decade, and he often borrowed or outright stole from the context around him when he explored new musical genres, themes, and hairstyles. But there’s still an identifiable thread of Bowie-ness that you can see throughout his career.

And when he did borrow something from the context around him, be it glam rock or kraut rock, he did it best. That’s the web.”

Bringing VR to the Web

Ada Rose Edwards - slides

Une présentation sous forme d’éloge à la réalité virtuelle (VR). C’est un rêve de gosse pour ma génération (j’ai 29 ans à l’écriture de cet article) et petit à petit la VR semble pouvoir devenir une réalité et particulièrement sur le Web.

Pour cela, il existe déjà des possibilités d’avoir des navigateurs dans la réalité virtuelle (Samsung et Google en proposent) et déjà la possibilité d’avoir une vidéo 3D dans un élément HTML :

<video controls src="360video.mp4" type="video/mp4; dimension=360-lr;" ></video>

L’une des principales limitations est la bande passante et la rapidité de chargement d’un contenu 3D complet. L’un des palliatif est d’utiliser les Service Workers pour gérer un cache et un téléchargement progressif des données. Ou plus simplement de se contenter de formes plus simples et de ne pas rechercher la fidélité visuelle.

“If visual fidelity was all that mattered, we would be watching blurays, not Netflix”

Josh Carpenter

Le W3C semble d’accord pour dire qu’il faut faire des efforts pour améliorer l’interopérabilité entre le Web et la VR : WebVR.

Je retiens également de cette présentation qu’il faut que des novices de la 3D se mettent à tester la VR pour pouvoir détecter les difficultés et améliorer le processus pour que tout le monde puisse mieux en profiter.

Tuning Babel to your runtime

Christophe Porteneuve - slides

Un remplacement au pied levé d’un speaker qui n’a pas pu être présent cette année mais qui n’en reste pas moins intéressant : une présentation des options de configuration de Babel 6.

La version 6 de Babel a changé de paradigme. Avant, Babel était une solution complète out of the box et il suffisait de l’intégrer au projet pour bénéficier de ES2015. La nouvelle version a fait le choix (et en a souffert) de permettre de compiler chaque nouvelle fonctionnalité du langage séparément. Chaque plugin est appelé transforms et il en existe une soixantaine à l’heure actuelle (dont 21 pour ES2015).

Pour simplifier tout ça cependant, Babel propose des presets qui regroupent un ensemble de ces plugins. Le plus simple à utiliser est le preset latest qui regroupe toutes les fonctionnalités déjà validées par le TC39 (stage-4) qui ne sont plus sujettes à discussion et qui arriveront donc dans le langage bientôt.

Pour les utilisateurs de node, le preset latest-minimal permet de ne sélectionner que le minimum nécessaire en fonction de la version de node que vous utilisez (et que vous précisez dans le package.json de votre package).

Et pour ceux qui aimeraient unifier les deux et ceux qui ne veulent pas forcément maintenir les vieilles versions de navigateurs, il existe maintenant le preset env qui a un fonctionnement similaire à Autoprefixer. Vous pourrez alors ne supporter que les 2 dernières versions des navigateurs.

Voici un exemple qui ne prend en compte que les deux dernières versions des navigateurs qui représentent plus de 1% de part de marché, qui ne tient pas compte des versions inférieures à 10 pour Safari et qui fait la même chose que latest-minimal pour node.

{
 "presets": [
   ["env", {
     "targets": {
       "safari": 10,
       "browsers": "> 1%, last 2 versions",
       "node": "current"
     }
   }]
 ]
}

The native integration of ES modules into the web

Guy Bedford

Un talk sur un (le ?) futur des outils de l’écosystème JavaScript et plus particulièrement sur l’avenir des modules ES2015 (import et export). Guy est l’auteur de jspm et de SystemJS et nous présente comment se passer de bundles JavaScript qui concatènent tous les modules utilisés.

C’est la présentation qui m’a donné le plus envie de cette édition de dotJS, pas à cause d’un effet wow mais en raison de la perspective offerte par la possibilité d’utiliser les modules directement dans le navigateur. Le but n’est bien évidemment pas de laisser le navigateur se débrouiller avec les 400 imports de fichiers divers et variés mais de départager son code final en plusieurs modules (dont certains pourraient être en asm.js) optimisés pour ce qu’on veut réaliser avec son site ou son application.

En effet, certaines librairies ne méritent pas d’être chargées dès le départ, d’autres ont besoin d’être présentes en permanence. L’utilisation de Service Workers peut permettre de précharger des modules (et devraient bientôt pouvoir utiliser la syntaxe import). Et plus particulièrement, la syntaxe d’import devrait, à terme, permettre de réaliser des imports conditionnels : c’est à dire qu’en fonction d’une action (ou d’une préférence utilisateur par exemple), on pourra charger un fichier particulier sous forme d’une promesse pour ensuite pouvoir l’utiliser dans son application et cette fonctionnalité me semble très intéressante.

Lightning talks #1

Marko Kovacevic nous a présenté RxJS, un système de streams qui permet entre autre (Il est difficile de développer le sujet en moins de 5 minutes) de répondre au problème d’annulation des promesses.

Rolf Erik nous a présenté son projet lint-filter qui a pour but de simplifier la correction des erreurs remontées par ESLint. Plutôt que de toutes les lister en une seule fois, lint-filter permet d’ajouter progressivement des règles de linting en ne les appliquant que sur les lignes présentes dans le commit en cours. De cette façon, on ne fait que commiter du code qui correspond aux guidelines mais on peut se passer de corriger tout le dépôt. On améliorera le code au fur et à mesure de ses modifications. Plus d’informations ici : Filtering lint errors.

Vladimir de Turckheim nous a mis en garde contre les injections en NoSQL. Utiliser une base de données non relationnelle n’empêche pas de courir le risque d’une injection : par exemple, un paramètre pourrait contenir { $ne: 0 } et récupérer plus de données que voulu. Il est donc important de valider le payload avant de faire des requêtes en base de données avec un outil comme joi.

Maxime Thirouin nous a présenté son générateur de site statique en React : Phenomic. Sa particularité est de générer un site statique utilisable sans activer JavaScript tout en devenant une Single Page App une fois le JS chargé. Les transitions entre les pages ne provoquent alors plus de rechargement. Et bonus, on peut également précharger les données des pages liées à la page courante et avoir de l’offline par défaut.

JavaScript Userland

Zeke Sikelianos - Liste de liens du talk

Cette présentation a commencé par une critique assez acerbe de npm qui en 2 ans n’a pas beaucoup évolué en dehors de la couleur du header et de la présence de publicité dans la sidebar mais qui a perdu son coté opensource. Le code du site était sur github de manière publique et ça a été abandonné. Il existe peut être d’autre raison pour Zeke mais il n’hésite pas à faire la comparaison entre IO.js (le fork de node) et Yarn pour expliquer que npm s’est reposé sur ses lauriers et que de la concurrence lui fera du bien (c’est tout du moins l’interprétation gentille).

Il a ensuite enchaîné sur un état des lieux des packages JavaScript : on tourne autour de 400-500 packages publiés par jour sur npm et c’est une bonne chose tant qu’on ne doit pas choisir ceux qui sont intéressant à utiliser ou non. Le nombre de téléchargement d’un package n’est pas forcément un bon indicateur, le nombre de contributeur en est un meilleur car il montre l’intérêt de la communauté à améliorer l’outil et évite donc le risque d’abandon du projet.

Et pour cela, on a eu droit à une liste d’outil que vous pouvez retrouver ci dessus. Les plus intéressant à mon sens me semblent être :

  • npm-hub qui ajoute une entrée au README d’un projet qui contient un fichier package.json qui liste les dépendances sous le README.
  • trymodule qui permet de lancer une console node avec un module préchargé depuis npm pour le tester sans créer un projet complet.
  • ntl qui propose un affichage dynamique des actions qui peuvent être lancées avec npm run
  • ghub.io qui est une sorte de raccourci d’URL : http://ghub.io/choo vous redirigera sur la page github du module npm choo. Dans la même veine, http://npm.im/choo vous redirigera vers sa page npm (et http://mdn.io/array.includes fera le même genre de chose pour MDN).

Reactivity in Frontend JavaScript Framework

Evan You - slides

Après être passé brièvement sur le fait que personne ne semble d’accord sur le concept de Reactive Programming et encore moins sur le concept de Functional Reactive Programming (puisqu’apparemment, d’après Hacker News, seul la définition donnée par son auteur peut être de la “vraie” programmation réactive). Evan renomme son talk How Things Happen in Frontend JavaScript Framework et présente les différentes façons qu’ont les framework du moment pour gérer le fait qu’une variable soit une dérivation d’une autre, ie b doit être toujours égal à 10 * a ou de manière générale, comment maintenir la relation entre la vue et les données.

On a donc un aperçu des choix opérés par React, Redux, Angular, Angular 2 et finalement Vue.js. Chacun fournit un moyen de limiter le plus possible le nombre de nœuds à recréer à chaque modification. Vue adopte le même système que MobX pour React : ajouter des listeners et des subscribers sur chaque donnée présente dans le state de l’application pour n’avoir à recréer que les vues affectées par ce changement (soit la liste des subscribers).

Ce choix rend Vue.js très performant et permet de ne pas faire de travail d’optimisation manuel. J’imagine que c’est une des raison de sa popularité cette année. La modification des données peut ainsi être aussi simple qu’une assignation de variable ou une mise à jour de propriété d’un objet et tout sera géré automatiquement ensuite. C’est également la raison pour laquelle je n’aime pas ce framework mais c’est un avis personnel qui provoque des débats au sein de Synbioz. Je préfère manipuler des données immutables et exprimer les changements sous la forme d’une action comme le proposent Redux et Elm.

Lightning #2

Bertrand Chevrier nous a présenté WebVim : une configuration complète de Vim pour développer du Frontend. Le logo de Vim a d’ailleurs prouvé qu’il était très apprécié de la communauté.

Gonçalo Morais a expliqué les opérations binaires en JavaScript et précisé que bien que ça ne soit pas une bonne idée de les utiliser pour une application en production, on peut les utiliser pour faire de sérieuses optimisations (dans le cas d’un jeu par exemple) et il est intéressant de les connaitre et de jouer avec sur un projet personnel.

Sebastien Chopin, le créateur de Nuxt nous a présenté son projet. Inspiré de Next (dont je vais parler un peu plus bas) et basé sur Vue.js au lieu de React.

Thomas Belin (slides) nous a donné une présentation de Cycle.js sans le dire par une analogie entre l’UI et les flux qui peuvent la faire changer et une personne qui parle et ses auditeurs.

Memory Layout of V8’s heap

Fedor Indutny - slides

Si le titre du talk ne vous parle pas, sachez que c’était le talk technique de cette année. On a pu voir une partie du processus de debug de node en allant fouiller au cœur de V8. Je ne vais pas vous mentir, je n’ai pas saisi grand chose et je vous invite à vous faire votre propre idée.

Live.JS

Si vous aimez la musique, sa visualisation et le bidouillage, je vous invite à surveiller la sortie de la vidéo de ce talk. En résumé : comment visualiser la musique chiptune depuis une Game Boy Advance sur une série de LED, un écran, des projecteurs et avec une machine à fumée en bonus. Je vous laisse avec ce sketch de Florine Pigny pour vous faire une petite idée.

Universal JavaScript

Guillermo Rauch

Une présentation de Next.js dont vous pouvez retrouver les principales caractéristiques sur cet article de présentation. Le but de cet outil est de permettre de réaliser un site qui peut s’exécuter aussi bien sur le serveur que chez le client. La première page à laquelle on accède sera donc servie intégralement par le serveur, les suivantes seront obtenus par des appels asynchrones.

Pour cela, Next reprend une vieille idée du monde PHP : utiliser le système de fichier comme API, c’est à dire créer un fichier JavaScript par page de son application. Le concept est intéressant et couplé à now, de la même entreprise, on peut créer un site web purement en JavaScript de manière simple, rapide et performante. Ceci bien sûr à condition d’apprécier React (ou Vue et d’utiliser Nuxt.js).

Keep your minds open

Igor Minar

Le dernier talk de la journée dont le titre n’évoque pas complètement le contenu. Sous couvert de nous demander de garder l’esprit ouvert, on a surtout eu droit à un historique d’Angular 2. Son histoire est assez intéressante cependant et l’ouverture d’esprit dont il a parlé a été du coté des frameworks concurrents.

Beaucoup de gens semblent penser que React et Angular sont des ennemis publics mais les core développeurs des deux frameworks se retrouvent une à deux fois par an pour discuter. Il est officiel qu’Angular 2 a repris la notion d’unidirectional data flow portée par React.

Les relations avec la communauté d’Ember étaient par contre réellement tendues (et continuent à l’être en partie) mais ça n’a pas empêché les mainteneurs d’Ember CLI de proposer leur aide à l’équipe d’Angular pour réaliser leur propre interface en ligne de commande.

Au final, il est donc faux de penser que la concurrence entraine forcément de l’animosité : tous les frameworks actuels collaborent entre eux et se partagent leur découvertes et leurs astuces. Ne soyez pas méchants si un framework ne vous plait pas, essayez de comprendre pourquoi et comment il en est arrivé là et si possible, proposez leur vos retours constructifs pour qu’ils puissent s’améliorer.

Conclusion

dotJS est toujours l’occasion de sonder l’écosystème JavaScript pour avoir un avis sur les technologies à la mode. Cette année, c’est clairement Vue.js qui a le vent en poupe. React se maintient et semble devenir un pilier, Angular2 prend des pincettes et Ember est cité de temps en temps pour son aide sur les autres projets. Le mantra lancé par Brendan Eich est toujours vivace “Always bet on JS” et est un peu la réponse à toutes les questions sur le bien fondé de l’utilisation de JavaScript pour quelque chose (de la musique ?). Force est de constater que rien ne semble infaisable avec ce langage. Que tout doive être fait avec est cependant un autre débat.

L’équipe Synbioz.

Libres d’être ensemble.