7min.

Retour sur les conférences dotJS 2017

C’est avec 1400 pairs que nous nous sommes rendus à dotJS qui se tenait comme l’année dernière au dock Pullman. Plus grande conférence JS européenne, nous sommes chaque année impatients de découvrir les différents talks et encore une fois, nous n’avons pas été déçus !

Section intitulée l-evenementL’événement 🎩

L’organisation était aussi bonne que les années précédentes (la nourriture aussi 🤗 ). La décoration très végétale contribuait à rendre le cadre agréable et relaxant, surtout pour ceux qui assistent aux conférences sur la scène, allongés dans des fatboys.

Le rythme des conférences, entrecoupé de grandes pauses et très bien animé par Christophe Porteneuve, est également un plus. Encore une fois cette année, le niveau des conférences était au rendez-vous.

Section intitulée au-programmeAu programme 🍿

Une particularité de dotJS est de ne pas donner le sujet des différentes conférences, ni l’ordre de passage des speakers. Une seule track et tout le monde dans le même bateau. Afin que vous puissiez avoir une idée des sujets abordés et sur quel cheval miser en 2018, voici une liste des thèmes abordés :

De nombreux lightning talks ont aussi ponctué l’événement: rendu serveur, développement de jeu avec React/Redux, l’API web audio ou encore GraphQL.

Stage dotJS

Un beau programme donc dans lequel quelques conférences nous ont particulièrement plus, en voici le détail !

Section intitulée async-awaitAsync + Await

Par @wesbos

Wes Bos démarre avec la première conférence et nous présente la gestion des fonctions asynchrones avec les API async et await. Fonctionnalitées déjà disponibles et discutées depuis quelques temps, Wes fait une bonne piqûre de rappel avec des exemples concrets et quelques pro-tips concernant la gestion des erreurs.

C’est maintenant supporté par défaut dans Node 8 et disponible dans votre navigateur avec le plugin babel transform-async-to-generator.

Si la conférence vous a donné envie d’en savoir plus, nous recommandons l’excellent article de Nicolàs Bevacqua « Understanding Javascript’s async await ».

Section intitulée working-well-the-future-of-web-testingWorking Well: The Future of Web Testing

Par @trentmwillis

A quoi nous sert de tester nos applications ? La réponse que nous donne Trent Willis dans cette conférence est la suivante :

Les tests doivent nous donner confiance dans le fait que nos applications fonctionnent bien.

Une application qui fonctionne bien doit selon lui satisfaire trois exigences :

  • être accessible,
  • être performante,
  • être nécessaire (pas de code inutile).

Dans la suite de la conférence, Trent nous explique comment réaliser des tests sur ces 3 axes. Voici les outils mis en avant lors de la conférence:

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-developers-google-com-web-updates-2017–04-headless-chrome-headless-chrome-a-et-le-protocole-chrome-devtoolsHeadless Chrome et le protocole Chrome DevTools

Ils permettent d’exécuter des test automatisés dans un vrai navigateur grâce à la librairie Puppeteer. Celle-ci expose une API permettant de faire dans Headless Chrome tout ce qui peut être fait manuellement. Elle permet ainsi de crawler et manipuler une page, capturer une timeline de l’exécution de la page (utile pour tester les performances) et même de prendre des snapshots, le tout en quelques lignes de code. QUnit est quant à lui utilisé pour les tests unitaires/assertions (couplé avex QUnit-in-browser) pour pouvoir être utilisé avec Headless Chrome.

###aXe-core pour l’accessibilité

Ce package permet de tester très simplement un grand nombre de problèmes d’accessibilité courants. Le code suivant (issu de la documentation du projet) suffit à vérifier qu’aucun problème d’accessibilité parmi ceux de la liste n’est présent sur la page.

axe.run(function (err, results) {
	if (err) throw err;
    ok(results.violations.length === 0, 'Should be no accessibility issues');
    // complete the async call
    ...
});

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-github-com-krisselden-ember-macro-benchmark-ember-macro-benchmark-aember-macro-benchmark

Cet outil, basé entre autres sur l’outil de benchmarking de Chrome, permet de générer un rapport de performances au niveau de l’application.

Section intitulée a-rel-nofollow-noopener-noreferrer-href-https-chromedevtools-github-io-devtools-protocol-tot-profiler-profiler-startprecisecoverage-aProfiler.startPreciseCoverage

Cette méthode qui fait partie du protocole Chrome DevTools permet d’obtenir une mesure du code usage d’une application : pour chaque bloc de code Javascript vous saurez s’il est appelé, combien de fois et où, ce qui peut être très utile pour repérer du code mort.

Nous ressortons de cette conférence avec plein de nouveaux outils à essayer, en particulier l’excellent axe-core que tous les projets devraient utiliser, et ça tombe bien puisqu’on n’a pas fini de vous parler d’accessibilité.

Section intitulée new-tools-for-old-problemsNew Tools for Old Problems

