Accueil > Forums et Salons, Web > Le présent et l’avenir de JavaScript à dotJS 2014

Le présent et l’avenir de JavaScript à dotJS 2014

J’ai eu l’occasion de participer à la conférence dotJS 2014, centrée autour de l’écosystème JavaScript. Bien que la conférence dure une journée, des workshops étaient organisés les jours précédents, dont notamment un workshop Polymer encadré par le très connu Addy Osmani (créateur notamment de Yeoman, TodoMVC, Aura), Ewa Gasperowicz et Sérgio Gomes, auquel j’ai eu la chance d’assister.

La conférence est quant à elle assez différente des conférences traditionnelles puisqu’elle regroupe de nombreux talks très courts (une vingtaine de minutes). J’ai pour ma part été mitigé sur cette édition. Adepte des TED Talks – des sessions de 20 minutes sur des sujets variés en général très inspirants – je m’attendais à des interventions du même acabit : innovantes et orientées vers ce qui pourrait être. De fait, la plupart des interventions s’attachaient à dresser un état des lieux d’un aspect de l’écosystème JavaScript actuel, sans pour autant vraiment apporter de pistes nouvelles.

Cela n’est pas une critique sur les interventions en elles-même qui étaient de très bonne qualité, mais plutôt une déception personnelle sur les sujets abordés. Parmi les interventions qui m’ont particulièrement plu, je vais en détailler certaines après être revenu plus en détails sur le contenu du workshop.

Workshop Polymer Polytechnic Paris

Dans les locaux de la Web School Factory, j’ai pu m’installer dans une salle déjà bien remplie pour profiter de ce workshop gratuit organisé en marge de la conférence dotJS. Autour de moi, très peu de francophones et beaucoup de motivation et de bonne humeur. Polymer est un framework en surcouche du standard des Web Components offrant à la fois une compatibilité avec tous les navigateurs actuels (notamment Safari et IE qui ne supportent pas les Web Components autrement). Ce framework offre également un sucre syntaxique très appréciable et qui permet au développeur de gagner du temps dans ses développements.

Très vite, le workshop démarre par une présentation générale de Polymer : sa philosophie, les besoins auxquels il répond et la comparaison entre les standards WebComponents et le sucre syntaxique de Polymer. Les slides de cette présentation sont disponibles en cliquant ici. Mon expérience de Polymer (et des Web Components) était très faible avant ce workshop et cela a donc été pour moi l’occasion d’apprendre et d’utiliser ce framework dans un environnement permettant facilement d’avoir des conseils et de l’aide.

Après cette présentation, a débuté le workshop proprement dit : en nous rendant sur un lien donné, nous avons pu découvrir plusieurs codelabs à réaliser nous guidant progressivement dans l’apprentissage de Polymer. Ces codelabs sont toujours disponibles et je conseille à quiconque voulant découvrir Polymer de s’en servir.

Mes impressions générales sur le framework sont très positives. Ayant eu l’opportunité de développer beaucoup en AngularJS, j’ai évidemment rapproché cette découverte des directives Angular, et cela m’a donc apporté un niveau de compréhension supplémentaire. Avec les Web Components, on peut très rapidement mettre en place des applications fonctionnelles, notamment grâce à la communauté qui offre ses propres composants réutilisables. Cela a de quoi me réjouir, sachant qu’Angular 2.0 sera compatible avec les Web Components.

Tuning Node par Joe McCann

Cette intervention m’a beaucoup plu parce qu’elle traitait d’un aspect auquel je n’avais jamais songé : optimiser directement l’exécution de son code JavaScript en étudiant le fonctionnement interne du moteur V8. Joe McCann est le co-fondateur et le co-CEO de Nodesource. Il dispose donc d’une solide expérience, même si comme il aime le dire, il est plutôt du genre à utiliser les outils qu’on lui donne au meilleur de leur capacité plutôt qu’à les démonter pour en examiner le fonctionnement interne.

