Publié par
Il y a 4 années · 3 minutes · Java / JEE

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.

Xavier Bucchiotty
Xavier est un développeur Java/Scala de sept ans d'expérience. Issu de la filière apprentissage, il dispose en plus de trois ans passés au sein d'un grand groupe industriel français. Cela lui confère une approche pragmatique et rigoureuse de son travail. L'alternance lui a permis d'acquérir des compétences techniques solides et concrètes. Motivé par les méthodes agiles, il affectionne les aspirations du software craftsmanship. Le virus de la programmation fonctionnelle l'a touché avec Scala puis Haskell. Fervent amateur d'Akka et du modèle acteur.

6 réflexions au sujet de « Jazoon, Working effectively with JavaScript »

  1. Publié par Cédric M, Il y a 4 années

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

  2. Publié par Cédric M, Il y a 4 années

    Bon à savoir, merci.

  3. Publié par Benoît BRIOT, Il y a 4 années

    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…

  4. Publié par Xavier Bucchiotty, Il y a 4 années

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

  5. Publié par Yannick Grenzinger, Il y a 4 années

    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

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