Dans son dernier livre, Javascript Efficace, David Herman plonge en profondeur dans le langage de programmation JavaScript et montre comment l'utiliser efficacement pour écrire des applications et bibliothèques plus portables, robustes et maintenables. Le livre rassemble des conseils, des techniques et des exemples de code pour expliquer les concepts importants de JavaScript.
InfoQ a rencontré David pour parler des nouvelles tendances en JavaScript et de l'écriture efficace de bibliothèques JavaScript.
InfoQ : Quelle a été la motivation derrière l'écriture de ce livre ?
David : Je voulais écrire un livre qui n'avait pas pour sujet le développement front-end, ou le développement côté serveur, mais JavaScript en tant que langage de programmation à part entière. Mon but était d'aider les gens à approfondir leur compréhension de ce que signifie écrire du code correct et robuste en JavaScript. Étant donné que JavaScript se retrouve dans de plus en plus d'environements, de la programmation côté serveur avec Node.js à Windows en passant par le développement d'applications GTK, je pense que le moment est venu pour les gens de voir JavaScript comme un vrai langage de programmation et non pas uniquement comme une des pièces de la chaîne de développement pour browser Web. Et j'ai toujours aimé la série des livres "Le Développement d'Applications Efficace" pour leur façon concise et pragmatique de donner des conseils de programmation pratiques et experts.
InfoQ : Nous avons tendance à voir EMAScript et JavaScript de façon interchangeable, ce qui prête à confusion. Pourriez-vous nous en dire un peu plus à propos de leurs relations ou de leurs différences ? Quelle version de JavaScript est actuellement utilisée ? Et qu'est-ce qui va venir ensuite ?
David : Cela semble prêter à confusion, mais heureuseument, ils sont basiquement la même chose. De façon générale, tout le monde se réfère au langage JavaScript. Mais JavaScript est officielement spécifié par l'organisation du standard Ecma, qui a créé le nom ECMAScript pour le standard, notament à cause de problèmes malencontreux de marque. En pratique, il n'y a pas vraiment de différence entre les deux. La dernière version de la norme ECMAScript est Edition 5, communément appellée ES5. La plupart des moteurs JavaScript modernes implémentent plus ou moins complètement le langage ES5. La prochaine version du langage sera l'Edition 6, qui est actuellement prévue pour être finalisée l'année prochaine. Toutefois, la spécification sera terminée bien avant que la norme soit ratifiée, et les moteurs JavaScript sont déjà en train d'implémenter certaines des caractéristiques de ES6.
InfoQ : Dans votre livre, vous donnez beaucoup de conseils utiles de programmation en JavaScript. Ce sont vraiment de bons conseils pour les programmeurs JavaScript professionnels. Combien de ces conseils doivent-ils leur existance au manque de certaines fonctionnalités de JavaScript ? Je me demande si certains de ces problèmes pourraient être réglés par de futures versions du langage.
David : Oui, je pense que certaines recommendations dans JavaScript Efficace pourrait être évitées en améliorant le langage. Par exemple, certaines des règles un peu délicates de portée, décrites dans le chapitre 2, vont être simplifiées grâce à de meilleures constructions pour les déclarations de variables dans ES6. Étant donné que ES6 n'est pas encore finalisé, j'évite d'en parler dans le livre ; ces améliorations peuvent changer très vite et je ne veux pas faire imprimer quoi que ce soit qui est sujet à changer.
InfoQ : JavaScript devient un langage très populaire et beaucoup de programmeurs veulent s'y mettre. Avez-vous des recommendations à leur faire ?
David : Et bien, j'espère qu'ils trouveront JavaScript Efficace utile ! Pour les gens qui n'ont jamais programmé, je recommande aussi le livre de Marijn Haverbeke : "Eloquent Javascript" et celui de Douglas Crockford :"JavaScript: The Good Parts."
InfoQ : Dans une de vos astuces, vous mentionnez que les programmeurs JavaScript devraient être à l'aise avec les "fonctions de haut niveau". Pensez-vous qu'il soit important pour les programmeurs JavaScript d'apprendre la programmation fonctionnelle ?
David : Je ne pense pas que la programmation fonctionelle soit un prérequis pour programmer en JavaScript. Mais apprendre la programmation fonctionnelle est une bonne façon d'améliorer votre niveau en programmation, et elle a de multiples utilisations en JavaScript. JavaScript fournit à beaucoup de gens un premier aperçu des concepts de programmation fonctionnelle. Je parle de ces différents concepts dans le livre, comme les fonctions de haut niveau et le design d'API stateless (sans état).
InfoQ : Quelles sont les conventions que les développeurs doivent suivre pour écrire correctement une bibliothèque JavaScript ?
David : Le Chapitre 6 de JavaScript Efficace est dédié à cette question. Certains des aspects du design qui sont spécifiques à JavaScript, dont la gestion de la coercition de type de JavaScript, travailler avec les tableaux JavaScript, et utiliser des "objets options" comme moyen de fournir des APIs ayant potentiellement un nombre important d'arguments optionnels. Il y a également quelques éléments de design de librairies qui sont plus universels mais qui sont toujours appropriés pour JavaScript, comme utiliser le typage structurel (aussi connu sous le terme "Duck Typing") et le chaînage de méthodes.
InfoQ : Il y a une tendance actuellement à créer des langages qui compilent vers JavaScript. Par exemple CoffeeScript, ClojureScript ou TypeScript. Pensez-vous que JavaScript devient lentement un langage de bytecode pour le Web ? Une personne ayant des connaissances limitées en JavaScript peut-elle être efficace en JavaScript ?
David : Oui, je pense que JavaScript est en train de devenir de plus en plus une cible de compilation depuis d'autres langages. J'espère que cette tendance va continuer et, en même temps, que JavaScript continuera à gagner une audience plus large de programmeurs. Donc, je ne pense pas que JavaScript devienne uniquement un "langage de bytecode".
Savoir si une personne peut être efficace dans un langage qui compile en Javascript est plutôt une question pour ces autres langages. Certains langages, comme CoffeScript ou TypeScript, sont conçus pour être vraiment très proches du modèle de programmation de JavaScript. Vous ne pouvez pas vraiment programmer avec CoffeScript sans comprendre JavaScript. Les autres langages, comme ClojureScript ou Roy, ont une approche radicalement différente en matière de style de programmation. Donc, ClojureScript pourait être plus facile pour un programmeur qui est a l'aise avec Clojure mais pas avec JavaScript.
Toujours est-il, il y a tout de même un intérêt à apprendre JavaScript. Par exemple, quand un programme ne se comporte pas comme prévu, il peut être nécessaire de comprendre ce qu'il se passe dans l'implémentation pour diagnostiquer le problème. Après tout, le problème pourrait être causé par un bug du compilateur qui génère le JavaScript, et même si ce n'est pas le cas, la plateforme (comme un navigateur Web ou Node.js) peut rapporter des erreurs sous forme de JavaScript.
InfoQ : Dans votre livre, vous avez une partie sur la concurrence et la programmation asynchrone. Cette partie est-elle uniquement pour les developpeurs JavaScript travaillant du côté serveur ? Un reproche que j'entends souvent à propos de la programmation asynchrone est la difficulté à gérer les callbacks. Pensez vous que l'API "Promise" ou d'autres alternatives peuvent aider ?
David : La concurence et la programmation asynchrone sont centrales à la programmation en JavaScript, au niveau du serveur, comme vous le dites, mais aussi au niveau du navigateur Web et plus ou moins dans tous les environnements qui font tourner JavaScript. Certains types de personnes sont habituées à gérer la complexité de la logique de la programmation asynchrone, y compris les "Promises", ce dont je discute dans l'Item 68. Je pense que les Promises sont très bien pour gérer cette complexité et qu'elles deviennent plus populaires et répandues en JavaScript. Pourtant, toutes les bibliothèques et applications n'ont pas adopté les Promises, ni même une seule approche pour l'asynchronisme. Donc, c'est important de comprendre les bases de la boucle d'évenement et les callbacks dans le but de pouvoir travailler avec des styles de concurrence en JavaScript variés.
InfoQ : Vous faites partie du projet asm.js. Je sais que beaucoup de personnes sont excitées par ses possibilités et ses usages. Que est le but du projet asm.js ?
David : Le projet asm.js identifie un sous-ensemble de JavaScript qui peut être utilisée comme un bon langage cible pour les compilateurs et qui pourrait être executé extrêmement efficacement dans les moteurs JavaScript modernes. La première version d'asm.js, que nous sommes justement en train de sortir, cible surtout les langages de très bas niveau comme C et C++. Cela nous a aidé à améliorer la performance du compilateur Emscripten (et devrait également bénéficier au compilateur Mandreel, qui est similaire), ce qui rend possible la compilation native d'applications C/C++ en JavaScript. Nos benchmarks actuels, qui tournent sur des versions "Nightlty" de Firefox, se sont vu être 2 fois plus lentes que leurs versions natives. Et nous espérons pouvoir appliquer plus d'optimisations au fil du temps pour s'approcher le plus possible de la vitesse native.
Actuellement, asm.js est extrêmement bas-niveau et utile uniquement pour un ensemble très restreint de programmes. Au fil du temps, on voudrait étendre asm.js pour incorporer plus de fonctionnalités venant de JavaScript, tout en préservant les excellentes performances qu'on peut actuellement voir dans la première version. Idéalement, cela devrait permettre à asm.js de devenir un compilateur cible approprié pour des langages de plus haut niveau comme Java, C#, Clojure, Ruby, Python, Racket, et beaucoup d'autres.
Comme vous avez précédement noté, JavaScript devient de plus en plus populaire en tant que cible pour compilateur, en partie à cause de son ubiquité. L'objectif global d'asm.js est de founir un meilleur support pour ces langages et compilateurs, de telle sorte que les gens puissent porter leur code existant sur le Web (ou sur une autre plateforme JavaScript), ou tout simplement pour qu'ils puissent écrire la logique de leur application dans le langage de leur choix. Les développeurs JavaScript intéréssés par apprendre plus de choses à ce sujet devraient jeter un oeil à ces excellents articles de blog de John Resig et Axel Rauschmeyer :
A propos de l'auteur de ce livre
David Herman est chercheur sénior chez Mozilla research. Il détient une licence en informatique de Grinnell College, une maîtrise et un doctorat en informatique de l'Université Northeastern. David a travaillé sur l'Ecma TC39, la commission chargée de la normalisation de JavaScript.