Jazoon, Working effectively with JavaScript

Cette séance est donnée par Thomas Schank, de ZHdK, l’université des arts de Zurich.

 
Premier sujet abordé, pourquoi JavaScript?

• Il est partout, dans les navigateurs, les serveurs avec NodeJS, les bases de données avec Riak, CouchDB ou MongoDB.
• Les tendances sur stackoverflow.com montrent une augmentation croissante de l’activité avec ce langage.
• Il permet de casser les architectures monolithiques (présenté dernièrement à QCon).

Le langage

Nous faisons ensuite les inévitables quiz sur ce langage surprenant :

"Foo" -1 => NaN

mais

"Foo" + (-1) => "Foo-1"

0.1 + 0.2 != 0.3

parseInt("07") == 7

mais

parseInt("08") == 0

undefined != false

et

false !=null

mais

undefined == null

C’est ce que ressort Douglas Crockford dans son célèbre livre Javascript: The Good Parts : « Le manque de transitivité est alarmant! »

Il nous rappelle ensuite les bases du langage, la portée des variables, les fonctions, les closures. En JavaScript, les objets ne sont qu’un ensemble de clés/valeurs. Il n’y a pas à proprement parler de classes, mais des prototypes. Les fonctions constructeurs sont des illusions et ne devraient pas être utilisées.
En JavaScript, il n’y a pas de thread mais qu’une seule ligne d’exécution. Faire attendre un traitement peut carrément bloquer un serveur ou un navigateur. La meilleure façon reste encore d’utiliser setTimeout.
On se sert alors fortement des closures, avec le paradigme « Continuation Passing Style ». On passe à chaque fois un callback qui sera appelé plus tard. Cette technique peut, dans certains cas, conduire à la création de pyramides de callbacks incompréhensibles. Des sucres syntaxiques, notamment avec Coffeescript, permettent d’améliorer la lisibilé avec ce style de programmation.

Thomas ne croit pas à l’idée d’utiliser JavaScript comme langage intermédiaire pour une machine virtuelle. De par sa souplesse, ce langage rendrait la liaison unique du code généré vers le code source impossible dans certains cas.

Les framework populaires

Vient ensuite le temps d’analyser les frameworks.

• GWT
  C’est très populaire mais il n’est pas partisan. Il cite Thoughtworks, « GWT is a reasonable implementation of a poor architectural choice ». Comme ça, c’est dit. => NOGO

• Coffeescript
  C’est du JavaScript, avec les mauvaises parties en moins. Chaque programmeur qui essaie ne peut plus revenir à du JavaScript seul. Il n’a qu’un conseil=> GO GO GO. C’est pour lui la meilleure réponse aux quelques dangers du langage.

• JQuery
  C’est un framework simple qui fait simplement son boulot et bien. => GO GO GO.

• Les framework MVC
  Thomas nous confie qu’il n’en utilise pas encore. C’est pour le moment naissant, trop de framework sortent sur le marché chaque semaine. Il serait dangereux d’engager de gros développement sur des technologies qui ne seraient pas maintenues dans trois mois. => WAIT

• DART
  Il se positionne aussi négativement sur ce langage développé par Google pour remplacer JavaScript dans les navigateurs. Il faudrait au moins dix ans pour aller vers une telle révolution. On a donc encore le temps de voir arriver un concurrent. => WAIT

Conclusion

Thomas termine sa présentation selon deux points de vue.

D’un point de vue technique, écrire du JavaScript non-trivial est une affaire sérieuse. Maîtriser les fondamentaux de la programmation fonctionnelle (encore elle !) s’avère vital. Ne surestimons pas nos capacités dans ce langage. Il nécessite de réelles compétences.

D’un point de vue management, le code écrit en JavaScript mérite les meilleurs développeurs, pas les moins bons. Certaines organisations sont peu regardantes sur le niveau de compétence des développeurs avec ce langage. Il est pourtant très facile d’écrire un code non-maintenable, illisible et rempli de bugs sans connaissance approfondie de JavaScript. Selon Thomas, les bons développeurs coûtent 20% plus chers mais sont 2000% plus productifs.