Le 2 décembre dernier a eu lieu la seconde édition de dotJS, à laquelle j’ai eu l’occasion d’assister.
Au programme : outils, tricks et visions d’avenir.
Yo Polymer – Addy Osmani (@addyosmani)
Créateur de Yeoman, Addy Osmani est venu présenter son nouveau projet : Polymer, basé sur Web Components. Il le décrit comme une bibliothèque permettant de créer de nouveaux composants facilement et donc de simplifier le code HTML. Son utilisation est limitée aux navigateurs « modernes ».
C’est un projet probablement intéressant et qui a visiblement suscité un certain intérêt. À suivre, donc !
Type dependence – John K. Paul (@johnkpaul)
Cette présentation fut l’occasion de parler rapidement de quelques outils de qualité de code pour JavaScript et de qualité de code en général. En quelques mots, John K. Paul préconise :
- des outils de vérification de syntaxe (grunt-jsvalidate, Google Closure) et de « bonnes pratiques » (linting) ;
- l’utilisation systématique du strict mode ;
- un outil d’analyse statique de code « à la Sonar », Plato ;
- des règles de formatage strictes du code (quitte à ajouter un hook au sysème de gestion de version pour refuser du code qui ne s’y conformerait pas) ;
- utiliser TypeScript au lieu de JavaScript pour bénéficier du typage.
Sans être personnellement convaincu par TypeScript, ses autres propositions ont le mérite d’être concrètes, facilement applicables et efficace.
<iframe> – Remy Sharp (@rem)
La balise <iframe> n’a pas bonne réputation et n’est pas des plus facile à utiliser. Remy, lui, en utilise quatre sur jsbin. Très vraisemblablement addict, il nous a présenté les cas pour lesquels l’utilisation d’un <iframe> était un atout :
- la réduction de la priorité des composants Flash (ce qui permet par exemple d’éviter à la publicité de se maintenir au-dessus du menu déroulant de votre site) ;
- l’exécution de requêtes cross-domain ;
- le maintien de la « propreté » des objets window et documents.
Growing a Language for Graphics – Nicolas Garcia Belmonte (@philogb)
En partant de GLSL, un DSL utilisé dans WebGL, Nicolas Belmonte a évoqué le standardisation de la surcharge des opérateurs en JavaScript. Malgré des années de discussions, celle-ci n’a toujours pas aboutie.
JS performance in the browser’s world – Dave Methvin
Ce fut la première conférence de la journée sous Windows. Blague à part, Dave Methvin a illustré un audit de performances sur une application front-end en JavaScript. Audit qui, précise-t-il, se déroule comme l’audit de performances d’une application « normale » : on ne fait pas les choses comme un gogole et on regarde AVANT de commencer là où ça pèche.
Il propose pour cela un certain nombre d’outils :
- webpagetest.org (waterfall diagram) ;
- Google page Speed ;
- YSlow ;
- Chrome timeline tab ;
- IE responsiveness tab.
Quels moyens se donner pour s’assurer (ou du moins pour ne pas les dégrader) de bonnes performances ?
- éviter au maximum le forced layout ;
- dans les très exceptionnels cas où ils sont inévitables, en mesurer les performances ;
- reverse-engineerer le code des bibliothèques pour identifier et corriger les algorithmes mal codés (lents).
Quelques remarques à noter :
- les performances peuvent ne pas être les mêmes d’un navigateur à l’autre (on peut observer une lenteur sur l’un mais pas sur l’autre) ;
- l’une des causes de lenteurs les plus fréquentes est… la publicité (qui vient avec un script bloquant).
The need for speed – Guillermo Rauch (@rauchg)
Le pitch tient en une phrase : ce n’est pas tant la rapidité de l’application qui compte mais le sentiment de rapidité perçu par l’utilisateur. Pour un temps de réaction de l’application de 0,1 seconde (ou moins !), l’utilisateur n’est pas gêné. Jusqu’à une seconde, le feedback n’est pas nécessaire. Les spinners ne sont à utiliser que dans une très forte minorité de cas, (ils font teeeeellement web 2.0) notamment les cas critiques (le processus de déconnexion par exemple : il faut s’assurer que l’utilisateur va bien jusqu’au bout pour ne pas risquer qu’un autre utilisateur utilise sa session derrière lui).
Dans cette optique, tous les moyens sont bons pour donner une impression de réactivité. C’est pour cette raison que les applications iOS proposent une capture d’écran au démarrage le temps que l’application démarre effectivement. Il vaut mieux afficher quelque chose qui ne sert à rien que de ne rien afficher du tout.
Module frontiers – James Burke (@jrburke)
Créateur de Require.js, James Burke a présenté la modularisation du code telle qu’il l’envisageait.
Dart – Nicolas Geoffray
Lars Bak n’a pas pu être présent pour cette édition de dotJS. Pour le remplacer, Sylvain Zimmer et Alexis Moussine-Pouchkine ont contacté Nicolas Geoffray, également membre de l’équipe de Dart, deux jours avant l’événement. Il fait partie de ces gens à qui vous pouvez vous plaindre de la présence de point-virgules dans le langage.
Nicolas ne sachant pas dire non, il a accepté de remplacer Lars Bak. Il a également accepté de regarder Wolverine avec ses enfants. C’est donc devant sa télévision qu’il a rédigé ses slides, tout en expliquant le film à ses enfants et en leur parlant de Gangnam style. Après quoi, il s’est senti vieux. Plus ou moins dans cet ordre.
Bref. Sur les cinq dernières années, le web a beaucoup évolué. Les outils, les langages, eux, n’ont pas suivi. La productivité du développement est devenue un goulet d’étranglement (note : on est en contradiction avec la conférence de Guillermo Rauch… qui a raison ?). D’où la création de Dart.
Contrairement aux idées reçues, Dart n’est pas réservé à Chrome. Il existe certes une VM dédiée à Dart (que vous pouvez tester sur Dartium, la version de Chromium l’embarquant), mais Dart se compile également en JavaScript. Sa compilation a été pensée sous trois aspects :
- taille minimale ;
- rapidité d’exécution ;
- conservation de la sémantique de Dart (ce qui explique qu’un simple Hello World « compilé » en JavaScript pèse 2,5 ko).
Practicing safe script – Alex Saxton (@SlexAxton)
C’est par une énumération d’attaques réussies qu’Alex Saxton commence sa présentation. Injection de contenu (tout le monde a un ami qui s’appelle <script>alert('pwned')</script>), white space attack, token CSRF… une liste tout aussi ludique qu’inquiétante.
Pour renforcer la sécurité des applications, deux méthodes sont proposées. All you have to do is never make a single mistake. Facile. Mais, encore plus facile, l’application d’une série de bonnes pratiques peut également s’avérer efficace :
- blocage du JavaScript inline ;
- blocage de l’utilisation de la commande eval ;
- blocage des appels cross-domain (JavaScript, CSS, images, polices…) ;
- le report des violations (directive report-uri à spécifier) ;
- l’utilisation de listes blanches au lieu de listes noires (tout ce qui n’est pas explicitement autorisé est interdit) ;
- l’utilisation systématique d’une couche de transport sécurisée (HTTPS).
Sans proposer de pistes pratiques, cette présentation aura au moins l’avantage de sensibiliser les développeurs aux risques encourus par leurs utilisateurs.
Making JavaScript more learnable – Pamela Fox (@PamelaFox)
Comment faciliter l’apprentissage du JavaScript ? C’est la question que s’est posé Pamela Fox à Khan Academy. Elle a identifié trois points majeurs : le design du langage, son débogage et sa documentation.
L’usabilité du JavaScript n’est pas des meilleures. Certaines choses ne sont, selon elle, pas nécessaires. Que a++ soit un synonyme de a+=1, lui-même synonyme de a = a + 1 en est un bon exemple.
Le débogage est facilité par jsHint (entre autres outils) mais ses messages sont difficiles à comprendre pour un débutant. Au message « Expected identifier », un message plus conversationnel de la forme « Ne manque-t-il pas une variable ou une constante ? » faciliterait l’identification des erreurs. Nous sommes donc tous incités à proposer des formulations plus claires, mais aussi à en proposer des traductions dans un maximum de langues (apprendre JavaScript et l’anglais, c’est important, mais faut-il apprendre les deux simultanément ?).
Enfin, la documentation est bien souvent insuffisante ou insuffisamment accessible aux débutants pour être utilisable. Ici aussi, nous sommes encouragés à la compléter chaque fois que cela est possible.
The web evolution in action – Brendan Eich (@BrendanEich)
Brendan Eich, CTO de Mozilla, est également à l’origine de JavaScript. Autant dire qu’il était attendu. Avant d’envisager le futur, il rappelle ses fondamentaux : la souveraineté de l’utilisateur. *Don’t lock user. Empower user. *Et voici la porte d’entrée pour Firefox OS qui, entièrement basé sur des technologies web standardisées, serait le meilleur (le seul ?) candidat à cette libération. JavaScript est vu comme le « langage final » vers lequel tout converge ou vers lequel tout doit converger.
Alors que la norme ECMAScript 6 n’est pas encore sortie, il évoque déjà le partenariat avec Google (pour Dart) et Intel pour ECMAScript 7 avec la volonté d’embarquer efficacement les autres langages (en citant dart2js).
