Compte-rendu de la JsConf 2010 (2ème partie)

Publié par Grégory Paul, le 5/10/2010, dans Événements, Valtech

Ce billet est la 2ème partie du compte-rendu de la JsConf 2010.

J’y aborde PhoneGap, un tour d’horizon de HTML5 par Google, l’importance des standards du web et de l’accessibilité, les secrets derrière l’émulateur JSNES. Je parlerais également de JavaScript côté serveur utilisé par de larges boutiques en ligne, de Nodejs, CouchDB et de SocketIO pour ensuite conclure cet événement.


Par la suite, c’est Brian LeRoux qui a fait son show à travers “PhoneGap: Love the Web and Lose the SDK“.

PhoneGap est un environnement de développement Open Source servant à mutualiser ces développements pour téléphones mobiles, tout en utilisant les capacités natives des appareils. Lors de la JsConf, Brian en a profité pour annoncer un service de build, permettant, à partir d’une URL SVN ou d’un ZIP, de construire et d’empaqueter l’application soumise pour chaque plateforme (iPhone, Google Android, Palm, Symbian, BlackBerry).

Cette présentation est à rapprocher de celle de Sebastian Werner, “Introducing Unify – A Framework for Cross Platform Applications“, où l’idée est de construire une application pour plusieurs plate-formes mobiles. Cette présentation a malheureusement été très marketing, avec aucun exemple ou code source.


Google était présent via Paul Irish, “Developer Programs Engineer” sur Chrome, présentant “The State of HTML5 : Inaugural Address“.

Google, à travers son navigateur Chrome, ces innovations (WaveWebM, WebP, Instant Suggest, etc) pousse les frontières technologiques du web.

Cette présentation interactive, que je vous encourage à consulter avec un navigateur récent (voir nightly), est bluffante et démontre bien ce que l’on peut déjà faire dans la majorité des navigateurs actuels, ce qui pourra être fait pour demain et enfin, dans un futur plus lointain.


J’ai beaucoup apprécié la présentation “JavaScript + Web Standards II: The Quickening” de Jenn Lukas, “Interactive Development Director” chez Happy Cog et contributrice au site A list Appart.

Elle aborde la problématique et les impacts des sites ne fonctionnant pas sans JavaScript et nous présente des solutions parfois simples à mettre en oeuvre.

Selon elle, respecter les standards permet de baisser les coûts de production. Si les navigateurs évoluent, le fait de se baser sur des standards permet de s’assurer d’un comportement standard par la suite. Elle indique ensuite que, selon elle, les sites doivent absolument fonctionner sans JavaScript. Les sites web proposent majoritairement du contenu pour les internautes. Ce contenu doit toujours être accessible, même sans support du JavaScript. Le JavaScript doit permettre le “progressive enhancement”, c’est à dire qu’il doit améliorer l’expérience utilisateur mais ne doit pas être la seule façon d’accéder aux informations du site.

Il est vrai que la majorité des tests effectués par les développeurs sont fait sur IE, Firefox, Chrome, Safari, Opera mais qui teste sans JavaScript ? Très peu de monde. Et pourtant, selon plusieurs sources, il y a jusqu’à 6 % de personnes sans JavaScript. Cela peut paraître peu mais 6 % est supérieur au nombre de part de marché de Safari !

Un autre argument important est l’indexation par les moteurs de recherche. Les moteurs n’exécutent pas le code JavaScript. Aussi, si vous voulez que votre site soit indexé correctement, il doit fonctionner sans JavaScript. Une autre problématique est l’accessibilité. Le code JavaScript modifie souvent la page, ce qui pose un gros problème aux outils vocaux ou brailles. En effet, il faut leur signifier un changement dans la page, ce qui est rarement effectué.

Jenn indique que JavaScript a eu mauvaise presse en terme de sécurité. Elle se demande si cela a changé aujourd’hui. La récente faille de sécurité sur Twitter en septembre dernier prouve toujours le contraire. JavaScript peut toujours “faire mal”. Ce genre de problème incite les utilisateurs (ou du moins une certaine catégorie) à se méfier de JavaScript, voir à installer des extensions désactivant le JavaScript (noscript).

