Suite à mon expérience sur Goldkeeper, je me suis orienté vers l'étude de Dart. Après deux semaines de découverte, de tâtonnement et d'implémentation d'un petit jeu, voici une première impression.

Tout d'abord, Dart est plus qu'un langage de programmation, c'est un environnement assez complet avec son langage, sa bibliothèque standard, son éditeur, son debuggeur, ses outils,... Comme c'est encore en plein développement, ça bouge pas mal. Mais c'est très acceptable pour construire quelque chose.

Les outils

Avant de parler du langage, je vais faire un tour par les outils fournis. Le premier d'entre eux est l'éditeur. Bonne chose, il est basé sur Eclipse ¹. Environnement connu, complet, fonctionnel. Du mauvais côté, par contre, plutôt qu'un plugin/view ajouté à un Eclipse de base, c'est un Eclipse très allégé. Et donc, par exemple, pas de support de gestionnaire de version, pas possible d'ajouter ses propres plugins préférés.

Je pense que c'est un choix délibéré pour éviter d'avoir à faire du support sur une multitudes de versions différentes.

(Mise à jour : en fait, il existe un plugin officiel Eclipse et un pour IntelliJ. Je n'avais pas vu.).

L'éditeur offre en plus une analyse statique. Pour le moment, je n'ai pas vu de l'analyse très poussée, mais l'éditeur analyse au moins les erreurs de base au niveau de la syntaxe et des types.

Dartium, la version de Chromium avec machine virtuelle Dart intégrée est lancée directement depuis l'éditeur, qui peut récupérer le log.

Je n'ai pas utilisé le debuggeur intégré pour le moment. Non pas que je n'ai pas besoin de debuggeur, mais que j'ai utilisé celui de Dartium directement, ce qui est plus facile pour un debug d'application Web.

Tout cela donne une vitesse d'itération très correcte... correcte, mais pas exceptionnelle. J'y arrive.

Dart vs. Javascript

L'un des objectifs de Dart est d'offrir un environnement de programmation dans le monde Javascript en apportant de la rigueur, en évitant les erreurs de design de Javascript et en apportant des facilités.

Forcément, tout cela vient avec son coût. D'après les études de performances disponible sur le site officiel, Dart dans sa VM est plus rapide que JS dans V8. Par contre, Dart traduit en JS est plus lent. Je n'ai pas encore vu cette partie, et le jeu que je développe n'a pas de problème de performances.

Par contre, l'application en Dart démarre beaucoup plus lentement qu'une application pure Javascript. Probablement que l'initialisation de l'environnement Dart est plus coûteux, mais je ne sais pas exactement.

Cela ralenti la vitesse d'itération, certes. Mais d'un autre côté, la rigueur du langage évite beaucoup d'erreurs sournoises faites lors d'un développement en Javascript et qui sont sources de ralentissement aussi. Au final, je pense qu'on s'y retrouve. C'est un peu plus lent, mais on lance moins « pour rien ».

Au niveau des lourdeurs, lorsque l'on traduit du Dart en Javascript et que l'on regarde le résultat sur un simple « Hello World », on constate que Dart amène beaucoup de choses. Le coût supplémentaire est très probablement amorti sur une application réelle, tout comme lors de l'utilisation d'un toolkit en Javascript. C'est à garder en tête : si vous n'avez que deux trois broutilles à faire dans un navigateur, aujourd'hui, restez en Javascript pur. Si vous développez une application complète, Dart est un candidat.

Le langage

Dart, c'est un peu de Javascript, un soupçon de C#, un pincée de Python, une cuillerée de jQuery,... C'est assumé. Le but étant d'offrir un langage à la syntaxe sans surprise (sauf si vous êtes spécialisé en Haskell).

De Javascript, il hérite la majeur partie de la syntaxe en enlevant toutes les surprises (les bêtises ?) de Javascript. Par exemple, la gestion de la portée est plus naturelle. Pas besoin non plus de contorsions pour essayer de cloisonner ses espaces de nom.

Les fonctions sont des objets de premier ordre, avec fermeture. Les maps et les tableaux sont là, implémentant une interface de type « Collection ».

Du C#, on retrouve une syntaxe simplifiée pour les fonctions retournant une expression (utilisation de l'opération =>), des getters et setters de propriétés. De jQuery, on retrouve la fonction de requête dans le DOM. Et de Python, le préfixe de tiret bas pour notifier le caractère privé d'un symbole.

Au niveau du typage, Dart offre la possibilité d'annoter les symboles. Le langage en lui-même est aussi peu typé que Javascript et peut se contenter de définition via var. Cependant, si vous utilisez des noms de types (de base ou de classe), alors Dart, via son éditeur, pourra vérifier les types et réagir en conséquence. Le langage offre aussi de vraies constantes.

Objets

Dart a un modèle objet là encore sans trop de surprise. Les classes peuvent implémenter des interfaces, étendre d'autres classes, être abstraites, être génériques,... On est dans du connu, et c'est agréable.

Petite chose chose étonnante, comme tout est objet et que la valeur d'un objet par défaut est null, toutes les valeurs par défaut est null. Écrire int i; déclare i et l'initialise à null.

La déclaration des constructeurs propose des simplifications syntaxiques pour des cas courants (MaClass(this.x); suffit à implémenter un constructeur initialisant le membre x avec son seul paramètre) et offre aussi une syntaxe pour les factories (un constructeur qui peut renvoyer autre chose que le type de sa propre classe).

Javascript nous a habitué à des appels de fonctions en cascade. Dart ajoute un opérateur intéressant, le double point (..). Cet opérateur peut enchaîner les actions sur les membres d'un objet. Plutôt pratique pour éviter des répétitions inutiles et éviter les copier/coller non maintenus.

Fonctions

Tout comme Javascript, Dart a un côté pseudo fonctionnel. Pseudo car, à part les fonctions comme objet de premier ordre et les fermetures, on est loin d'un Lisp ou dans Caml. Dart n'innove pas vraiment mais ajoute quelques fonctionnalités classiques : paramètres optionnels et paramètres nommés.

Grâce à une série de fonctions de traitement sur les collections, on pourrait être tenté de verser dans la programmation fonctionnelle. Cependant, la bibliothèque standard accroche un peu : cela manque de vision globale fonctionnel, beaucoup de méthodes et fonctions sont des procédures qui ne retournent pas de valeur. Rien de rédhibitoire, mais c'est dans ces coins là que l'on sent que la peinture est encore fraîche.

De plus, le manque de protection de style pure en D n'incite pas à faire confiance aux fonctions. Le langage n'offre pas de système pour prévenir les effets de bord.

Plus gênant par contre, il n'y a pas de constructeur de liste (list comprehension). Écrire les listes « à l'ancienne » dans un langage de ce type, ça donne une impression de manque. Je n'irai pas jusqu'à dire qu'il manque un système aussi puissant que Linq, mais presque. On verra bien les développements futurs.

Qualité

Une application Dart peut s'exécuter en mode production ou en mode debug. En mode debug, le langage supporte les assertions.

Dart a aussi une bibliothèque de tests unitaires et de « mock objects ». Les tests sont déclarés via des fonctions et il faut les appeler explicitement. C'est un peu dommage. Je n'ai pas encore plongé dans le code, mais j'ai l'impression que les tests ne sont pas lancé dans une vraie isolation. Il faut donc faire attention à bien nettoyer à la fin d'un test et ne rien retenir dans des objets potentiellement encore actifs, le garbage collector n'est pas forcément encore passé.

Plus complexe, le DOM n'étant pas réinitialisé à la fin d'un test, c'est à gérer manuellement.

Autre problème, où placer les tests ? S'ils sont placés en tant que part of de la bibliothèque à tester, on peut tester les fonctions privées. Mais les tests sont alors transportés avec le code de la bibliothèque. Si les tests sont en dehors de la bibliothèque, on ne peut plus tester les fonctions privées. Autant tester des fonctions privées à une classe est une mauvaise idée, autant ne pas pouvoir tester des fonctions privées à une bibliothèque est plus gênant.

Je continuerai à regarder l'existant. Apprendre un langage, c'est aussi voir comment sont faites les choses de la bonne manière.

Conclusion temporaire

Dart est une bonne promesse. Je n'ai pas encore le niveau nécessaire pour être vraiment à l'aise. Je regarde encore pas mal la documentation et je dois chercher des exemples de code pour cerner la philosophie d'ensemble. Cependant, c'est assez clair pour progresser rapidement.

Je vais donc continuer mon aventure dans le monde de Dart.