JsConf.eu 2011 – Compte-rendu (partie 1/2)

Publié par Grégory Paul, le 4/10/2011, dans Événements, Valtech


Ce week-end a eu lieu à Berlin la 3ème édition de ls JsConf.
Y ayant passé un très bon moment l’année dernière (confère mon compte-rendu), j’ai réitiré l’expérience cette année.

Petit clin d’oeil cette fois-ci, l’accueil fut confié à la fondatrice (factice) du fan club de Brendan Eich (le père de JavaScript). Celle-ci a poussé la chansonnette juste avant la keynote d’ouverture avec des paroles très appropriées.


Lors de la keynote d’ouverture, Dean McNamee a présenté Plask, un outil destiné à réaliser des créations artistiques.
Basé sur V8, Plask permet de faire le pont entre la technique (2d, 3d, audio, webgl, capteurs physiques, imprimantes, etc) et la création d’oeuvres éphémères.
Cet outil a été utilisé par exemple pour le dernier anniversaire de wikipedia afin de construire un système imprimant continuellement sur de petites cartes les derniers articles modifiées. L’intérêt de JavaScript pour ce type de développement est la rapidité de mise en oeuvre (les délais sont habituellement de l’ordre de la semaine) ainsi que la robustesse du système (l’oeuvre ne doit jamais s’arrêter le temps de l’exposition).

Ainsi, dans l’exemple précédent, 3 processus indépendants s’envoient des messages. Une action posant problème ne bloquant pas les autres processus.
D’autres oeuvres furent produites tels qu’une installation pour Lexus, où 2 voitures remplies de fumée clignotent au sein d’une musique alternative.
L’intérêt de Plask est la rapidité de la mise en oeuvre et l’utilisation de toutes librairies JavaScript déjà existantes.


La présentation suivante fut celle par Sergi Mansilla nous présentant leurs travaux sur Cloud 9 IDE, un éditeur construit 100% sous JavaScript et node.js, un an après leur annonce au même endroit. Leur slogan est intéressant : “Cloud 9 is to Eclipse what Google Docs is to Microsoft Office”.

Il y eu au programme des nouveautés comme la partie collaborative où plusieurs utilisateurs peuvent éditer le même fichier en même temps.
Cloud 9 IDE étant herbergé sur le Cloud, cette approche peut être pertinente.
Bien sûr, étant un projet OpenSource, il est toujours possible de lancer cet IDE localement sur sa machine pour peu qu’on dispose de node.js.
D’autres améliorations ont étés apportés tels que la visualisation des branches et de commits git.
En résumé, Cloud9IDE a passé le stade de l’expérimentation, il est utilisable en production pour construire des applications node.js (Cloud 9 IDE est construit avec Cloud 9 IDE).


Mathias Bynens a ensuite donné son retour sur jsPerf dans la session “Using jsPerf correctly“.
JsPerf est un site web permettant de benchmarker un bout de code qui sera exécuté des milliers de fois.
Le but est de mesurer les performances dans le navigateur courant, puis de le comparer avec d’autres.
L’intérêt est de pouvoir vérifier quel code est le plus rapide entre 2 ou plusieurs approches (par exemple la façon la plus optimisé de concaténer des Strings). Mathias revient donc sur les bonnes façons d’écrire ces tests de performances, en utilisant à bon escient le setup ou le tearDown, en réinitialisant les variables pour éviter la dépendances entre tests, etc.
En effet, l’écriture de tests est similaire a un test unitaire, on retrouve donc des similitudes.
Il est également possible de tester des méthodes asynchrones en appelant la méthode deferred.release à la fin de l’appel asynchrone.
Après son 1er anniversaire, l’auteur en conclut que jsPerf a servi a benchmarker les différents moteurs JavaScript mais également à soulever quelques bizareries de JavaScript.


Dans la session “JavaScript JITs“, David Mandelin et David Anderson, développeurs Mozilla, nous présentent ensuite les amélirations dans les moteurs JavaScript.

Pour rappel, dans les navigateurs actuels, le code JavaScript est transformé à la volée en code machine afin d’être le plus rapide possible.
Ils nous expliquent comment optimiser cette transformation et réduire le nombre d’instruction.
JavaScript n’étant pas typé, 2 approches sont possibles lors de la générations de code machine : la 1ère solution où le code, pour chaque instruction, adopte la réelle opération à appliquer en fonction du type et la 2ème où le code devine le type et génère directement les bonnes instructions.
La 1ère approche n’est pas optimisée tandis que la seconde nécessite de recompiler le code si les variables changent de type.
Nous rentrons alors dans le vif de la présentation avec du code JavaScript d’un côté et, à droite le code machine généré. La 1ère approche précédente génèrent plus de 30 instructions pour une simple addition d’entier en JavaScript ou encore plus de 230 instructions machines pour une boucle simple.
Une première optimisation par le compilateur est d’extraire les opérations répétées inutilement dans les boucles ; cette technique est appelée l’hoisting.

Une autre technique est l’inline caching utilisée lorsque les valeurs ne peuvent être déterminées au moment de la compilation du script. Dans ce cas là, le code se modifie lui-même à l’éxecution en remplaçant les valeurs au moment où il va être éxecuté.
Avec la 1ère approche, un programme est 10 x plus lent qu’en C tandis qu’avec la seconde et ces techniques d’optimisations, on arrive à un résultat 2 x plus lent qu’en C, ce qui n’est pas si mal.
Le plus grand problème vient du gap sématique, notamment car C différencie les types de données (int, long, float, double, …) alors qu’en JavaScript, tous les chiffres sont des floats codés sur 64 bits. Les tableaux typés (typed arrays) permettent dès à présent d’améliorer ces performances (notamment pour WebGL).