Par Suz Hinton

Suz nous a parlé accessibilité en tentant d’aborder le problème avec une vision neuve. En prenant l’exemple de l’Accessible Icon Project, qui réussit à imposer petit à petit un icône plus humanisé pour remplacer le symbole international d’accessibilité (lequel voyez-vous ? ♿️), elle introduit l’idée de « Guerilla accessibility ».

Son idée est d’expérimenter, de tester des méthodes nouvelles, afin de répandre les bonnes pratiques et rendre le monde plus accessible. Elle nous a présenté quelques uns des projets qu’elle a réalisé dont la génération de sous-titres automatiques pour ses vidéos Twitch ou encore un outil qui remplit automatiquement les attributs alt des images sur Instagram grâce au machine learning.

Section intitulée a-framework-author-s-case-against-frameworksA framework author’s case against frameworks

Par Adrian Holovaty

Il est compliqué depuis deux ans de suivre toutes les évolutions dans l’écosystème JavaScript. Adrian nous amène un point de vue controversé en se demandant si nous avons vraiment besoin d’un framework pour notre projet. Deux articles sous forme de discussion sont mentionnés pour expliquer son point de vue et je pense que beaucoup de développeurs peuvent se reconnaître en les lisant. A lire : « How it feels to learn JavaScript in 2016 and 2017 » Le deuxième est une réponse qui termine sur une note plutôt positive, en effet même s’il est plus compliqué d’être à jour, ces évolutions amènent de nombreuses fonctionnalités et un certains confort sur le développement.

Adrian prend pour exemple aussi son application Soundslice qui n’utilise aucun framework et qui a implémenté son propre moteur de rendu pour les notations musicales des tablatures de guitare. C’est une belle preuve d’un produit fonctionnel créé par plusieurs développeurs, avec comme rappel qu’il est très important d’utiliser des patterns pour éviter d’avoir une application difficile à maintenir et à appréhender pour de nouveaux développeurs.

Il termine sur une note positive en nous conseillant de garder l’esprit ouvert et de choisir ce qui correspond le mieux pour notre projet et notre équipe. Ne pas se laisser guider par la hype, mais réfléchir au meilleur moyen de construire son projet.

Section intitulée webpack-webassembly-under-the-hoodWebpack + WebAssembly: Under the hood

Par Sean Larkin

Sean effectue une entrée en scène digne d’un one man show en lançant des t-shirts webpack au public. Passé l’effet de surprise il nous présente les fonctionnements internes de Webpack en détail.

Le premier bloc est le module tapable permettant l’intégration des plugins. Ensuite viennent s’ajouter plusieurs couches:

  • Compiler: objet récupéré après l’instanciation de la configuration webpack
  • Compilation: fruit de la compilation
  • Resolver: responsable d’aller chercher les fichiers
  • Module factories: création des modules
  • Parser: transforme les modules en AST et résout les dépendances
  • Template: création du code final à partir des AST générés

C’est aussi l’occasion de révéler les prochaines features du bundler, nous pourrons ainsi profiter du support natif de WASM pour intégrer facilement du WebAssembly dans nos applications (pour rappel supporté maintenant dans tous les navigateurs). Aussi arrive le support natif du CSS, donc plus besoin de require le CSS dans notre JS pour forcer la compilation, ou encore d’utiliser le hack du extract-text-webpack-plugin.

Section intitulée getting-data-from-the-skyGetting Data From The Sky

Par Thomas Watson

Thomas fait une introduction aux ondes radios et aux différentes manières de les utiliser. Notamment le protocole de communication des avions qui broadcast constamment leur position ainsi que d’autres informations concernant l’appareil. Avec un simple récepteur d’une dizaine d’euros, il est possible d’intercepter ces communications. La démo est bluffante, avec quelques lignes de code et cet appareil Thomas affiche une carte avec la position et l’altitude de plusieurs avions autour de Paris dans un rayon de 100 kilomètres !

Une super introduction qui donne envie de bricoler avec les ondes radios. Les slides sont disponibles ainsi que le code de la démo sur GitHub à cette adresse.

Getting Data From The Sky


Section intitulée un-call-for-paper-l-annee-prochaineUn Call For Paper l’année prochaine !

Pour finir, une nouveauté pour la prochaine édition de dotJS : un CFP sera ouvert, non seulement pour les lightning talks, comme c’était déjà le cas cette année, mais aussi pour les conférences plus grand format. L’occasion peut-être de prendre une part plus active à cet événement.

En attendant, la version 2017 fut une très belle édition, encore merci à toute l’équipe dotJS pour cette journée ! 😘


Cet article porte sur la conférence dotJS 2017.

dotJS 2017

Commentaires et discussions

Nos articles sur le même sujet

Nos formations sur ce sujet

Notre expertise est aussi disponible sous forme de formations professionnelles !

Voir toutes nos formations

Ces clients ont profité de notre expertise