dotJS 2014

Le 19 Novembre 2014, au Théatre de Paris, avait lieu la nouvelle édition de dotJS. Un lieu magnifique, des speakers de renom et des présentations intéressantes. Je n'ai pas réussi à sortir un fil directeur général au programme, mais voici un petit résumé des différentes conférences.

C'est dans l'ordre chronologique de la journée, mais sans doute un peu en vrac dans les idées.

James Halliday aka Substack

Substack, le mec qui code même dans son sommeil (jetez un œil à sa timeline), nous a parlé de... plein de choses. Je suis pas sur de pouvoir en ressortir le propos exact, mais j'ai beaucoup apprécié le personnage et la session de questions-réponses qui a suivi son intervention.

Il a commencé à nous parler de comment réussir à avoir une application web qui puisse fonctionner complétement offline, avec le mode online qui soit simplement un bonus. Pour ça, on passe par un cache manifest, qui définit la liste des éléments qui doivent être gardés pour le mode offline. Et si on veut aller encore plus loin, on mets carrément le cache manifest dans le cache manifest, comme ça on est sur que notre appli ne se connectera pas.

Il a ensuite énoncé quelque chose de très vrai : un site offline est le meilleur moyen d'avoir un scaling infini. Zero requête vers le serveur, pas de problème de charge, il peut y avoir une infinité de personnes qui utilisent le site en même temps, cela n'influera en rien sur ses fonctionnalités.

Il a développé, comme à son habitude, un ensemble de modules pour aller dans cette direction. L'un d'eux utilise localStorage pour garder un historique des anciennes versions du site directement dans le browser. Il est ainsi possible de revenir à des versions de la veille ou de la semaine dernière à partir du moment où on les a déjà téléchargé une fois.

S'en vient ensuite la question de l'authentication quand on n'a pas de serveur distant ? En utilisant les méthodes de crypto définies dans crypto.subtle, on peut réussir à faire une grosse partie de l'authent directement dans le browser.

