Les 5 et 6 décembre 2019, la dernière édition de la DotJS se tenait au Dock Pullman à Aubervilliers. Une conférence dédiée au web et plus particulièrement à son langage de prédilection, le JavaScript.
Grande nouveauté cette année, la conférence se déroule sur 2 jours avec une première journée dédiée au développement front avec que du JavaScript au menu (avec ou sans framework) et une seconde journée dédiée au langage et au JavaScript côté back (NodeJS).
What to expect from a modern web framework?
Tim Neutkens
Dans une longue introduction, Tim nous explique pourquoi il faut en 2019 privilégier les framework et librairies existantes plutôt que de partir sur du vanilla. Il devient en effet plus simple et rapide avec les frameworks récents d’initialiser un nouveau projet. Les frameworks sont accompagnés d’un tooling performant inclus dans leur CLI. Le CLI permet souvent d’initialiser le projet, de créer des nouveaux composants du projet, d’exécuter les tests (unitaires et/ou fonctionnels), de packager l’application (création de bundle optimisé), et pour certains de déployer une application sur un environnement présent dans le Cloud.
Puis il nous a fait une rapide présentation de NextJs, qui permet d’optimiser les bundles et donc d’améliorer la rapidité de l’application.
The complexity in simplicity
Sara Vieira
Le but de ce talk était d’accentuer sur l’expérience utilisateur, notamment sur les effets de bords. Voici quelques exemples :
- Les “placeholder” ne sont jamais traduits par les systèmes de traduction et ou lus par les logiciels dédiés à l’accessibilité.
- Les “select” customs ne prennent pas en compte les inputs comme par exemple quand on tape une lettre les options ne défilent pas pour aller à la proposition souhaitée.
- On a tendance à mettre des formulaires partout, notamment sur les systèmes de carte de crédit où on est capable d’automatiser le type de carte de crédit en fonction du numéro de la carte.
- On fait en sorte de rallonger les loader sur les appels sensibles car “ça ne rassure pas l’utilisateur si le paiement se fait trop vite” (Merci Paypal pour cette info).
Develop, Debug, Learn ?
par Chris Heilmann
Après un rapide “feedback” sur ces 20 dernières années de développement web, avec une certaine pointe de nostalgie ou le développeur écrivait son code, puis il le debuggait et ainsi de suite de manière itérative (Code => Learn => Debug => Code …).
Depuis l’avènement des frameworks, qui sont arrivés avec leurs outils CLI / Tests framework / … on voit de plus en plus d’outils mais au final encore environ 80% des développeurs utilisent les console.log() alors que tant d’outils sont disponibles comme l’utilisation de points d’arrêt au niveau des devtools du navigateur voir même une intégration directement dans l’IDE (VSCode, …). Les vieilles habitudes ont la vie dure.
Et il va même plus loin en utilisant des plug-in de VSCode pour utiliser le navigateur embarqué et utiliser à la fois les dev-tools mais également le debugger intégré.
https://noti.st/codepo8/7rsBH3/develop-debug-learn-a-time-to-re-think-our-tooling
Evergreen Libraries
Par Igor Minar
L’évolution des libraires Javascript s’est accélérée ces dernières années à un rythme effréné à tel point qu’on est arrivé en 2016 avec un sentiment de ras le bol chez les développeurs puis 3 librairies sont sortie du lot (React, Angular et VueJS), et nous somme alors rentrés dans un nouveau rythme : celui des migrations de framework, en effet passer d’une version A à une version B avec beaucoup de “Break Changes” a une nouvelle fois lassé un grand nombre de développeurs.
A partir de ce constat et après la migration d’AngularJs vers Angular, la core team s’est demandée quelle était la bonne posture à adopter. En effet le framework ayant été complètement réécrit, il était très difficile voire totalement impossible de mettre à jour son projet avec les bonnes versions.
Ils ont donc passé un “contrat” avec les développeurs, chaque partie prenante devant y mettre du sien pour que tout se déroule sans trop d’accrocs.
Du côté de la core team :
- ils essayent de publier 2 versions majeures par an en veillant à bien répartir les changements trop importants sans qu’il y ait de “Break Changes” entre deux versions majeures.
- ils font un très gros travail pour également automatiser la migration, pour cela ils ont ajouté il y a quelques releases déjà l’upgrade directement dans le CLI.
Du côté de l’équipe de développement :
- Mettre à jour dès qu’une version majeur sort pour minimiser les effets de bords liés à cette migration et ainsi éviter les “Break Changes” qu’il pourrait y avoir si on saute une version majeure.
Serverless Application
Par Phil Hawksworth
Présentation du Jamstack (Create fast and secure sites and dynamic apps with JavaScript, APIs, and prerendered Markup, served without web servers).
Exemple avec une application de glaces, quand on se connecte on voit la liste des glaces existantes. Il est également possible d’ajouter une nouvelle glace. A la soumission du formulaire aucun appel n’est fait coté back (car celui-ci n’existe pas) mais la base de données est simplement mise à jour. Le CI détecte cette mise à jour et vient publier une nouvelle version de l’application, version possédant la glace ajoutée.
https://noti.st/philhawksworth/hKvs2V/are-you-being-servered-exploring-a-serverless-web
State of UI Components
Par Evan You
Evan You nous explique comment les frameworks modernes tendent à délaisser les classes telles qu’on les connaît pour utiliser le plus possible des fonctions.
Un comparatif a donc été réalisé avec les forces et faiblesses de chaque solution du marché les plus populaires et qui suivent cette même mouvance, à savoir ReactJS avec les Hook, VueJS (dont il est l’auteur) qui va utiliser un système similaire mais sans avoir besoin de déclarer les éléments à rafraîchir et Svelte 3.
Sans trop s’avancer car il reste beaucoup de travail à accomplir, il prévoit une sortie de la future mouture du framework VueJS pour la fin du premier trimestre 2020, affaire à suivre.
Javascript save the world
par Asim Hussain
C’est un grand plaisir de revoir Asim qui vient aujourd’hui parler de “Green IT” et surtout comment rendre nos applications web moins énergivores.
Après une rapide introduction sur l’état de notre planète et les effets que provoqueraient une augmentation de la température sur la faune et la flore. Il nous invite à nous impliquer en tant que développeur à avoir un oeil plus ouvert sur le partage des ressources serveurs. En effet, la production d’électricité est responsable d’environ 30% des émissions de CO2 de la planète (faute à encore beaucoup trop d’électricité produite à partir d’énergie fossile).
Mais comment réduire notre impact énergétique ? En premier lieux en utilisant des fournisseurd Cloud éco-responsable (Google GCP et Microsoft Azure), mais également en mutualisant les ressources. En effet un serveur en mode IDLE consomme malgré tout 25% d’électricité par rapport à une pleine charge. Cette électricité représente beaucoup d’émission de CO2. Pour palier à ce problème la solution vient des ressources mutualisées du Cloud et plus particulièrement de functions cloud (GCP Cloud Function / Azure Function / AWS Lambda) qui ne consomme que lorsque ces dernières sont utilisé et ne consomme qu’une partie de la ressource mutualisée. Un bon moyen de s’inscrire dans une démarche “Green IT”.
Il nous invite à repenser notre infrastructure pour être plus en adéquation avec nos besoins, les coûts et la consommation énergétique de nos applications.
Exploring the hidden potential of sound data
par Charlie Gerard
Après une introduction sur l’analyse tridimensionnelle des sons via la Web Audio API, on se demande bien où Charlie veux en venir.
Et c’est là qu’intervient Tensorflow.js, elle apprend à un réseau neuronal à identifier différents sons de la vie courante. Et à l’aide de la Web Audio API et de Tensorflow, elle nous fait une démo live de son application de reconnaissance de son. Elle ne se ménage pas, l’application reconnaît lorsqu’elle parle, elle tousse, … ou elle se brosse les dents. Oui oui elle s’est brossée les dents sur scène…
Bravo pour cette démo qui nous ouvre la voie vers une infinité de possibilités…
More WebAssembly in your JavaScript / Into WebAssembly
par Sven Sauleau / Vlad Filipov
Deux talk pour nous parler d’un langage récemment officialisé comme langage pouvant s’exécuter dans un navigateur web: WebAssembly. Dans ces deux présentations, on nous parle des avantages d’utiliser ce nouveau langage: Rapidité, Sécurité, …
Pour être rapide, c’est rapide, une petite démo d’un calcul de Hash exécuter 100 000 fois est environ 100 fois plus rapide en utilisant un worker codé en WebAssembly par rapport au même calcul effectué en JavaScript. Les promesses sont nombreuses mais pour cela il va falloir se remettre (ou s’y mettre) à coder en C, C++ ou Rust. Pas sur que les développeurs Web s’y collent 🙂
Optimization
par Vladimir Agafonkin
Un talk très intéressant pour toutes les personnes cherchant à optimiser leur code et donc leurs algorithmes.
Il nous a présenté un principe très simple (qui a d’ailleurs bien fait rire la salle) pour pouvoir s’améliorer
- Trouver un endroit où notre app est lente
- Rechercher pourquoi c’est lent
- Le corriger
Ça semble évident dans un 1er temps mais c’est plus compliqué qu’il n’y paraît, surtout lorsqu’il s’agit de trouver le “pourquoi”. Son conseil est donc de ne pas hésiter à prendre de la hauteur et de regarder le problème dans son ensemble.
Par la suite il nous a présenté la notation “O” qui permet de mesurer la complexité temporelle d’un algorithme.
- O(1) : Instantané, comme par exemple une assignation, une condition etc
- O(n) : Un parcours de liste (donc votre algorithme dépend de la taille de votre liste
- O(n²) : Une boucle for imbriquée dans une autre boucle for. Ici ça commence à sentir mauvais et il faut très sérieusement commencer à réfléchir à une parade
- O(n3) : 3 boucles for imbriquées => Tout recommencer !
- O(log(n)) : Un traitement par dichotomie par exemple => Se rapproche plus du O(1) que du O(n)
- etc etc etc
Ces complexités sont vraiment très importantes car nous pouvons facilement améliorer certaines parties de notre code qu’on a un peu trop négliger !
Encore une fois la dotJs fût passionnante et nous démontre que le web continue d’évoluer, de se remettre en question et nous promet toujours plus de possibilités et de fun. Vivement l’année prochaine.
