Comme tous ceux qui font du développement web, je code pas mal en Javascript. J’en ai déjà parlé sur ce blog, c’est un langage dont j’apprécie la souplesse mais dont les limitations m’empêchent d’imaginer faire du vrai génie logiciel dessus. J’ai beau faire des développements JS “propres”, avec l’utilisation d’objets rangés dans des namespaces hiérarchiques, je ne cesse de pester contre l’âpreté de son modèle objet.
Toutefois, pas mal de choses bougent en ce moment du côté du développement sur les navigateurs. Je n’ai pas encore vraiment mis le nez dans tous ça − à part lire de la documentation − mais ça reste intéressant d’en parler un peu.
Dart
Pour commencer, le langage Dart − créé par Google pour remplacer un jour le Javascript − vient de voir son SDK publié en version 1.0. C’est un langage qui fait voler en éclat les problèmes du Javascript ; son modèle objet est complet, il gère nativement les packages, et il peut être aussi bien fortement que faiblement typé.
Pour le moment, seule une version spécialement modifiée du navigateur Chromium (Dartium) est capable d’interpréter directement du code Dart. Mais il est possible de « compiler » du code Dart en code Javascript, permettant son exécution par n’importe quel navigateur. Là où ça devient intéressant, c’est que cette phase permet d’optimiser le code Javascript généré au point de le rendre en 42% et 130% plus rapide que le même code écrit nativement en Javascript.
C’est d’autant plus intéressant que les interpréteurs Javascript ont connu une énorme augmentation de leurs performances ces dernières années.
Bon, par contre je ne suis pas persuadé que passer par une phase de compilation pour du code client soit très pratique d’utilisation. Mais il reste toujours la possibilité de développer sur Dartium, puis de tester le code JS généré sur les autres navigateurs.
En tout cas, si le Go (l’autre langage de Google) a réussi à obtenir un peu de “traction”, j’ai le feeling que le Dart a le potentiel pour se faire une place de choix dans l’univers des langages de programmation modernes.
Programmation C/C++
Bon, quand il s’agit d’obtenir les meilleures performances possible, on finit quoi qu’il en soit par programmer en C ou en C++. Les ingénieurs de Google en étaient arrivés à cette conclusion et ont développé NaCl (pour “Native Client”) qui est une techno permettant d’exécuter dans un navigateur du code compilé pour processeur x86.
Enfin, quand on dit « dans un navigateur »… ça marche tant que le navigateur en question est Chrome, hein.
En plus, avec l’API Pepper, le code C/C++ n’est plus cantonné à une simple fenêtre, mais il peut communiquer avec le navigateur, ça peut amener à des choses sympatiques.
Mais fondamentalement, j’ai toujours trouvé cette idée bizarre. Oui, c’est génial d’avoir Quake qui tourne dans un navigateur web. Mais le principe fondamental du web, c’est de reposer sur des standards multi-plateformes. Embarquer du code compilé nativement pour un type de processeur au milieu de tout ça, c’est moche.
Ça tombe bien, car deux technologies différentes permettent de contourner ce problème. Les deux reposent sur une particularité du compilateur LLVM. Pour schématiser grossièrement, un front-end prend en charge la compréhension d’un langage de programmation, génère un bytecode spécifique, qui est ensuite utilisé par le back-end pour produire un exécutable natif. Et donc, le bytecode intermédiaire n’est pas dépendant du processeur sur lequel il va être exécuté.
La première techno basée sur ce bytecode s’appelle Emscripten. Elle prend du bytecode LLVM, et génère du code Javascript qui peut être exécuté directement par le navigateur. Le résultat est assez bluffant, dans la mesure où le moteur Unreal 3 a été porté en seulement 4 jours, et que la démo Epic Citadel qui est basée dessus est vraiment impressionnante.
En plus, avec la bibliothèque pepper.js, il est possible d’atteindre le même résultat qu’avec l’API Pepper (intégrée à NaCl, citée plus haut).
La seconde techno, issue de Google (décidément !), s’appelle PNaCl (pour Portable Native Client). Grosso modo, vous prenez NaCl, vous lui ajoutez Emscripten, vous mélangez bien, et voilà le résultat. En fait, le navigateur intègre un interpréteur de bytecode LLVM. On obtient ainsi le meilleur de chaque monde : la vitesse d’exécution qu’on est en droit d’attendre d’un code C/C++, avec la portabilité qu’on est en droit d’exiger sur le web.
Conclusion
Comme je le disais, ça bouge du côté du développement sur navigateur. Et c’est assez excitant. Je vais avoir du mal à trouver le temps d’expérimenter ces technos, mais j’en ai bien envie.
On peut remarquer que le vénérable Javascript, grâce à son support quasi-universel, reste le garant de la compatibilité de ces technologies (Dart, Emscripten) avec tous les navigateurs existants. Il devient le bytecode générique du web, un peu comme le C est utilisé par certains langages exotiques comme un bytecode intermédiaire (j’en parlais dans un article sur la création d’un interpréteur).
Pas sûr qu’il soit très simple ni rapide de faire une triple compilation (C/C++ vers bytecode LLVM, puis vers Javascript, pour enfin être interprété sur le navigateur, éventuellement avec de la compilation JIT). Mais si on peut accélérer le codage en développant sur un navigateur spécifique, pour ensuite être compatible avec tous les autres, ça peut en valoir la chandelle.
J’utilise TypeScript qui se veut une implémentation de EcmaScript 6. Avec PhpStorm comme environnement de développement, c’est une bonne solution.
Ah oui, je ne connaissais pas TypeScript. Ça a l’air pas mal, je vais regarder ça attentivement, merci. Maintenant il faut se demander s’il ne vaut mieux pas investir du temps dans Dart, que Google a l’air de pousser fort.
TypeScript est poussé par Microsoft et c’est une implémentation en JavaScript actuel du JavaScript futur. Ce qui est aussi une garantie.
TypeScript est un sur-ensemble strict de JavaScript ce qui signifie qu’on peut incorporer l’existant tel quel… et appeler jQuery. On peut concrètement l’utiliser aujourd’hui sans rien casser. Dart à côté est une grande boite fermée. Passer à Dart demande alors un investissement bien plus grand alors que le retour n’est pas si certain.
Pour essayer TypeScript : http://www.typescriptlang.org/Playground/ .
Effectivement. Mais en regardant rapidement le site, il n’y a pas d’exemple montrant qu’on peut typer les variables (alors que c’est présent dans la spécification du langage). J’ai l’impression que la manière de déclarer le type de retour d’une fonction n’est pas très pratique. Et je n’ai pas vu s’il était possible de définir la visibilité (public, protected, private) des attributs et des méthodes.
Colle ceci dans le Playground :
class Greeter { private message: string; constructor(name: string, private num: number) { this.message = "Hello, " + name + "!"; } public say() { alert(this.makeMessage()); } private makeMessage(): string { return "Message numero " + this.num + ": " + this.message; } } var greeter = new Greeter("World", 123); greeter.say();Note : J’utilise la syntaxe raccourcie pour déclarer « num » comme variable d’instance directement dans le constructeur.
Ah yes, intéressant. Merci.
Bon, j’ai un peu de mal à me faire au typage après la déclaration ; c’est vraiment particulier à l’Ecmascript/ActionScript, il me semble. En tout cas, c’est très différent de ce à quoi je suis habitué.
Je veux juste revenir sur le C/C++, ce n’est pas un peu risqué de données un accès au navigateur. Oui ça peut donner quelques chose de sympa, mais à quel risque ? Il ne serait pas plus intéressant d’avoir une possibilité de faire fonctionner le C/C++ côté serveur au lieu de côté client ? Limite soyons fou, d’ajouter une possibilité d’exécuter nativement en proxy. Au moins la sécurité serait présente.
Non, aucun problème. Le code C/C++ accède aux données du navigateur à travers une API que celui-ci lui met à disposition. Exactement comme du code Javascript. Ce n’est pas comme si on codait des extensions navigateur. Il faut vraiment voir ça comme un équivalent au code Javascript, mais qui s’exécute bien plus rapidement.
salut!
je relis ce blog passionnant (merci!) et dorénavant début 2016, ES2015 côté client et Node côté serveur ont le vent en poupe! ça foisonne de partout (elixir, js, coffeescript, etc) mais JS a fini par mettre tout le monde d’accord on dirait pour le futur, en général, non? Un unique language client et serveur, now what, un unique framework fullstack aussi, Meteor? Pour démarrer sa petite boite web, une idée de site ou appli, multi devices (web, smartphones, …), ultra économique et suffisant (sauf besoins spécifiques), non?
Bref, un seul codeur pour tout faire et hop, économique, rapide, fiable… (ok, une fois qu’on a dans la boite à outil ce qu’il faut… sinon faut le créer ou aller chercher ailleurs, chez Node et Angular ou React, sinon ben… back to 2 languages et 2 frameworks…)
Qu’en pensez vous en 2016?
@nicolas : Oui, ça continue à bouger en 2016. Personnellement, je reste pas très fan du Javascript everywhere. Mais c’est plus une question d’habitude qu’autre chose. Il y aura toujours beaucoup de choses que je préférerai faire en PHP, et quelques rares choses que je préférerai faire en C 😉
Et puisque tous ces écosystème sont effectivement très dynamiques, je ne pense pas qu’il soit souhaitable d’avoir un unique framework. Là où les fullstack connus vont continuer à grossir (aussi bien en terme d’utilisation qu’en lourdeur générale), d’autres framework plus légers ou plus spécialisés vont continuer à apparaître.
La diversité, c’est bien aussi 🙂