Il a ainsi fait une exception pour cette présentation, puisqu’il nous décrit en détail les mécanismes internes du V8 pour savoir comment optimiser notre code. Le V8 est un moteur JavaScript développé par Google qui est notamment utilisé pour compiler le Node.js. Pour ceux qui souhaitent en savoir plus, je recommande la lecture de cet article rédigé par  Thibault Laurens. Après une brève présentation du principe du V8, qui compile en assembleur notre code JavaScript tout en essayant de l’optimiser, Joe McCann en retire une action en deux phases :

  1. Ecrire du code performant
  2. Optimiser grâce aux flags

15213682664_5796c88ab2_z

Derrière ce premier point qui peut sembler évident se cache en fait l’interrogation suivante : Comment écrire le code qui sera le mieux optimisé par V8 lors de la compilation en assembleur ? En réponse à cela, Joe nous offre plusieurs pistes intéressantes :

  1. Garder tout le temps pour une fonction le même nombre d’arguments et le même type. Cela permet de conserver des fonctions monomorphiques et non pas polymorphiques ou pire encore mégamorphiques, ce qui ne peut pas être optimisé par le V8. Une explication très précise est disponible sur le lien suivant. Bien qu’il soit toujours possible d’effectuer cette optimisation, à mon sens il convient de bien réfléchir au cas par cas. Ainsi, on peut penser aux fonctions de lodash qui acceptent différents types d’arguments. Il faut donc bien réfléchir au gain réel par rapport à la perte du côté pratique de telles fonctions ;
  2. Utiliser des constructeurs et des factory pour s’assurer que les propriétés sont ajoutées et définies dans le même ordre tout le temps. Une fois encore, le lien précédent permet d’expliquer ce comportement ;
  3. Garder les objets de la même taille en déclarant dès le début toutes les propriétés (même s’il faut les définir null/undefined). V8 peut ainsi créer les maps correspondants en une seule fois
  4. Eviter de mélanger les types dans les arrays ;
  5. Eviter d’utiliser trop de closures anonymes et utiliser à la place des fonctions nommées (je n’ai plus l’explication précise de celui-ci malheureusement) ;
  6. Garder la taille de nos fonctions à moins de 600 caractères / bytes (commentaires compris). D’abord déroutant, derrière ce conseil se cache en fait une explication toute simple : jusqu’à 600 caractères, V8 va compiler notre fonction en inline.

Mais améliorer notre code n’est pas la seule façon d’en optimiser l’exécution. Joe McCann reprend le dernier point, à savoir la limitation des fonctions à 600 caractères/bytes, afin d’en faire la démonstration. En effet, Node offre toute une gamme de flags permettant de le configurer et l’adapter au mieux à notre code. Pour ce fameux dernier point en effet, Joe nous montre qu’on peut augmenter cette taille limite pour les fonctions inlined :

