Quand on veut parler de nouvelles technologies « web », il y a de quoi faire. Depuis des mois, de nombreuses librairies ont émergé, souvent pour contourner les bugs/incompatibilités des navigateurs (jQuery) ou pour simplifier le développement d’applications web (Backbone, Knockout, AngularJS, …).
Contrairement à Flex, il n’y a pas de framework « full stack » côté client. Vous devrez donc décider quelles librairies vous allez utiliser, vous assurer qu’elles « cohabitent » bien, assembler, mélanger et vous obtiendrez peut-être une application web robuste.
Il y a des nombreuses applications web comme GMail, Google Maps, WordPress que je trouve remarquables et que j’aimerai savoir réaliser.
Au cours des derniers mois, j’ai pu tester plusieurs librairies afin de me donner une idée. Vous vous en doutez, il est impossible de tout tester dans des cas d’utilisation « réels », faute de temps. L’analyse que je vais faire n’engage donc que moi et l’expérience que j’ai eu avec ces librairies. N’hésitez pas à utiliser les commentaires si vous pensez que ce que je dis devrait être corrigé.
Mes critères sont assez simples et personnels. A noter que certains sont aussi basés sur ce que je sais déjà faire. Par exemple, je suis sûr que l’on peut faire des merveilles en PHP mais je n’y connais pas grand chose alors je ne vais pas essayer de faire le malin là dessus.
Je ne suis pas forcement intéressé par la « beauté » d’un langage / framework et je ne pense pas que le code soit « de l’art » ou de la « poésie ». Flex m’a apporté une facilité de développement dont j’ai du mal à me passer. En gros, créer des composants, taper du code, lancer en debug, faire des watch dans Eclipse ou du pas à pas dans le code, corriger et cela jusque ça marche.
Voici donc les critères qui me tiennent à coeur:
Productivité
Dans l’ensemble, il faut que la solution soit productive. C’est-à-dire que l’on arrive à créer du contenu sans y passer des heures. Ne pas passer plusieurs minutes pour tester une application, la mettre en production ou pour compiler X ou Y.
Il faut que ce contenu soit facile à maintenir et qu’il puisse être facilement réutilisé par les membres de l’équipe. Pour vous donner un exemple, la notion de « composant » en Flex est primordiale, et nous permettait de réaliser des applications complexes parfois sans effort. L’application du DRY (Don’t Repeat Yourself) et du KISS (Keep It Simple and Smart/Stupid) de manière globale permet de faciliter la maintenance et de limiter les effets de bord.
Dans l’ensemble, il faut que le développement, aussi bien côté serveur que côté client soit rapide.
Debugging
Dans une journée, je passe *beaucoup* de temps à debugger, par rapport au temps nécessaire pour écrire le code. Il faut que je puisse faire du pas-à-pas facilement, qui je puisse inspecter une valeur dans son contexte et que je puisse naviguer facilement dans mon code. Cela relève souvent du travail de l’environnement de développement utilisé (IDE) mais aussi du navigateur qui propose une partie de ces outils.
Multi-plateforme
Flash Player ne tourne pas sur le navigateur de l’iPad et cela est très embêtant, surtout d’un point de vue commercial. Sur Android, Flash Player est à la limite adapté pour afficher des vidéos mais pas du tout pour le reste. « HTML5 » fait la promesse de pouvoir s’adapter à toutes les plateformes, presque de manière « magique ». On sait tous que ce n’est pas tout à fait vrai.
Dans l’idéal, il faut une solution qui permette de s’adapter facilement à une plateforme. Ou tout du moins, qu’elle n’apporte pas de blocage pour le faire.
Un minimum de « couches »
Par expérience, plus il y a de « couches » logicielles (soit en nombre de librairies utilisées, soit en nombre de « X compilé en Y ») impliquées dans un projet, plus il est complexe à gérer. D’abord parce que la compatibilité transversale des versions est assez difficile à assurer mais aussi parce que l’introduction d’un nouveau langage / DSL doit ensuite être appris par les membres de votre équipe.
Le but est donc de minimiser le nombre de langages, sans allez dans l’excès, pour pouvoir profiter pleinement des capacités de chaque langage, individuellement.
Communauté
La « Flash Platform » a un gros atout, c’est son énorme communauté, avec de nombreuses ressources déjà disponibles sur Internet. Cela est du en partie à son âge, mais aussi à pas mal de passionnés.
Une communauté active permet d’obtenir de l’aide rapidement et de trouver des librairies ou des bouts de code de qualité sur le net.
Voici donc un florilège de ces nouvelles technos que j’ai pu utiliser.
Play! Framework
Certainement mon plus gros « coup de coeur » ces derniers temps. Si vous ne connaissez pas Play! Framework, je vous conseille très vivement de suivre le tutorial officiel:
http://www.playframework.org/documentation
Ce n’est pas un simple « Hello, world » mais un tutorial bien plus long qui vous permettra de découvrir les nombreuses facettes de Play. Vous allez ainsi réaliser un « blog engine », avec personnalisation, soumission de formulaire, administration, internationalisation, tests et mise en production. Pour l’avoir fait de bout en bout, cela prend moins d’une heure et permet de bien comprendre les mécanismes qui se trouvent derrière Play.
Ici, on se trouve donc côté serveur mais même si on fait beaucoup de bruit sur tout ce qui se passe côté client, le serveur reste primordial. D’autant plus que tous les moteurs JavaScript que vous utiliser vos clients ne sont pas toujours des Webkits sous stéroïdes. Vous ne pourrez pas réaliser de « Rich Internet Application » sans faire une grosse partie du travail côté serveur.
Voici ce que j’aime chez Play!:
Aucun temps de compilation
Play! s’appuie sur le mécanisme de « hot reload » d’Eclipse, qui permet de recharger du code directement dans la JVM. On peut donc modifier les sources de son projet, rafraîchir la page dans son navigateur et voir la modification.
Personnellement, ça m’a rappelé ma (toute petite) expérience que j’ai eu en PHP, et le plaisir de ne pas devoir à recharger un Tomcat ou à lancer un build install Maven pour changer 3 caractères. Productivité maximale.
Possibilités de debug
Même si tout est rechargé à la volée, on peut toujours effectuer le debug dans son IDE, cela fonctionne sans problème. Rajoutez en plus les messages d’erreurs « humainement lisibles » générés pas Play qui ne vous donne pas simplement une grosse stack trace et vous obtenez un debug bien plus aisé.
En plus de cela, on peut voir que dans la version 2.0 de Play, Google Closure Compiler sera utilisé et affichera même des warnings/erreurs de compilation JavaScript directement dans le navigateur.
Encore une fois, très bonne expérience pour le développeur.
Le templating
Je vous rabâche ça depuis un moment mais j’essaie de trouver une sorte d’équivalent aux composant Flex. Et pour l’instant, ce qui y ressemble le plus, c’est peut-être le système de templating (côté serveur) de Play. Il est en effet possible d’isoler une partie du code dans un template (ou « tag » dans le jargon Play) mais aussi d’avoir des templates dans des templates pour la création de page complexes.
Dans sa version 1.x, Play utilise Groovy pour son engine de templating. Groovy est un langage simple, qui tourne sur la JVM. Pour ce que l’on utilise dans les templates (if / for principalement), il n’y a pas besoin d’avoir une réelle maîtrise de ce langage. Si vous connaissez un peu Java, c’est presque « naturel ».
Système de build et de dépendance
Le système de build est très important dans le cycle de développement d’une application « entreprise ». Le plus répandu et bien sûr Apache Maven mais je pense ne pas me tromper en vous disant que tous les développeurs qui y ont touché ont perdu quelques cheveux.
En version 1.x, le système de dépendances de Play est constitué d’un simple fichier dependencies.yml à plat qui parait du coup très simple et plus facile à manipuler que les XML de 5 pages de Maven.
Sur ce point, je ne suis pas sûr de savoir si c’est une bonne chose. Tous nos projets Java chez Business Geografic utilisent Maven et même si cela nous a pris des semaines à être configuré correctement, il est très apprécié par les développeurs de pouvoir ajouter une dépendance et de laisser Maven se débrouiller pour les dépendances transitives au travers des repository Maven déjà populaires. Par contre, le fort ralentissement d’Eclipse au démarrage est une plaie.
Dans sa prochaine version (2.x), Play intègre un nouveau système de build nommé « SBT » (Simple Build Tool) que je ne connais pas du tout. J’espère que cela pourra permettre de gérer les projets « mixtes », car cela m’a posé beaucoup de problèmes lors de mes tests en 1.x.
Une communauté active
Le Google Groups de Play est *très* actif:
https://groups.google.com/forum/?hl=fr#!forum/play-framework
Beaucoup de messages par jour et des réponses souvent pertinentes. J’ai personnellement laissé quelques questions dessus lors de mon apprentissage et j’ai reçu les premières réponses 20 minutes après avoir posté mon message.
De même, Play est basé sur un système modulaire, avec déjà de nombreux modules développés par la communauté (100+ je crois):
http://www.playframework.org/modules
Un très bon point pour les développeurs. Côté tutoriaux, c’est un peu plus léger mais la très bonne documentation officielle comble largement ce manque.