Un retour sur dotJS 2013

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.

Photo de clôture des speakers de dotJS 2013

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)

Voir la présentation

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)

Voir la présentation

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 :

Growing a Language for Graphics – Nicolas Garcia Belmonte (@philogb)

Voir la présentation

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)

Voir la présentation

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)

Voir la présentation

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)

Voir la présentation

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)

Voir la présentation

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)

Voir la présentation

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).

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*