Jenn nous montre plusieurs exemples de site avec et sans JavaScript. Elle nous montre que, très souvent, il ne suffirait de pas grand chose pour que le site fonctionne, au moins en mode dégradé. Elle rappelle l’intérêt du “progressive enhancement“, c’est à dire d’avoir tout d’abord un site fonctionnel sans JavaScript (navigation fonctionnelle, envoi de formulaire) puis d’ajouter peu à peu des animations et autres améliorations dans l’expérience utilisateur. Elle nous montre un exemple d’interface qui fonctionne avec ou sans JavaScript.

L’accessibilité des éléments via le clavier est un point très important (à travers des tabindex convenablement placés par exemple). Elle permet sur certains sites d’entreprises de rendre les utilisateurs beaucoup plus productifs, en utilisant plus rapidement l’outil.

Au minimum, si votre application dépend fortement de JavaScript, il faut prévenir l’utilisateur en lui expliquant que JavaScript est désactivé et l’implication que cela génère sur le site. Un bon exemple est facebook, qui, si JavaScript est désactivé, propose de rediriger l’utilisateur sur le site mobile fonctionnant sans JavaScript.

Elle évoque ensuite le cas des animations. Celles-ci sont majoritairement réalisées sous JQuery. Or, il suffirait de déplacer ces animations via des règles CSS3 pour rendre cela accessible et utilisable sans JavaScript.



Un autre coup de coeur fut la présentation de Ben Firshman : “Lessons learnt pushing browsers to the limit“.

Ben est l’auteur de JSNES, cet émulateur Nintendo NES écrit en JavaScript. Il nous raconte qu’il est parti des sources de l’émulateur Java, sur lesquelles il a appliqué des expressions régulières pour transformer la syntaxe en JavaScript ! Il nous parle de diverses astuces, d’optimisations afin d’avoir un nombre d’images par secondes acceptables sous Chrome, Safari, Opera puis Firefox.

Je vous invite vivement à tester l’émulateur, visualiser cette belle présentation et récupérer le code source sous GitHub si comme moi, cette aventure vous passionne.


La présentation suivante fut celle d’Ulrike Mueller, intitulé “Server-side JavaScript the untold story“.

Il s’agit d’un retour d’expérience sur l’utilisation de JavaScript côté serveur pour des sites d’e-commerce à fort trafic chez Demandware.

Demandware propose à la fois une plateforme pour la personnalisation de site d’e-commerce et à la fois leur hébergement. Ils servent plus de 40 millions de pages par jour et hébergent notamment la boutique des jeux olympiques de Londres 2012, celle des snowboards Burton, la boutique Puma ou encore Nine West.

En 2004, leur solution était avant tout basé sur Java. Les principaux composants étaient la personnalisation facile et rapide de boutique d’e-commerce, de traitement de job (job processing) et d’appel Web-Service. En 2005, une refonte de l’application fut démarrée. Java fut écarté et la question s’est porté sur le choix d’un autre langage. Plusieurs options étaient envisageables à l’époque, Jython, JRuby, Groovy et Rhino (un interpréteur JavaScript sous Java). Le choix s’est porté sur Rhino car les alternatives n’étaient globalement pas assez abouties au moment du choix.

En 2006, une API en JavaScript orientée objet fut offerte aux développeurs, permettant d’interagir avec les produits, les clients, le panier de l’utilisateur, les commandes, les profils clients, etc. Il s’avère que Rhino s’est montré étonnamment fiable, avec un seul bug rencontré en 5 ans de développement (avec cependant un support du XML relativement buggé).

Ulrike nous montre des exemples de code de boutique, avec notamment l’appel à un web service. Le code est relativement concis, 14 lignes de JavaScript suffisent pour récupérer le service, lancer l’appel et traiter la réponse.

