DotJs 2018: un petit résumé
Le 9 novembre 2018, au dock Pullman de Paris, a eu lieu la dotJs. Cet événement rassemble chaque
année la communauté de développeur JavaScript à travers le monde en proposant seulement un
seul track mais avec comme speakers beaucoup d’acteurs majeurs ou représentatifs. Le tout
entrecoupé de ligthning talks de 5 minutes.
année la communauté de développeur JavaScript à travers le monde en proposant seulement un
seul track mais avec comme speakers beaucoup d’acteurs majeurs ou représentatifs. Le tout
entrecoupé de ligthning talks de 5 minutes.
Cela fait depuis 2014 que je vais aux différentes éditions, et si je devais comparer celle-ci aux autres,
je dirai qu’elle m’a déçue. Surtout par rapport à l’édition de 2017 qui était pour moi fantastique.
Notamment des sujets comme l’usage du machine learning pour l’accessibilité, sur comment
s’assurer que son site est accessible, sur pourquoi certaines choses disparaissent dans nos
navigateurs pour éviter des failles, ou encore une personne qui a expliqué comment en NodeJs
intercepté et comprendre les données de positions des avions et de les afficher.
je dirai qu’elle m’a déçue. Surtout par rapport à l’édition de 2017 qui était pour moi fantastique.
Notamment des sujets comme l’usage du machine learning pour l’accessibilité, sur comment
s’assurer que son site est accessible, sur pourquoi certaines choses disparaissent dans nos
navigateurs pour éviter des failles, ou encore une personne qui a expliqué comment en NodeJs
intercepté et comprendre les données de positions des avions et de les afficher.
Si je devais résumer les points négatifs: je trouve que les speakers et les sujets n’étaient pas au
niveau des autres sessions. En fait, la plupart des sessions n’étaient pas techniques. Mais elles
ne parlaient de philosophies, de besoins ou d’approches: elle parlait des passions des différents
speakers, sans que cela nous apporte beaucoup de choses à notre quotidien.
niveau des autres sessions. En fait, la plupart des sessions n’étaient pas techniques. Mais elles
ne parlaient de philosophies, de besoins ou d’approches: elle parlait des passions des différents
speakers, sans que cela nous apporte beaucoup de choses à notre quotidien.
Voir même certains speakers n’allaient au fond de leurs démarches et donnaient plus une impression
de “je viens pour me faire voir”. Je pense notamment au talk de John Papa qui m’a vraiment frustré
car son sujet est intéressant: comment choisir son framework. Et en somme il dit …
“débrouillez-vous, c’est pas facile”. En faisant des clins d’oeils appuyés sur Angular sur lequel
il travaille et qu’il s’est fait connaître, notamment via ses guidelines.
de “je viens pour me faire voir”. Je pense notamment au talk de John Papa qui m’a vraiment frustré
car son sujet est intéressant: comment choisir son framework. Et en somme il dit …
“débrouillez-vous, c’est pas facile”. En faisant des clins d’oeils appuyés sur Angular sur lequel
il travaille et qu’il s’est fait connaître, notamment via ses guidelines.
Néanmoins, tout n’est pas à jeter et voici un résumé des talks qui m’a le plus marqué.
Sacha Greif - The state of JavaScript
Sacha Greif est un développeur français travaillant au Japon et qui a développé un outils se
nommant https://surveyjs.io/ permettant de faire des questionnaires. Et ces dernières années,
il l’utilise pour demander aux développeurs de ce qu’ils pensent de JavaScript à l’heure actuelle.
Ils consolident les réponses et cela donne https://stateofjs.com/.
nommant https://surveyjs.io/ permettant de faire des questionnaires. Et ces dernières années,
il l’utilise pour demander aux développeurs de ce qu’ils pensent de JavaScript à l’heure actuelle.
Ils consolident les réponses et cela donne https://stateofjs.com/.
En somme il nous donne les tendances 2018 des frameworks et des habitudes des développeurs
JavaScript, et certains résultats sont étonnants (mais à la fois logique):
https://2018.stateofjs.com/introduction
JavaScript, et certains résultats sont étonnants (mais à la fois logique):
https://2018.stateofjs.com/introduction
Première, TypeScript explose littéralement, et c’est d’autant plus flagrant que ceux qui ont
commencé à l’utiliser ne peuvent plus s’en passer. Et en soit également une bonne nouvelle:
de plus en plus de personnes se sont penchés sur ES6 et l’ont complètement adopté.
commencé à l’utiliser ne peuvent plus s’en passer. Et en soit également une bonne nouvelle:
de plus en plus de personnes se sont penchés sur ES6 et l’ont complètement adopté.
Au niveau frameworks frontend, sans surprise, React reste le leader. Et là où les résultats sont
surprenant, c’est que beaucoup de monde aimerait utiliser Vue.js à l'occasion. En revanche
beaucoup de gens ont utilisés Angular … et ne souhaitent plus l’utiliser par la suite !
surprenant, c’est que beaucoup de monde aimerait utiliser Vue.js à l'occasion. En revanche
beaucoup de gens ont utilisés Angular … et ne souhaitent plus l’utiliser par la suite !
Ceci est vraiment significatif. Car même si AngularJs est beaucoup moins structurant qu’Angular,
il est beaucoup plus facile de prise en main et de mise en production. La stack technique nécessaire
pour maîtriser Angular dernière du nom est importante et le framework n’est vraiment pas simple,
ni sur les tests, ni sur certains fonctionnalitées comme la transclusion, etc…
il est beaucoup plus facile de prise en main et de mise en production. La stack technique nécessaire
pour maîtriser Angular dernière du nom est importante et le framework n’est vraiment pas simple,
ni sur les tests, ni sur certains fonctionnalitées comme la transclusion, etc…
Pour le reste, je vous invite à aller sur https://2018.stateofjs.com/introduction/
Tobias Ahlin - Minecraft is getting a JavaScript runtime
Ici, le sujet partait d’un défi: pouvoir faire en sorte de développer une application qui puisse
fonctionner sur un grand ensemble de devices en utilisant un langage pivot qui serait JavaScript.
Et l’application n’est plus ni moins que Minecraft.
fonctionner sur un grand ensemble de devices en utilisant un langage pivot qui serait JavaScript.
Et l’application n’est plus ni moins que Minecraft.
Tobias Ahlin explique sa démarche et du choix de JavaScript (versus coder en natif) en expliquant
ques les utilisateurs auront moins de considérations sur le “feel native” pour un jeu que sur une
application classique. Car en effet, le layout d’un jeu n’a rien à voir (ni à faire) avec le design du
device sur lequel il tourne.
ques les utilisateurs auront moins de considérations sur le “feel native” pour un jeu que sur une
application classique. Car en effet, le layout d’un jeu n’a rien à voir (ni à faire) avec le design du
device sur lequel il tourne.
Ainsi, avec son équipe, ils ont mis en place une API JavaScript afin de facilement recréer le monde
Minecraft (et aussi pour tous les plugins):
https://minecraft.gamepedia.com/Bedrock_Beta_Script_Documentation.
Minecraft (et aussi pour tous les plugins):
https://minecraft.gamepedia.com/Bedrock_Beta_Script_Documentation.
Et également, ils nous ont montré comment faire en sorte que leur application fonctionne sur tous les
devices, via HummingBird.Le but est d’intégrer dans son application un engine JavaScript qui
pourra fonctionner sur tous les devices. Cet engine a néanmoins quelques “inconvénients”, car ne
permet pas d’utiliser toutes les fonctionnalités HTML, CSS et JavaScript. Par exemple, nous ne
pouvons pas utiliser les “float” CSS. Mais c’est un “plus”, car cela allège l’engine, évite de possibles
bugs d’interprétations tout en utilisant les fonctionnalitées modernes du monde du Web. Ainsi, un
code fonctionnant sur HummingBird fonctionnera sur les navigateurs récents.
devices, via HummingBird.Le but est d’intégrer dans son application un engine JavaScript qui
pourra fonctionner sur tous les devices. Cet engine a néanmoins quelques “inconvénients”, car ne
permet pas d’utiliser toutes les fonctionnalités HTML, CSS et JavaScript. Par exemple, nous ne
pouvons pas utiliser les “float” CSS. Mais c’est un “plus”, car cela allège l’engine, évite de possibles
bugs d’interprétations tout en utilisant les fonctionnalitées modernes du monde du Web. Ainsi, un
code fonctionnant sur HummingBird fonctionnera sur les navigateurs récents.
Anders Helsberg - TypeScript
Ancien développeur au sein de C#, il mène désormais le développement et l’amélioration de
TypeScript.
TypeScript.
Il a ainsi pris le temps de nous expliquer en quoi TypeScript est un outils intéressant (principalement
pour le typage) mais aussi désormais sa polyvalence en autorisant d’étendre la syntaxe et d’aller
plus loin dans le checking du code.
pour le typage) mais aussi désormais sa polyvalence en autorisant d’étendre la syntaxe et d’aller
plus loin dans le checking du code.
Mentions spéciales
J’ai personnellement deux mentions spéciales, car c’est autour de deux ligthning talks. La plupart du
temps, c’est dernier sont simplistes à cause de leur durée de 5 minutes.
temps, c’est dernier sont simplistes à cause de leur durée de 5 minutes.
Même si certains étaient vraiment curieux, car nous dire qu’on peut faire des points d’arrêts dans le
navigateur pour débugguer (ce qui me semble être la base de tout développeur Web), il y a en
revanche deux qui se sont radicalement sorti du lot, et un troisième sympa.
navigateur pour débugguer (ce qui me semble être la base de tout développeur Web), il y a en
revanche deux qui se sont radicalement sorti du lot, et un troisième sympa.
L’un de Joost Lubach est autour du code asynchrone. Le sujet en tant que tel est très couru. C’est
surtout le format sous forme d’une animation autour d’un client qui commande un burger. C’était
vraiment didactique et ludique que vous pouvez retrouver ici: http://slow-burgers.joostlubach.com/
surtout le format sous forme d’une animation autour d’un client qui commande un burger. C’était
vraiment didactique et ludique que vous pouvez retrouver ici: http://slow-burgers.joostlubach.com/
Je peux citer ensuite Sam Wray qui nous expliqué et expliquer l’usage du OffscreenCanvas, qui
permet donc de dessiner dans un Canvas depuis les WebWorket et des performances que cela peut
amener. Notamment en synchronisant sur 30 écrans des animations qui se coordonnent en fonction
de la musique (ce qui était vraiment bluffant).
permet donc de dessiner dans un Canvas depuis les WebWorket et des performances que cela peut
amener. Notamment en synchronisant sur 30 écrans des animations qui se coordonnent en fonction
de la musique (ce qui était vraiment bluffant).
Enfin, je vais citer Jeremias Menichelli avec son sujet “gimme your content punk”. Le but étant de
nous sensibiliser autour des chargement des WebFonts et des techniques à exploiter afin de ne pas
ralentir le chargement des pages (comme utilisé une font par défaut en attendant celle souhaitée.
nous sensibiliser autour des chargement des WebFonts et des techniques à exploiter afin de ne pas
ralentir le chargement des pages (comme utilisé une font par défaut en attendant celle souhaitée.
En vrac
Voici la liste des autres conférences avec un avis éclair.
Lauren Tan - Strongly typed: ici le but était de montrer que le typage aider et était important pour
tout ce qui est programmation fonctionnel. Ce talk m’a déçu car il aurait mieux value renommer en
“Strongly typed with functional code”, car pendant un grand moment, elle nous a expliqué ce
qu’était le typage et c’est à la fin qu’elle introduit la notion de programmation fonctionnelle et de
l’intérêt d’utiliser avec le typage fort.
John Papa - Choose framework: Comme dit plus haut, il voulait essayer de nous guider sur le
choix de frameworks frontend à faire. Du coup, la seule chose qu’il nous dit et de faire une
application comme lui (tour of heroes), de tester tous les frameworks … et c’est tout. Vraiment
décevant car il aurait pu apporter une démarche aux choix en listant un ensemble de besoins et /
ou de critères afin de nous aider à faire le choix. Un comparatif des différents frameworks auraient
pu être un plus, mais avec le prédicat précédent, cela aurait suffit à nous aider.
Kurt Mackey - We built a runtime: Ici, le speaker explique qu’il voulait mettre en place un CDN.
Et comme le critère principale est que cela soit le plus rapide possible, il a donc expliqué qu’il a testé
plein de choses comme LUA, Golang, Go + divers engine JavaScript, Rust, NodeJs … et qu’à la fin,
il a fait sa propre solution: https://fly.io/. Intéressant, mais il n’est pas assez loin dans sa démarche
Tara Manicsic - HTTP2: Encore un talk pour dire que http/2, c’est bien et qu’il faut l’utiliser … En
revanche, une section était intéressante sur le prise de recul sur certaines fonctionnalitéesn et
notamment sur le “Event Push” qui serait dans la prochaine version dépréciée car ne répondant pas
vraiment aux besoins.
Felix Rieseberg - Performance JS for Electron: développeur chez Slack, il utilise au quotidien
ElectronJs et nous faire part de points d’attention afin d’améliorer son application. J’avoue que la
quasi totalité est déjà le cas pour nos applications Web. La seule vraiment intéressante (qui est
possible sous ElectronJs et qui se fait sur des plateforme comme Android), et que lorsque la visibilité
de l’application change, c’est de désactiver les tâches de fonds.Ceci serait possible dans nos
navigateurs mais pas encore trop démocratisé:
Myles Borins - Top level awaiting: très intéressant mais très très technique et difficile à expliquer.
En somme, en tant que TSC director de NodeJS, il explique le cheminement de l’implémentation
des async/await sous NodeJs, et des problèmes suscités notamment quand nous l’utilisons au
niveau le plus haut (dès le départ de son code). Il a nous expliqué ainsi les rouages internes de
NodeJs et des discussions qui a eu lieu tout autour.
Devin Lindsey - Robot Rocks: développeuse qui s’est amusé à faire danser des robots ensembles.
La seule chose à retenir: utiliser cyclon.js et que ce n’est pas facile… (c’est ça qui est dommage,
elle n’est pas assez loin en expliquant les soucis que nous rencontrons et comment les résoudre).
Au final
Pour moi, je trouve cette session moins bien que les autres car peu de sujets intéressants ou qui se
démarquent. La question est maintenant de voir si cela reste exceptionnel, d’autant plus qu’il y a eu
une annonce majeure: l’année prochaine, la dotJs sera en deux jours. Une dédié pour le monde
frontend. L’autre backend.
démarquent. La question est maintenant de voir si cela reste exceptionnel, d’autant plus qu’il y a eu
une annonce majeure: l’année prochaine, la dotJs sera en deux jours. Une dédié pour le monde
frontend. L’autre backend.
Si vous voulez voir les photos, c’est par ici.
Commentaires
Enregistrer un commentaire