Il a finalement parlé d'un autre de ses modules, forkdb, qui semble fonctionner comme un database key/value, mais où chaque value contient un hash des metadata de son historique, permettant d'établir une chain of trust (à l'instar des bitcoins), permettant de rejouer l'intégralité des modifications apportées à la valeur. Cela permet de faire des bases de données décentralisées, qui tournent individuellement sur les browsers de chacun, touchant la même source de données, mais qui peuvent se réconcilier plus tard car l'ensemble des transactions est gardé en mémoire et peut être rejouée.

Au final je dois bien avouer que j'ai pas tout compris aux applications concrètes de tout ça, mais ça donnait quand même envie !

Pour finir, dans les questions-réponses dont je parlais il lui a été demandé comment il faisait pour être aussi productif. Sa réponse est sans appel :

Facile, je n'ai pas de boulot. Si vous voulez commencer à être productif, quittez votre job.

En vrac sur d'autres questions, notamment sur npm :

Npm c'est un peu comme une décharge publique. Tout le monde y mets plein de choses, des choses qui marchent, d'autres qui marchent pas, et parfois, en fouillant bien on trouve des pépites. Comme dans tout langage, il faut une énorme quantité de mauvais code pour avoir du bon code. C'est pour ça que les artistes qui font des chefs d'œuvres vivent dans des taudis en bordel. Au final ce n'est pas une question de langage, de si on mets des parenthèses et des points-virgules ou non, c'est une histoire d'écosystème de développeurs et de communauté.

Vraiment, un chouette type !

Charlie Robbins

Ensuite, Charlie Robbins, de Nodejitsu nous a parlé de npm aussi, mais d'un point de vu statistique. Il a analysé les repos npm pour faire de l'analyse statistique dessus et savoir les modules les plus utilisés comme dépendances, les versions les plus stables (ie. utilisées par le plus de packages), celles qui présentent le plus de failles de sécurités, etc.

Le gars est sans doute très fort pour faire des statistiques sur des données de type graph (et ses slides sont très jolis), mais concrétement je n'ai rien tiré réellement de cette présentation.

Justin Meyer

Justin Meyer nous a quand lui un peu éloigné du code et s'est rapproché des humains derrière les écrans. Il a effectué lui aussi quelques stats, à plus petit échelle, sur les projets sur lesquels il a travaillé durant les dernières années. Il a ensuite noté chacun des projets selon des tas de critères (sortie dans les temps, effort de dev, nombre de bugs, etc) et pour chacun il a vérifié s'ils possédaient telle ou telle carac (test unitaire, module loader, documentation, user testing, etc).

Il a ensuite mis ces informations en regard pour en déduire les éléments qui influent le plus dans la réussite d'un projet, afin de créer une checklist des choses à faire pour s'assurer un maximum de chances de réussites.

L'idée est très intéressante, mais comme son initiative vient à peine de commencer, il n'avait pas vraiment de réels chiffres à sortir sur les éléments les plus influençants. Néanmoins, en prenant quelques pincettes avec les chiffres (calculés sur un petit échantillon), on arrive quand même à isoler les éléments suivants comme ayant été des facteurs clés du succès du projet :

• user testing
• design documentation
• shared vision and roadmap
• release in less than 6 months
• social events

Domenic Denicola

Domenic, nous a ensuite parlé de JSDom. Selon lui, le meilleur moyen d'apprendre comment quelque chose fonctionne est de le recoder... en Javascript. Lui et d'autres ont donc recodé le principe du Document Object Model en nodejs, de manière à pouvoir parser un arbre HTML (et le CSS/JS qui en découle) sans avoir besoin d'un browser.

Un peu dubitatif au démarrage quand à l'utilité d'un tel projet, je suis finalement resté bluffé par le niveau de maturité de JSDom et je pense que je l'utiliserai si le besoin s'en fait sentir (pour éviter d'utiliser tout une stack de browser quand juste le DOM est nécessaire).

Ils réimplémentent complétement les API natives du DOM (document, window, HTTPRequest, etc). Le cas d'usage le plus courant est pour faire du rendering complet coté serveur. On lui passe un input HTML, du JS et du CSS à coté, et on peut ensuite requêter le DOM pour obtenir les listeners, les styles, etc.

Basé sur JSDom, il existe aussi zombie.js qui permet d'aller un peu plus loin pour simuler un navigateur. On peut par exemple simuler le remplissage de formulaire. Il semble que la bibliothèque soit pas mal utilisée pour tricher sur les jeux en ligne.

Afin d'être au plus proche de la spec officielle du DOM, ils ont développé un outil qui accepte en input un fichier de spec au format webidl, et qui le transforme en un fichier de classe JSDom en Javascript. Comme ça, il est (presque) inutile de comprendre la spec pour pouvoir l'implémenter.

Angus Croll

Angus Croll nous a fait passer un très bon moment avec un talk extrèmement intéressant intitulé "Code & Literature". Pour lui, Javascript est un langage très souple qui permet de faire énormément de choses, et qui permet aussi de faire la même chose d'énormément de façons différentes. Pour éviter de trop se disperser, on a inventé des best practices, qui fonctionnent dans la majorité des cas. Mais quand on rencontre un edge case imprévu qui va nous forcer à casser ces règles, on ne sait pas forcément comment faire car on n'a jamais appris qu'une seule manière de faire.

Lui nous incite à tester, à jouer avec le code, à essayer. Javascript nous permet de faire les choses de manière impérative, object ou fonctionnelle, profitons-en. Ça ne suivra peut-être pas les guidelines et ne sera peut-être pas propre selon les standards du projet, mais ça nous fera apprendre des choses. Il n'y a qu'en essayant quelque chose d'inconnu qu'on peut apprendre.

Lui aussi est d'accord sur ce que disait Substack : il faut beaucoup de mauvais code pour avoir du bon code. C'est une phase d'apprentissage obligatoire, et il ne faut pas perdre de vue le coté fun de l'apprentissage. Et les styleguides ne sont que des indications à un moment donné pour un projet donné, elles évoluent dans le temps et dans l'espace.

Par exemple, on considérait avant les notations if (!!x), fn && fn() ou (function(){...}()) comme étant des bad smell, alors qu'aujourd'hui on les considère comme des syntaxes tout à fait valides, pour peu qu'on sache bien les utiliser. Le niveau des codeurs de JS a évolué, et ce qui était considéré comme des syntaxes ésotériques fait aujourd'hui partie intégrante du langage.

Javascript est un langage à part entière, dont il faut comprendre les subtilités. Au début on semble être en terrain connu, la syntaxe est facile, qu'on vienne de Java ou de C, on s'y retrouve. Puis on commence à plonger un peu plus et on se rends compte qu'on n'avait vu que la partie émergée de l'iceberg et que tout le "weird shit" se trouve caché en dessous. Et tout à coup, tout semble compliqué. Alors on se barde de plein de bonnes pratiques et de jshint et jscs et on se pense en sécurité. Mais on perds le fun.

Playing is learning. C'est en essayant de faire les choses différement qu'on apprends. Les développeurs autodidactes sont souvent les meilleurs, parce qu'ils ont fait des erreurs, et comprennent ce que cela implique, ce qui fonctionne et ce qui ne fonctionne pas. Ils peuvent penser à des alternatives, et continuent de s'amuser.

Mike McNeil

Mike McNeil, créateur de SailsJS, nous a parlé de machines. J'ai pas pris énormément de notes sur cette conférence, donc je la fais essentiellement de tête.

L'idée des machines est de définir les méthodes de ses modules sous forme d'objet, qui contiennent effectivement dans une clé la méthode en elle-même, mais surtout pas mal de metadata sur la méthode autour. On peut par exemple y ajouter des méthodes de preinput ou postoutput pour sanitizer le contenu ou le formatter d'une certaine manière. On peut aussi y définir les différents arguments, en indiquant des exemples, et une petite phrase de documentation.

En faisant ainsi, on se rajoute une couche supérieure d'abstraction au dessus de nos méthodes, mais on y gagne un moyen simple de faire de la documentation auto-générée et qui sera forcément à jour (pas comme des annotations sous forme de commentaire qui finissent toujours pas être désynchros).

L'idée parait intéressante, à condition que ces objets soient "compilés" finalement en JS (et hop, encore un preprocesseur de plus dans le pipe).

John-David Dalton

John-David Dalton, créateur de lodash, nous a parlé des shims et des bibliothèques et pourquoi une bibliothèque est supérieure.

Il commence par balayer tout un tas d'a-priori qu'on peut avoir sur les implémentations natives dans les browsers. Comme quoi la syntaxe est plus simple, que les perfs sont meilleures, qu'il n'y a pas besoin de compilation spéciale ou que les implémentations sont stables. Tout ceci n'est pas vrai et il donne quelques exemples sur plusieurs browsers.

Ensuite, il s'attaque aux shims (qui consistent à définir manuellement des méthodes pour combler les trous des browsers, mais de laisser l'implémentation native si elle existe). Les shims sont une bonne solution, mais qui n'est pas parfaite selon lui. Notamment, on subit les régressions de performance qui peuvent apparaitre entre les versions des navigateurs. Mais surtout, on risque de casser des implémentations si on remplace un prototype natif par notre propre version, lors des futures versions où ce prototype sera implémenté.

Pour lui, la meilleure solution est d'utiliser une bibliothèque, qui elle s'assure d'être compatible entre tous les navigateurs. Lodash implémente la même API qu'underscore, mais avec un axe particulier sur la performance. Pour avoir regardé le code source des deux librairies, celui d'underscore est parfaitement lisible et clair et on aurait tous pu l'écrire. Celui de lodash est bien plus complexe car même s'il expose la même API les rouages internes passent par des optimisations bien plus importantes.

En plus de ça, lodash offre du sucre syntaxique pour les appels les plus courants des méthodes et permet de chainer et de fusionner les itérations map, filter et take. Si vous souhaitez par exemple prendre les 10 premiers éléments de votre liste qui matchent tel critère après être passé par telle transformation alors lodash s'arretera dès qu'il aura trouvé les 10 élements. Avec underscore ou une autre implémentation classique, on aurait du itérer trois fois sur le même set (une pour la transfo, une pour le filter et une pour n'en prendre que 10).

Soledad Penades

Démos de web audio, en jouant sur les pitchs et la fréquence. J'avoue que j'ai pas énormément de souvenirs de cette présentation.

Joe McCann

Joe McCann nous parle d'optimisations de V8, le moteur qui fait tourner node. Pour lui, il y a deux types d'ingénieurs; ceux qui se demandent "comment ça marche ?" et ceux qui se demandent "qu'est-ce que je peux construire avec ça ?". Lui se situe dans la première catégorie et a plongé dans les rouages de V8 pour nous remonter quelques astuces d'optim de perf.

V8 est extremement intelligent et va s'occuper de faire la majorité des optimisations tout seul. Néanmoins, il y a moyen de l'aider en le mettant sur la bonne piste.

Déjà, définir des fonctions qui acceptent toujours le même nombre d'arguments, et toujours de même type va lui permettre d'optimiser la mémoire allouée. Quand on défini des objets, il est plus intéressants de définir l'objet, avec toutes ses clés (même null ou undefined) plutot que de définir un objet vide et d'ajouter ensuite les clés à la main. Ensuite, il faut favoriser les tableaux d'élements de même type (éviter de mixer des int, string et objets par exemple), ce qui parait assez évident. Dans le même ordre d'idée, V8 parvient plus facilement à optimiser les fonctions nommées que les fonctions anonymes, même si elles sont directement invoquées.

Mais surtout, là où l'optimisation devient plus obscure c'est sur la taille (en caractères) d'une fonction. En effet, par défaut, si une méthode fait moins de 600 caractères (commentaires inclus) V8 va la garder en mémoire directement plutot que d'avoir un pointeur vers sa définition. Joe nous a fait quelques démos en grossissant artificiellement la taille d'une méthode en ajoutant simplement des commentaires et en la jouant des millions de fois. La différence entre les deux était flagrante (de 1 à 10s).

Cette limite de 600 chars est paramétrable en passant un flag à V8 à l'initialisation (--max_inlined_source_size). Et il est aussi possible de changer cette limite on the fly directement dans une appli node (par exemple sur une route donnée), en utilisant la syntaxe (étrange) %SetFlags() qui permet de passer l'instruction directement à la couche C depuis le js.

Paul O'Shannessy

Paul nous a parlé de React. React est le V du trigramme MVC et vient de chez Facebook. Initialement, il s'appellait XHP, un enfant illégitime entre PHP et XML.

Le principe de React est d'avoir des composants d'UI réutilisables et qui sont uniquement responsables de l'affichage de leur data. La donnée arrive forcément d'en haut. Le composant recoit sa nouvelle donnée, mets à jour son affichage.

Honnêtement, plus j'entends parler de React et plus j'ai envie d'essayer. Ça me semble une manière tellement élégante d'isoler ses composants UI tout en leur gardant une logique simple. Le composant n'est pas responsable de la donnée, ce n'est pas lui qui en garde une copie, il est juste notifié de son changement et se doit de se mettre à jour en fonction.

Mon résumé de React ne lui fait hommage, mais on mettra ça sur le compte de la fatigue à la fin de l'écriture de ce CR.

Julien Lecompte et Yehuda Katz

Je n'ai pas parlé des interventions de Julien Lecompte et Yehuda Katz car je n'ai pas pris de notes à ce moment (fatigue, manque de batterie de laptop ? je ne me souviens plus de la raison).

Julien nous a parlé du YUI framework, de son histoire et de ce qu'il est devenu. Yehuda nous a parlé de la difficulté de maintenir des projets open-source et de les faire monter de version majeure sans s'aliéner toute la communauté (transparence, rétro-compatibilité, eat your own dogfood, open-source rapidement). Même s'il ne l'a pas nommé, tout ce qu'il indiquait était l'exact opposé de ce qu'Angular est en train de faire pour sa v2.

Conclusion

Beaucoup de sujets ont été abordés durant cette journée, sans qu'il ne soit possible de donner une ligne claire. Autant à dotScale il était évident que le gros sujet était Docker tellement toutes les présentations en parlaient, autant là tout le monde parlait de choses différentes : du backend, du frontend, des browsers, des serveurs, des outils de builds, des processus, etc.

Je retiendrai particulièrement les interventions de Substack et Angus Croll comme étant les deux moments forts de la journée. Je noterai cependant la totale absence d'Angular dans cet événement. Seul Yehuda en a parlé sans le citer, comme quoi, Angular et Javascript restent deux mondes différents.

Tags : #dotjs

Want to add something ? Feel free to get in touch on Twitter : @pixelastic