L’environnement d’exécution est un environnement partagé. Aussi il est très important pour eux que le code ne bloque pas, et qu’il n’empêche pas l’exécution des autres boutiques.

En conclusion, Ulrike est très content du choix de cette solution technique qui prouve son efficacité.

Cependant, l’équipe avait initialement beaucoup d’expérience en Java et non en JavaScript. Cela a conduit à la création d’une API très proche de ce que l’on retrouve en Java. Avec du recul, il y aurait aujourd’hui beaucoup plus de closures. Enfin, CommonJS, cet ensemble de pratique pour du développement JavaScript côté serveur, serait quelque chose qu’ils adopteraient aujourd’hui.

Un retour d’expérience intéressant qui montre que JavaScript côté serveur est viable si le contexte s’y prête.



Une autre présentation fut celle de Mikeal Rogers : “node.js + CouchDB == Crazy Delicious“.

Mikeal a voulu nous montrer en quoi nodejs se marie très bien avec CouchDB.

Pour rappel, CouchDB est une base de données NoSQL, orientée document et basée sur HTTP et REST. Il nous présente l’application d’exemple d’un webmail où du code HTML, CSS et JavaScript sont partagés entre le client et le serveur nodejs. Il utilise la technique des CouchApp, technique permettant à CouchDB de servir des pages HTML, styles CSS et fichiers JavaScript en son sein. 

Ensuite, il nous rappelle que CouchDB bénéficie d’une vue spéciale, intitulé “_changes“, permettant de récupérer la liste des documents ayant subi un changement. Dans son exemple, il place donc le serveur nodejs derrière CouchDB et, en requêtant sur la vue “_changes”, récupère les documents emails au statut “à envoyer”. Ces emails sont alors traités par le serveur nodejs pour envoyer les emails.

C’est une façon de faire originale, d’autant plus que CouchDB intègre une notion de réplication, ce qui permet d’imaginer une base CouchDB côté client (ou dans son mobile avec CouchOne Mobile), dont les données se synchroniseraient sur la base où est branché le serveur nodejs effectuant l’envoi d’email.


Tobias Schneider nous déroula sa session “Not your Mother’s JavaScript!“.

Il se présente comme un hacker, dans le sens débrouillard ingénieux. A travers quelques exemples, il nous montre que l’histoire du Web est souvent une limite technique qu’on dépasse par un hack, une bidouille, avant de devenir un standard. Il cite Ajax que l’on réalisait autrefois via le chargement en boucle d’une iframe où l’on copiait/collait le DOM qui est devenu le standard XHR aujourd’hui. Ou encore JSONP, cette bidouille pour récupérer via Ajax des données présentes sur un autre domaine, qui deviendra une norme prochainement.

Il nous montre certains de ces trophées, comme l’envoi d’une requête Ajax vers un fichier ZIP renommé en PNG, afin de pouvoir le décompresser côté client. Une optimisation est de charger ce fichier dans un canvas, puis de lire la valeur de ces pixels un par un pour reconstituer le contenu du fichier décompressé. La décompression proprement dite étant géré par la librairie de lecture des PNG du navigateur.



Un autre session fut la présentation de Guillermo Rauch sur “Socket.IO: Web Sockets for Everyone“.

SocketIO est une bibliothèque permettant une connexion continue entre un navigateur et un serveur. Il utilise les WebSockets si le navigateur les supporte, sinon, ce rabat sur d’autres techniques (boucle en Ajax, Long polling, Flash, …). Elle permet de construire des applications “temps réel”, où des informations peuvent être poussées au client par le serveur. Il présente également NodeStream, un framework sous nodejs permettant de simplifier la réalisation d’applications temps réel.


Enfin, Kevin Dangoor, Joe Walker & Patrick Walton de chez Mozilla, nous présentâmes “Bespin/Skywriter: The JavaScript Programmer’s Editor“.