La session suivante fut celle d’Andreas Gal, également chez Mozilla, sur pdf.js.
Comme son nom l’indique, le but est de parser le format PDF et de l’afficher au sein du navigateur.
Voici la démo qui permet le rendu d’un PDF directement dans le browser, en JavaScript/Canvas et sans plugin !
Tout d’abord une expérimentation, cette librairie a pour but d’être incluse dans une future version de Firefox avec comme but de s’éxecuter dans un environnement plus sécurisé qu’un plugin natif et donc de fermer la porte aux exploits PDF.
Andreas nous présente les différents problème rencontrés, notamment les endroits où il est nécessaire d’optimiser le code, au détriment da lisibilité notamment lors de la décompression du format pdf (les pdfs sont zippés).
Une des avancés qui a rendu cela possible est l’utilisation massive de TypedArrays, tableaux typés pour recueillir des entiers (Uint8Array).
A la fin de la présentation, on s’aperçoit que les slides ont été rendus via cette bibliothèque, directement dans Firefox et c’est incroyablement rapide.
Bien sûr, l’ensemble du format PDF n’est pas couvert (pas de formulaires, ni video, encore moins l’embarcation de flash) mais le support actuel suffit pour la majorité des PDF disponible sur le net (avec du texte, des graphiques, schémas ou images). Impressionant !




Toutes les sessions sont enregistrées avec du matériel de pro et on les retrouvera sur blip.tv/jsconfeu.



Dimitry Baranovaskiy a ensuite présenté Raphaël 2.0 dans la session du même nom.
Cette librairie permet de construire via JavaScript des dessins, animations qui seront ensuite converties en SVG ou VML pour Internet Explorer.
Cette seconde version apporte de nombreuses améliorations, une API plus claire ainsi qu’une documentation très soignée.
L’auteur a d’ailleurs réalisé une librairie, dr.js, parsant un format de commentaire pour créer la doc à la volée (une sorte de JavaDoc sous cortisone).



JavaScript fait son entrée dans l’embarqué avec la session (spectacle ?) “Arduino Extravaganza”. Il a été question d’une application bâtie sur node.js (avec comme principaux modules node-arduino, node-serialport & node-espresso) envoyant des commandes via le port série à un Arduino (plateforme matérielle peu onéreuse et OpenSource), pilotant des pompes reliées à des bouteilles dans le but de réaliser des cocktails.
Des questions étaient alors posés à 2 volontaires désignés, Chris Williams et Malte Ubl.
En fonction de la justesse de la réponse, le participant devait boire le cocktail réalisé ou alors l’offrir à son adversaire.

Une session divertissante mais qui montre l’étendue des librairies node.js, qui permettent d’en faire un outil ultra-polyvalent.




Le traiteur s’est surpassé par rapport à l’année précédente, avec des plats préparés devant le public.


Partant du constat qu’il existe une base de code en C/C++ très conséquente, Alon Zakai nous présente ensuite “Emscripten“, un outil pour transformer du code C/C++ en JavaScript.
Quelques démos assez bluffantes nous sont alors montrées, comme bullet, un moteur physique de 150K lignes de code en C, porté avec cette méthode, SQLite s’éxecutant dans le navigateur, un interpréteur Python (http://repl.it) ou encore espeak, librairie permettant la synthèse vocale.
Ces démos sont très fluides et l’intérêt de réutiliser la base de code C ou C++ est énorme.

Le fonctionnement est le suivant : compiler son code C/C++ en LLVM (Low Level Virtual Machine), puis utiliser Emscripten qui transforme ce language intermédiaire en JavaScript.
Les performances sont environs 2 à 3 fois inférieures à l’utilisation de C/C++ mais cela est relativement acceptable dans certains cas.


Pour la keynote de fermeture, Brendan Eich nous parle de l’avancement des spécifications autour d’EcmaScript 6, prochaine version de JavaScript (JavaScript est un dialecte qui respecte les spécifications d’EcmaScript).
Le but de ce commité est de faire évoluer JavaScript doucement afin de réparer les mauvais côtés du language et d’apporter des facilités.
De nombreuses fonctionnalités sont discutés (et certaines déjà implémentés en partie ou totalité) comme les tableaux typés (pour des raisons de performances, notamment pour WebGL), les structures de données, l’ajout de classes, de générateurs comme sous Python ou encore les blocks comme sous Ruby.
Brendan fini par nous présenté les derniers travaux d’Intel sur une démo introduite à l’IDF 2011, dénomé RiverTrail, permettant de rendre le code JavaScript multi-threadé avec à la clé des performances décuplées !
En conclusion, Brendan est très optimiste car, à de nombreuses reprises, différents griefs ont étés portés à JavaScript (à juste titre à certaines périodes) comme : “JavaScript est un jouet”, “JavaScript est trop lent”, “JavaScript ne peut être réparé” ou encore “JavaScript ne pourra pas être multi-trheadé”…
A chacune de ces accusations, JavaScript a évolué pour devenir aujourd’hui un langage universel, répandu sur pratiquement toutes les machines du monde.



Cette présentaton clôt cette 1ère journée et laisse la place à la traditionnelle soirée, toujours aussi originale et agréable.

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.