%SetFlags(“--max_inlined_source_size=1000");

Il existe ainsi de très nombreux flags qu’il peut être intéressant d’étudier, même si Joe McCann recommande de ne pas utiliser ces outils en production. Il n’en reste pas moins qu’il s’agit de nouvelles pistes d’optimisation qu’un développeur peut expérimenter en s’amusant. Et l’expérimentation est le concept central de la conférence d’Angus Croll dont je vais maintenant vous parler.

Accéder aux slides >

The Book Nerd’s Guide to JavaScript par Angus Croll

Javascript compared to JavaCette présentation n’est que peu technique, mais l’intervention d’Angus m’a beaucoup marqué car celle-ci était très bien conçue, ponctuée d’humour bien choisi, et à la fois très vraie dans le fond. Angus Croll, le créateur de Flight, a récemment écrit un livre intitulé If Hemingway Wrote JavaScript, dans lequel il résout des problèmes de JavaScript à la façon de plusieurs grands auteurs littéraires.

 

Angus Croll met ainsi en place une analogie entre le JavaScript et la littérature. Il explique que ce qui fait la richesse de cette dernière réside dans le fait qu’on puisse en utiliser toutes les subtilités. A l’inverse, en ce moment, les style guide JavaScript fleurissent sur internet et regorgent d’exemples à « ne pas faire ». Angus relève en plaisantant qu’en JavaScript, tout ou presque peut être considéré comme étant à éviter. Il dénonce cette orientation réglementée en expliquant que certains des paradigmes les plus utilisés aujourd’hui ont un jour été considérés comme une mauvaise pratique, à l’instar de fn && fn() ou if(!!elt).

Ainsi, en suivant ces guides, on se retrouve avec très peu de possibilités de résoudre certains problèmes. Que faire si ces solutions ne peuvent pas être utilisées ? Angus Croll affirme qu’il faut au contraire tenter, expérimenter, s’amuser en JavaScript. C’est un langage qui a évolué depuis toujours de cette façon, ce qui lui a permis d’atteindre la place prépondérante qu’il occupe aujourd’hui. C’est en expérimentant des choses qui peuvent paraître aberrantes au premier coup d’oeil que le JavaScript a su se réinventer.

Angus illustre ensuite cet état de fait en nous présentant le problème de la génération de nombres premiers résolu par Lewis Caroll puis par Jorge Luis Borges, avec des éléments étonnants comme deux join imbriqués qui donnent des résultats très intéressants.

Enfin, et ce n’est pas le moins important, Angus Croll souligne que l’expérimentation permet au développeur JavaScript de s’amuser, et c’est là une des clés pour apprécier son travail et se perfectionner dans sa maîtrise. Cela permet d’ouvrir son esprit à de nouvelles méthodes de programmation, et comme le dit James Halliday dans sa conférence : « You need a lot of bad code to write good code. »

Accéder aux slides >

Plusieurs conférences qui se complètent

En dernier point de cet article, je voulais revenir sur plusieurs conférences qui – à mon sens – se complètent de façon assez intéressante. Elles tournent toutes autour du concept d’application web côté client fonctionnant même hors-ligne. La première conférence est celle de James Halliday, décrite dans l’article de Julien Roche. Outre le format surprenant (que je qualifierais de console as slides), James offre plusieurs pistes intéressantes pour les applications hors-ligne. La première est de forcer l’aspect hors-ligne en jouant sur l’HTML5 cache. L’utilisateur, ayant téléchargé toutes les ressources nécessaires une première fois, ne dépend plus de la stabilité du serveur : il peut exécuter son application hors-ligne.

james-halliday-dotjs14

Mais comment faire lorsque l’utilisateur a besoin de s’authentifier ? James nous ouvre une seconde piste en parlant de connexion par cryptage asymétrique, proposant notamment son début de solution, KeyBoot. La conférence de Martin Gonto offre une deuxième possibilité grâce à l’utilisation des JSON Web Token ou JWT afin d’envoyer des données sous forme d’objet JSON signé et crypté. On a donc une possibilité d’échange de données avec le serveur, mais l’authentification ne peut évidemment fonctionner qu’en ligne. La solution est donc de s’authentifier une seule fois grâce à ce système de cryptage asymétrique, puis de permettre le travail offline en synchronisant les données seulement lorsque possible.

Il nous faut donc une base de données en local, une façon de stocker les informations pour les utiliser et plus tard les synchroniser. Il existe le local storage évidemment, ainsi que l’API WebSQL. James Halliday propose cependant une autre possibilité avec sa solution forkdb. Cependant, la solution présentée par Jack Rousseau dans son talk, pouchdb, me semble plus intéressante et plus aboutie. Elle permet en effet d’avoir une base de donnée répliquée localement et gère la synchronisation des instances selon que l’application est en-ligne ou non.

Ces conférences mises bout à bout permettent donc d’imaginer un écosystème complet qui nous permettrait de bâtir des applications hors-ligne sans trop d’efforts, permettant une meilleure expérience utilisateur (plus de chargement, plus d’attente lors des communications avec le serveur puisque la synchronisation se fait en fond).

A la fin de la journée

Malgré la déception que j’ai évoquée plus tôt sur le fait que les talks n’étaient pas assez tournés vers l’avenir, ce dotJS 2014 m’a permis à la fois de découvrir de nouveaux frameworks ou de nouvelles solutions, mais également de m’ouvrir de nouvelles pistes de réflexion, notamment sur les applications offline et les optimisations possibles de JavaScript.

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


sept − 3 =