Skywriter, anciennement Bespin, est un éditeur de code écrit en JavaScript et reposant sur canvas. Il s’utilise de 2 manières, soit à travers un bookmarklet qui va enrichir les textarea présents dans la page courante, soit en l’installant dans son projet comme l’a fait notamment XWiki .


Learning JavaScriptEnfin, Chris William présente le fait que la communauté JavaScript doit s’unir en appliquant 3 principes :

  1. respecter les autres languages de programmation, puisque la majorité d’entre nous viennent de là,
  2. ne pas devenir un JavaScript fanboy,
  3. enfin, améliorer les recherches Google pour que les termes “JavaScript“, “Apprendre JavaScript” pointent vers des pages intéressantes (ce qui est loin d’être le cas actuellement).

A travers ces présentations, les discussions avec les orateurs et participants, on se rend compte que les tendances actuelles sont le code JavaScript côté serveur (nodejs), la volonté d’apporter une plateforme unifiée pour le développement d’application mobile (PhoneGap, Unify) et enfin, l’adoption lente mais sûre de HTML5 avec des modes dégradés pour les navigateurs plus anciens.

On voit également que JavaScript devient de plus en plus mature, avec l’émergence d’IDE de plus en plus puissants (Cloud 9 IDE, Bespin/Skywriter) et des briques d’architectures comme CommonJS ou SocketIO.

Enfin, la communauté JavaScript me semble très différente de la communauté Java : on y trouve de nombreux autodidactes, des “hackers” au sens noble du terme, des membres pouvant paraître “décontractés” mais en réalité très compétents et vraiment ingénieux.

Une expérience très enrichissante en somme !

Si vous souhaitez en savoir encore plus, je vous invite à suivre ce fil RSS que j’alimente au fur et à mesure de mes trouvailles ou de suivre le tag #jsconf sous Twitter.

3 retours sur “Compte-rendu de la JsConf 2010 (2ème partie)”

  1. Thomas says:

    Retour très complet, merci ! Il est intéressant de voir que certaines entreprises ont déjà misé sur Javascript côté serveur depuis des années.

    Ceci dit, j’ai un peu tiqué sur la présentation de Jenn Lukas. Depuis des années maintenant, on nous dit que 6% des internautes n’ont pas Javascript activé. Je serais curieux de voir les résultats d’une étude fiable appuyant ce chiffre.

    De plus, ça ne m’étonnerait pas que le Google bot puisse indexer (au moins) une partie du contenu généré en Javascript. Il indexe déjà les éléments Flash et SVG. http://www.seomoz.org/ugc/new-reality-google-follows-links-in-javascript-4930 + http://googlewebmastercentral.blogspot.com/2008/06/improved-flash-indexing.html

  2. Grégory Paul says:

    Bonjour Thomas,

    Au sujet de la présentation de Jenn Lukas, elle présente ses sources dans ses slides, à la diapo 14.

    Elle cite notamment les statistiques de w3schools et thecounter.
    Mais effectivement, ce genre de chiffre est toujours à prendre avec des pincettes (cela dépend de la cible du site et de son public).

    Je suis d’accord avec vous mais j’ai néanmoins retenu 2 points importants dans cette présentation :
    – il est parfois facile de rendre un site web fonctionnel à minima sans JavaScript (au moins pour l’accès au contenu),
    – il faut prévenir l’utilisateur si l’application dépend beaucoup de JavaScript et ce qu’implique sa désactivation (il n’y a rien de plus frustrant qu’un site qui ne marche pas sans en connaître l’origine).

    Merci pour les liens. C’est vraiment intéressant de voir jusqu’où vont les moteurs de recherche (en tout cas Google). Cela invalide en partie le critère SEO.

    Grégory

  3. Thomas says:

    Une nouvelle étude de Yahoo (avec ses biais ceci dit) : http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/ indique que, en moyenne, 1% des internautes n’ont pas Javascript.

    Cela ne veut pas dire que je suis favorable au développement pur Javascript sans se soucier de ceux qui ne l’ont pas activé ;)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

By submitting this form, you accept the Mollom privacy policy.