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.

Billets sur le même thème :

6 commentaires

  • Je demande des explications pour le parseInt() :)
    Incompréhensible le parseInt()…

  • C’est une convention en Javascript. parseInt utilise la base octale s’il y a un ‘0’ devant un chiffre. Cette fonctionnalité est bien sûr dépréciée.
    http://www.w3schools.com/jsref/jsref_parseint.asp

  • Bon à savoir, merci.

  • Je sais bien que Xavier ne fait que relater la présentation de Thomas Schank, mais je trouve que cette vision manque 1 aspect crucial : Quels outils pour développer en équipe avec Javascript ? Et là GWT prend tout son sens; eclipse, maven, jenkins, junit,… Donc reprendre bêtement l’assertion de Thoughtworks me semble un peu léger pour un professeur de son rang.
    Il cite jQuery comme excellent candidat (GOGOGO) alors que c’est très loin d’être parfait (allez jeter un coup d’oeil à ExtJS ou Dojo, vous y trouverez des frameworks autrement mieux finis que jQuery).
    Voilà j’ai pas pu m’empêcher d’amener mon petit grain de sel…

  • Merci Benoît pour cette précision. Tous les commentaires sont les bienvenus. ExtJS a souvent été cité lors de ces trois jours, notamment lors de cet excellent talk :
    https://www.conftool.com/jazoon2012/index.php?page=browseSessions&presentations=show&form_session=16&CTSID_JAZOON12=wmHlIVOMA8kgsCAO17jJKbMb-5d

    Après ces quelques conférences, on se rend bien compte qu’il y a, à mon sens, une ambiguïté. On sent qu’on ne va pas se passer de JavaScript, que cela entraine beaucoup d’activité dans la communauté. Mais on est conscient de ses faiblesses et de ce qui nous en éloigne de nos langages de programmation traditionnels. Imposer un autre langage dans les navigateurs sera aussi compliqué. Jean Helou me faisait par de son retour par ce billet blog: http://evanfarrer.blogspot.ca/2012/06/unit-testing-isnt-enough-you-need.html
    Alors que faire? GWT est en effet une réponse à une problématique. Certains en discutent beaucoup. Mais il existe bien un besoin, sinon il ne serait pas tant utilisé.

  • Comment peut on comparer GWT à Coffeescript / JQuery ?
    L’un est en Java et se veut très productif (surtout si on met du Vaadin), l’autre demande une maitrise d’un langage, une grosse rigueur (le monde javascript ne pardonne pas le travail mal fait) et surement bien plus de travail.

Laisser un commentaire