On commence par Matthias qui nous fait une intro à React pour ceux qui ne connaissent pas. Ça tombait bien, je ne connaissais pas et ça m'a bien donné envie d'essayer.
Le principe de React est de simplifier la conception des UI, où tout est devenu trop compliqué au fil des années. On avait un simple serveur qui nous renvoyait du HTML au début, maintenant on a des SPA qui vont chercher seulement leurs données depuis le serveur et doivent mettre à jour leur markup en fonction.
Avec React, tout est un composant. Chaque composant possède sa propre méthode render qui doit retourner un markup HTML qui sera inséré dans le DOM. L'avantage d'avoir une simple méthode comme ça pour chaque composant c'est que c'est facile à tester unitairement. Les composants sont simples, petits, isolés, et les méthodes sont donc faciles à tester.
Le composant possède aussi un état, une liste de variables internes qu'il peut modifier en réponse à certaines actions de l'utilisateur ou recevoir depuis un parent. Ces variables sont privées, et lui permettent de choisir les modifications à appliquer au markup.
Le moteur de template de React utilise une syntaxe jsx, qui est croisement entre du XML et du Javascript, ce qui fait un peu peur au premier abord. Mais c'est juste du sucre syntaxique, React arrive avec son pre-processeur qui transforme ce jsx dans nos fichiers js en du vrai js. Le pre-processeur arrive avec quelques autres goodies d'ES6, et sans doute aussi dans le futur avec des annotations, du type checking, etc.
Du coup, on a un vrai moteur de template, qui est tout simplement du js. On peut y faire des conditions, des boucles, du map, reduce, bref tout ce qu'on veut faire en js sans devoir passer par une complexe syntaxe de template. Il est donc là inutile de réinventer de la logique dans un autre langage.
React continue sur sa lancée de simplification en faisant en sorte que tout soit explicite. Ici, pas d'API polymorphe à la jQuery où les getters et les setters se mélangent. On a même certaines fonctions qui sont déconseillées (comme ajouter directement un innerHTML), et qui possèdent donc des noms bien flagrants pour montrer qu'on fait quelque chose de mal quand on les utilise (dangerouslySetInnerHTML).
Pour revenir rapidement sur la méthode render, qui est le cœur de React, on a aussi autour la méthode shouldComponentUpdate, qu'on peut overrider pour indiquer au moteur que non, là, vraiment, c'est pas la peine de faire un nouveau rendering du component, je sais qu'il n'a pas bougé. Dans le même ordre d'idée, on a accès aux events willMount, didMount et willUnmount pour lancer du code custom à différents moment de la vie d'un composant.
React possède un très puissant algo de rendering, qui va checker le retour du render d'un composant et de tout ses sous-composants pour savoir s'il doit mettre à jour ou non son rendu. Il batche toutes les modifications ensemble jusqu'au prochain rendering du browser, et rajoute un petit algo de diff pour la route.
Autre parti-pris, qui va dans le sens de la simplification, il n'y a pas d'héritage dans React, il n'y a que de la composition à base de mixins. On défini des méthodes qu'on pourra implanter dans différents composants, quels qu'ils soient (comme réagir à un event de scroll ou de resize par exemple).
React s'abstrait du DOM officiel aussi en réimplementant pas mal de choses, mais en le faisant ainsi de manière cross-browser. Il réimplémente par exemple le principe d'event capture et event bubbling, tout seul. Il en profite pour rajouter une petit optim de perf dans l'histoire; plutot que de repasser une nouvelle instance de l'objet event à chaque intermédiaire, il recycle toujours la même liste de x objets qu'il passe à chacun des handlers.
Idem, il possède sa propre représentation du DOM pour savoir quand faire des updates, qu'il appelle le virtual DOM (et je crois qu'ils utilisent JSDOM, mais pas sur).
Globalement, j'ai été convaincu par React et j'ai bien envie d'essayer sur un prochain projet ou side-project. La simplicité avec laquelle on peut gérer notre affichage simplifie pas mal de chose. Le markup n'est plus du tout source de la donnée, il se concentre juste sur afficher les choses d'une manière ou d'un autre quand elles changent. Les algos de diff, super simples à coomprendre, permettent de s'assurer qu'on ne render par les choses pour rien, et les exposer sous forme de méthodes testables rends le truc encore plus attractif.
Je pense que ça s'incruste facilement dans un projet Backbone, mais que ça doit être la bonne galère de le passer dans de l'Angular.
Isomorphic JS
La seconde présentation, de Yannick Croissant, nous parlait de Javascript isomorphique, ou de comment générer la même application en front comme en back. Bon, j'avais déjà assisté à son atelier à ParisWeb sur le même sujet, du coup j'ai surtout écouté d'une oreille distraite et n'ai pas pris de notes.
Néanmoins, de mémoire il était question des problèmes que cause le fait de partir en mode SPA.
Déjà on duplique de la logique de code entre le back et le front, ce qui est particulièrement flagrant au niveau des validations de formulaires. On veut fournir une expérience riche, du coup on ne veut pas perdre du temps avec des appels serveurs pour vérifier la validité d'un champ de formulaire, et on veut les tester rapidement en local, en y déportant des règles métiers. Mais on ne peut pas non plus l'enlever du backend pour des raisons de sécurité. On se retrouve donc souvent à coder deux fois la même chose, des deux cotés. Au début de NodeJS on pensait que le fait d'avoir le même langage des deux cotés allait permettre d'éviter de coder deux fois les choses, mais le langage n'a pas grand chose à voir là dedans, la question est plus générique au niveau de l'archi.
Avoir une appli SPA pose aussi de gros problèmes en terme de référencement. Même si Google comprends le JS, ou même si on peut faire des hacks à base de phantomJS pour générer des pages statiques à servir aux robots crawleurs, ça reste des pansements sur des jambes de bois. Le modèle n'est pas adapté.
React permet de solutionner ce problème de manière assez élégante. Le serveur génère un HTML à servir au client, incluant du React, qu'il peut lui même instancier et modifier, comme s'il tournait dans un browser. C'est un état initial qui est servi au client. Puis toutes les mises à jours suivantes sont simplement de nouveaux retours de l'API qui vont déclencher des mises à jour de la vue dans le client. Si on reload complétement la page, la nouvelle page rendue par le serveur retournera un nouvel état de départ, mais encore une fois les nouvelles modifs se feront sous forme de diff. On a là une approche incrémentale, qui permet des affichage de page plus rapides.
On touche là au meilleur des deux mondes. Sur une url données, dans un contexte donné, notre serveur nous donnera un HTML parfaitement formé, parfaitement adapté pour le crawling, le SEO, l'accessibilité, etc. Si le navigateur est en mesure d'executer React, il peut mettre à jour la vue de manière incrémentale en redemandant les nouvelles infos au backend, qui peut se permettre de la lui retourner de manière simple sous forme de data.
React, CSS in JS
Le dernier talk était de Chistophe Chedeau, de chez Facebook (et sans doute connu de certains d'entre vous pour son boulot sur Curse Gaming). Il nous a présenté React depuis sa création jusqu'à ce qu'il est aujourd'hui.
L'idée principale derrière Reacte était de simplifier la codebase de Facebook. Des milliers d'ingénieurs qui bossent sur du front-end en même temps, avec des compétences en HTML/CSS très variées. Il n'y a pas vraiment de dev front chez Facebook, tous les devs travaillent sur toutes les parties, qu'elles soient back ou front. Du coup, ils ont souhaité abstraire au maximum certaines parties du markup pour limiter les erreurs, et simplifier le développement.
Un des problèmes majeur de CSS qui se fait ressentir sur une codebase comme celle-là, c'est que tout dans CSS est globales. On definit une classe, elle va s'appliquer partout dans le markup. Certes on peut préfixer un selecteur pour le rendre plus precis, mais on n'est jamais sur à 100% d'avoir une isolation parfaite. Un autre dev peux, consciemment ou non, overrider nos styles. En utilisant une méthode comme BEM, on peut limiter ce problème mais alors on rends le code extremement difficile à minifier, avec des classes à rallonge sur presque tous les éléments.
Le second problème majeur est qu'il est très difficile de supprimer du code. Il n'y a pas de couverture de code comme dans d'autres langages qui pourrait être déduite par des tests unitaires. Quand on supprime du CSS, on ne sait jamais réellement ce qu'on va casser.
Et pour finir, ils souhaitaient un moyen simple de pouvoir partager des constantes entre PHP, Javascript et CSS (un code couleur, un nombre d'éléments à afficher, un flag de feature flipping, etc).
Ils ont donc planché sur un moyen de créer des composants isolés, qui chargent leurs propres dépendances, qui ne se fassent pas overrider par l'extérieur et qui ne puissent pas non plus le faire.
Leur action principale, pour obtenir ce pouvoir, a été de convertir le CSS en Javascript. Tout simplement en React, ils n'écrivent pas leurs propriétés de style dans du CSS mais dans des objets JSON (légérement améliorés avec quelques helpers). Cette partie m'a un peu fait peur, et a continué à me suprendre dans le reste de la présentation. Finalement, après en avoir discuté avec d'autres devs qui font déjà du React régulièrement, cette approche n'est pas obligatoire et est même rarement employée : on continue d'utiliser des classes pour le style.
Bref, ces propriétés JSON/CSS sont ensuite appliquées directement en style= sur les éléments du markup. L'avantage de cette méthode barbare est qu'on est certain qu'on ne pourra pas se faire overrider par d'autres classes (style a la prio la plus forte), et comme on ne déclare pas de classe, on ne va rien overrider à l'extérieur non plus. C'est assez malin.
De plus, ils en profitent pour "optimiser" certaines règles au passage (si on ne mets pas d'unité, c'est des px par défaut par exemple) ou comportement (un display:none en React va carrément supprimer le nœud du DOM).
En fait, pas mal de comportements du DOM classique sont recodés en Javascript en React. Quand j'ai vu les onMouseEnter / onMouseLeave pour recréer le :hover j'étais assez dubitatif quand même. Le speaker annoncait que le fait d'être particulièrement explicite de cette manière rendait le code plus simple à comprendre. Je suis pas vraiment convaincu à premier abord, mais pourquoi pas. Par contre, là où je le rejoins c'est que ça rends le code de rendu vraiment plus facile à style. On peut écrire des tests unitaires qui vont pouvoir manuellement passer un élément en :hover et tester un comportement en allant regarder le contenu de l'objet de style.
Il a fini par nous expliquer deux-trois autres optimisation que le moteur de React opère. Pour moi, ce n'est rien de plus que ce que le moteur natif du browser execute, mais qu'ils ont recodé à la main, et ce qui leur permet de s'affranchir des différences d'implémentations entre navigateurs. Je ne sais pas trop quoi penser à ce sujet. Certes ça permet de simplifier le dev et d'offrir la même expérience à tout le monde, mais ça fait réinventer la roue.
Plus le talk avancait et plus les démonstrations allaient dans ce sens et j'en suis sorti en me demandant où ça allait exactement. Vjeux lui même annonçait que React était jeune, qu'ils ne s'attendaient pas à ce qu'il prenne autant d'ampleur en dehors de Facebook et qu'ils expérimentent des choses, mais que tout ne sera peut-être pas bon à garder.
Conclusion
Premier avant-gout de React, j'ai été assez séduit par la simplicité qui s'en dégage. La dernière conférence m'a laissé plutot dubitatif (comme à chaque fois qu'on essaie de remplacer CSS par JS parce que "CSS c'est trop compliqué").
Cette session des HumanTalks avait lieu chez nous, chez Octo. Je me suis occupé de l'organisation, du coup j'ai pas beaucoup eu l'occasion de voir les présentations en elle-mêmes. Du coup, mon résumé sera un peu moins touffu que d'habitude (ouf! dirons certains).
De l'idée au projet
On a tous des idées de projets qu'on a envie de faire sur notre temps libre. Mais la plupart du temps, on profite d'avoir les coudées franches pour aussi partir sur de bonnes bases, et en profiter au passage pour apprendre de nouvelles technos. Finalement, on se retrouve avec une toute nouvelle stack, qu'on ne connait pas du tout, on apprends sur le tas, on découvre les outils, et deux semaines plus tard on a juste mis en place la stack technique et on n'a pas commencé le projet en lui-même.
Du coup, Jonathan Beurel vient lui nous parler des pièges à éviter dans ce cas, et comment aller droit au but de ce qu'on veut construire. Lui, sur son projet perso, il a repris les briques qu'il utilise déjà tous les jours au boulot et qu'il maitrise : Vagrant, OpenStack, Capistrano, Angular & Node. Son hébérgement, il le fait facilement avec les GitHub Pages, et il utilise au maximum l'écosystème as a service: SaaS, IaaS, PaaS.
Pour sa base de données, il a donc testé Firebase et Parse. Son retour d'expérience c'est que c'est difficile de rajouter de la logique métier avec Firebase, alors que c'est très facile avec Parse, sous forme de hooks Javascript. Malheureusement pour lui, Parse fournit un SDK simple pour Backbone mais pas pour Angular.
Pour le déploiement, il a utilisé Codeship. A chaque push sur son repo, il execute les tests, et si les tests réussissent, il execute un script de déploiement.
Au final, il a du js à tous les étages de sa stack et utilise un maximum d'outils en -aaS pour mettre en prod. Ça lui fait gagner beaucoup de temps et il utilise ce que d'autres ont déjà fait, pour lui se concentrer sur les fonctionnalités propres à son idée.
Protobuf
Pour le coup là, j'ai été occupé toute la présentation à réceptionner les pizzas, je n'ai malheureusement rien vu !
Formateur indépendant, mais où est Charlie?!
Mathieu Robin, formateur indépendant depuis peu nous parle de l'aventure que c'est de se lancer dans la formation tout seul. Pour lui il y a de grosses arnaques dans le milieu de la formation, avec un budget de 14 milliards fourni par l'État pour les formations en entreprises. D'après lui, il suffit d'attester avoir participé à une formation, et que le formateur atteste l'avoir donné, pour toucher un part du gateau. Il a donc voulu en faire parti...
Des clients l'appellent pour lui demande des formations, mais sans savoir exactement la date, la durée, le nombre de personne. En gros, il faut être prêt à partir en formation rapidement.
Pour être officiellement reconnu comme formateur, il faut un numéro de SIRET, ce qui est facile à obtenir, mais il faut aussi un numero d'agréement de formation, qu'on n'obtient qu'une fois qu'on a fait une vraie formation, payée par une société. Le soucis étant que tant qu'on n'a pas fait cette formation, la société paye le prix fort, il est donc très difficile de faire cette première formation.
Mathieu Segret, co-fondateur de l'organisme de formation HumanCoders a rajouté un mot à la fin, pour aller dans son sens. Passer formateur nécessite de naviguer dans un vrai dédale administratif. Chez HumanCoders ils ont automatisé un maximum de choses pour remplir automatiquement les papiers au format PDF, ce qui leur rends la vie plus agréable.
Meteor
Ici aussi, je n'ai pas pu assister à la présentation, trop occupé à préparer le buffet pour discuter après coup.
Conclusion
Dommage pour moi, je n'ai pu voir qu'une partie des talks, pris dans l'organisation. J'ai pu un peu discuter après coup aussi, et on a bien mangé (avec de beaux gateaux d'anniversaire des HumanTalks).
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.
Vendredi après-midi avait lieu la première conférence dotCSS. Comme d'habitude pour les dot conferences, le lieu était magique. Cette fois-ci, au théatre des variétés, sur les grands boulevards.
La demi-journée a été riche en informations autour de CSS, depuis sa création, jusque son futur, les choses bizarres qu'on peut faire avec, les outils qui tournent autour et son intégration au sein d'une équipe aux compétences diverses.
Le talk d'ouverture était de Daniel Glazman, co-chairman du W3C. Il a rappellé qu'il était "juste" co-chairman, et pas co-boss. Que ce n'était pas lui qui prenait les décisions finales quand à l'orientation du web, mais qu'il avait plus un rôle d'huile entre les différentes pièces, un facilitateur de débats (souvent houleux).
Le W3C est un consortium de représentant de sociétés privées et des grands acteurs du web, de fabricants de navigateurs, de sites à fort traffic, de fabricant de hardware, etc. Ils se mettent d'accord pour donner un axe de travail pour l'amélioration des technos du web (CSS entre autres). Mais chaque membre a son propre planning, ses propres objectifs et le rôle du W3C est de réussir à trouver un compromis qui conviennent à tout le monde. Et parfois, ces consensus donnent quelque chose d'hybride qui ne convient réellement à personne.
Retrospectivement, on peut dire que plusieurs erreurs ont été faites lors de la création de CSS selon ce principe. Par exemple la fusion des marges, le principe du box-model, ou la complexité à réussir à centrer verticalement du texte. Pour leur défense, il faut bien avouer que CSS était initialement prévu pour donner un peu de style à des rapports académiques, à du texte pur et dur, pas à faire des mises en pages complexes dépendantes de la résolution d'écran, de la vitesse de la bande passante et de la densité de pixels comme on lui demande aujourd'hui.
Glazou a terminé par nous présenter, non sans trolls, les prochaines shiny features de CSS. Les tant attendues variables arrivent enfin ! Sauf que c'est pas exactement des variables, ce sont des Custom Inherited Properties qui ne sont donc pas globales, mais qui cascadent depuis un élément parent vers ses descendants.
Pour aligner du texte verticalement, on a le fantastique flexbox qui permet de faire les mises en pages les plus folles au prix d'une syntaxe complexe avec X propriétés différentes pouvant prendre Y valeurs possibles.
Et puis, il y a le nouveau sélecteur :matches() qui est plus du sucre syntaxique et qui permet de simplifier l'écriture de certains sélecteurs (par exemple :matches(section, article) :matches(h1, h2) plutôt que d'écrire section h1, section h2, article h1, article h2.
Dans le même ordre d'idées, des améliorations à :nth-child() sont dans le pipe, pour pouvoir préciser un sélecteur afin de ne compter que certains éléments.
On parle aussi d'une syntaxe proposée pour pouvoir sélectionner un élément autre que celui qui se trouve en bout de chaine d'un sélecteur. Aujourd'hui on peut écrire div p pour sélectionner tous les paragraphes dans des divs, mais on ne peut pas écrire de sélecteur pour sélectionner tous les divs qui contiennent des paragraphes.
Mais les modifications sans doute les plus importantes à mon sens seraient de pouvoir avoir accès au moteur de parsing CSS, en read-only, depuis Javascript. Ne plus être obligé de reparser les règles CSS à la main pour calculer la taille d'une font en pixels ou la valeur d'une couleur à un point x au milieu d'un linear-gradient. Puisque le parser CSS a déjà fait ce travail, il serait bon qu'on puisse y accéder directement.
Une très bonne intro, aussi bien tournée vers le passé que le futur, pour commencer ces conférences dotCSS !
Bridging the gap between developers and designers
Le second speaker faisait parti de ces nombreux speakers français qui ont fait l'effort de présenter en anglais pour l'auditoire en grande partie non-francophone. Kaelig travaille aujourd'hui au NY Times après avoir bossé au Guardian.
Sa présentation n'était pas réellement technique, mais portait plus sur la manière de faire en sorte que les développeurs front et les designers travaillent mieux ensemble. Il est indispensable pour lui que cela passe par un partage d'un langue commune. Que quand un designer indique que le header doit être "gris clair", il n'y ai pas d'ambiguité sur quel gris il faut utiliser.
Pour cela, ils utilisent une feuille recensant toutes les couleurs utilisées dans leur site, en donnant un nom à chacun (du type neutral-1, corporate-color, etc) et la valeur hexadécimale qui va avec. En faisant ainsi, designers et développeurs parlent bien toujours des mêmes couleurs et se sont créés un dictionnaire de mots partagés. Le nom de la couleur que les designers emploient à l'oral pour discuter entre eux est aussi le nom de la variable dans les fichiers CSS. La communication entre les deux mondes est alors grandement simplifiée.
Ils appliquent le même principe pour les fonts, en créant une matrice des différentes combinaisons de font/size utilisées, en les réferencant par leur fonction comme par exemple heading-3 ou maintext-2. Ici aussi, le vocabulaire des designers a été uniformisé, et les mêmes termes sont utilisés dans les feuilles de styles, ce qui aide en plus à développer directement en peer programming designer/developer dans le browser.
Pour les breakpoints RWD, même histoire, ils ont arreté de mettre des valeurs en em dans leurs media-queries car cela n'évoque rien à la lecture. A la place, ils ont créé des mixins qui peuvent être facilement comprises à la lecture et ont abstrait les détails en dessous. Par exemple, mq(from:tablet), mq(from:phone, to:tablet), mq(until:tablet).
Niveau grille, même combat, création de helpers pour pouvoir rapidement définir "je veux trois colonnes, mais en desktop en avoir 7". Le code SCSS directement lisible exprime bien cette intention, on a des helpers pour définir des règles différentes pour phone et desktop, et on exprime avec d'autres helpers le nombre de colonnes qu'on souhaite. Toute la complexité de largeur de colonnes, largeur des marges, breakpoints est cachée dans ces mixins (qui sont le territoire des devs), alors que l'intention est exposée un niveau plus haut (territoire partagé dev/designer).
Le fait de partager la même langue pour parler de la même chose aide à la cohésion de l'équipe et à l'appropriation du projet. Il est plus facile de modeler le code pour qu'il suive les idées du designer que de remodeler le designer pour qu'il parle comme du code. En partageant tout cela entre les deux territoires, on augmente l'appropriation du code par les designers et l'appropriation du design par les devs.
D'après lui, dans un projet web, il vaut mieux avoir une connaissance générale de tous les métiers qui vont prendre part au projet, plutôt que d'être expert uniquement de la partie qui nous concerne. Dans cette optique, il nous a donné 10 conseils pour ne pas perdre de vue l'essentiel. Plusieurs de ses conseils se recoupaient, je vais donc les synthétiser.
Tout d'abord, l'option la plus simple est souvent la meilleure. Plus on va vite, moins ça coûte cher au client. Le meilleur code est l'absence de code, plus on écrit de code, plus on écrit de PPOF (Potential Point of Failure). En réduisant la complexité d'une solution, on la rends plus légère et donc plus facile à comprendre, à apprendre à quelqu'un, à maintenir et à débugguer. Une solution simple aura moins tendance à casser, et nécessite moins d'overhead du codeur pour la comprendre. "Le mieux est l'ennemi du bien", il vaut mieux avoir quelque chose de good enough aujourd'hui, que quelque chose de parfait demain.
Ensuite, il ne faut pas oublier l'objectif. Le code n'est qu'un outil pour atteindre cet objectif. Il est nécessaire de comprendre ce qui coûte et ce qui apporte de la valeur au client, afin de ne pas lui faire perdre d'argent. Pour cela, il est nécessaire d'aller voir les autres personnes, d'autres métiers qui travaillent sur le même projet. Le travail d'un intégrateur web n'est pas de reproduire des PSDs, enfermé dans sa bulle avec son casque sur les oreilles. Il lui faut aller voir les autres, et faire ce qui est bon pour le produit final.
Finalement, il ne faut pas être trop attaché à son code. Le code est jetable et s'il est modulable il est facile d'en jeter un morceau en gardant le reste. Les demandes du projet vont changer régulièrement, il faut être prêt à accepter le changement, à jeter du code, à en écrire du nouveau. Dans le même ordre d'idée il est inutile de prévoir à l'avance tout les cas particuliers, car ils n'arriveront peut-être jamais, peut-être la fonctionnalité va-t'elle changer en cours de route.
Keep Calm and Write Sass
Hugo Giraudel nous a ensuite parlé de Sass, avec une liste de bonnes pratiques et de choses à ne pas faire. Il a aussi abordé un peu le tooling autour de Sass.
Sass est un preprocesseur CSS, qui apporte des briques habituellement trouvées dans les langages de prog : variable, conditions, boucles, fonctions, etc. C'est assez facile de vouloir en faire trop avec Sass, juste parce qu'on peut le faire. Mais ça ne sert à rien, et il faut rester KYSSS (Keep Your Sass Simple and Straightforward).
Il ne faut pas oublier que Sass permet de se positionner une couche au dessus de CSS, et qu'il permet donc d'exposer des méthodes pour générer du CSS. Il faut que ces méthodes soient peu nombreuses, avec une API publique simple. Ici, les bonnes pratiques du Clean Code habituelles s'appliquent : des noms explicites, des comportements devinables, pas des tas d'arguments différents pour gérer plusieurs cas de figures différents, etc.
Sass incite aussi au nesting de sélecteurs à outrance. C'est très facile à faire en Sass, mais ça donne des feuilles de styles finales avec des sélecteurs bien trop précis et bien trop difficiles à overrider. Il faut limiter au maximum le niveau de nesting.
Finalement, il a évoqué plusieurs outils comme scss-lint qui est un linter de fichiers Sass, sassdoc qui permet de générer une documentation HTML avec des exemples à partir de fichiers source Sass et enfin True qui permet de faire des tests unitaires sur les retours des fonctions Sass.
Et la dernière conférence à laquelle j'ai pu prendre des notes avant que la batterie de mon laptop et les neurones de mon cerveau ne lachent fut celle d'Estelle Weyl.
Estelle nous a montré quelques astuces tout droit tirées des coins les plus reculés du monde du CSS. Tout d'abord, grâce à counter-increment, il est possible de garder un compteur en CSS. Par exemple la page actuelle de sa présentation était indiquée grâce à ce système, et elle nous a montré comment afficher le nombre d'erreurs d'un formulaire rien qu'avec du css.
Elle nous aussi rappellé qu'il existait un grand nombre de pseudo-selecteurs dans la même veine que :valid et :invalid mais qu'ils ne sont pas encore correctement implémentés partout (notamment :default et :placeholder-shown).
On a ensuite fait un petit rappel des spécificités des sélecteurs (récapitulé sous forme de poisson sur Specifishity, et appris que les sélecteurs >, +, ~ et :not() n'ont aucune spécificité. Donc div p a le même poids que p + p et img pèse aussi lourd que :not(img). Il est bon de le rappeller.
Elle a ensuite parlé de l'horreur absolue qu'est !important dans du CSS, qui permet d'overrider toutes les autres règles et qui est lui-même impossible à overrider. Mais elle a aussi donné une astuce pour réussir à overrider un !important... astuce que je ne donnerai pas ici, vous pourriez avoir envie de l'utiliser ! :)
Pour finir, elle nous a montré un moyen de faire du browser sniffing directement depuis le navigateur, pour peu que celui-ci supporte @supports (recursive joke inside). En testant des propriétés prefixées -webkit ou -moz on peut comme ça appliquer certaines règles uniquement à un moteur de rendu ou un autre. Pas sur que ce soit une brillante idée, mais ça peut dépanner.
Fin des talks
Les trois derniers talks étaient de Nicolas Gallagher qui nous a parlé de comment ils ont modularisé leur UI chez Twitter, en utilisant des Web Components. Ce qu'il mettait en avant faisait echo à pas mal de choses dites précedemment : aligner les developpeurs et les designers sur un langage commun, masquer la complexité en dessous et laisser une API publique simple et qui exprime bien l'intention.
Bert Bos, co-créateur de CSS nous a parlé des challenges que posent les différents règles de typographie des différents pays du monde pour le CSS. Différents types de guillemets selon les langues, espaces avant la ponctuation ou non, italique qui s'applique ou non à la ponctuation, etc. C'était plus une lettre ouverte pour sensibiliser à ces questions.
Et finalement Ana Tudor nous a complétement bluffé en nous faisant faire des cos et sin pour dessiner des tracés chromatiques à coup de boucles en Sass.
Conclusion
Toutes ces conférences l'ont très bien rappellé : le langage CSS est riche, et il est possible de faire des choses formidables avec, mais il est aussi complexe à comprendre et demande de s'y plonger avec sérieux. Nous devons mettre en œuvre pour CSS toutes les bonnes pratiques que nous utilisons déjà pour les autres langages : modularisation, clean code, API publiques, tests unitaires.
Cela est d'autant plus important que le CSS est la partie partagée entre les développeurs et les designers, et celle-ci se doit d'être la plus claire et robuste possible pour la cohésion du projet au sein des équipes et sa maintenabilité sur la durée.
J'ai testé le meetup Vim pour la première fois. Ca faisait quelques fois que je voyais passer ça mais j'avais jamais eu l'occasion d'y faire un tour. Au final j'ai passé une soirée très sympa, même si ce n'était pas du tout le type de meetup auquel je m'attendais.
J'ai plus l'habitude d'aller dans des meetups où plusieurs speakers présentent devant une assemblée. Là, on était en tout petit commité (7 personnes), dans une salle équipée d'ordinateurs et d'un vidéo projecteur pour partager nos écrans.
L'idée initiale était que chacun puisse présenter les plugins ou astuces qu'il utilise. Au final, on a très vite dérivé, on a discuté, on s'est expliqué des choses et on s'est lancé des défis à la Vimgolf.
J'ai pas pu rester jusqu'au bout, pour l'apéro entre vimeurs ensuite, mais la soirée était bien sympa. Les prochains meetups semblent s'organiser pour prendre la forme de petits exercices à la Vimgolf, à faire à plusieurs pour s'entrainer et s'entraider. J'y retournerai sans doute à l'occasion, et vous devriez en faire de même si vous débutez sur vim.
