Back from Devoxx : Play! 2, hopes and fears

Le mois de Novembre est de loin le préféré des Javaistes et tous ceux qui le peuvent se rendent à Devoxx, la plus grande conférence européenne sur Java. Plutôt que de commenter chaque session vue, je vais essayer de synthétiser mes impressions sur ces 3 jours de conférences.

Devoxx c’est 5 jours, 2 d’universités et 3 de conférences, à Anvers avec 3300 développeurs. C’est beaucoup de rencontres, des gens que l’on apprécie mais que l’on ne croise qu’aux conférences, et d’autres que l’on voit pour la première fois (et que l’on tente de reconnaître des avatars twitter, avec plus ou moins de succès!). L’organisation est extrêmement bien rodée (10 ème édition) et l’équipe de Stephan fait un travail incroyable (vous imaginez servir 3300 geeks affamés pendant une semaine dans un cinéma où se déroulent 6 tracks en parallèle?).

Il y avait de nombreux sujets traités mais je vais me concentrer sur les sujets qui n’étaient pas ou peu présents l’année précédente, en commençant par Play! dans ce premier article.

Avec aucun talk l’année dernière et 3 cette année, on peut dire que Play! a fait du bruit! Nous avons notamment eu l’annonce de la beta release de la version 2.0 et du rapprochement avec la société Typesafe. Une version qui comme le laisse supposer l’intégration dans la stack de Typesafe s’oriente vers Scala, même si Java sera toujours supporté (l’animation en haut à droite de ce site vous donne une bonne idée de l’évolution).

Fears

Cette décision me gêne un peu personnellement et d’après les échos que j’en ai eu, n’est pas forcément très populaire. Vous pouvez installer cette bêta et vous faire une idée par vous même avec la documentation disponible, mais la simplicité que l’on aimait dans la version 1 disparaît un peu. J’ai attendu quelques jours avant de faire ce billet, car je voulais tester un peu par moi même et prendre la température autour de moi et sur le web. Que nous amène donc cette v2 ?

Même si il est possible de rester sur une version Java pour la partie serveur, le moteur de template est pour l’instant en Scala uniquement, alors que Groovy jusqu’à présent faisait un très bon travail en se faisant oublier. Scala amène un typage plus fort donc une détection plus en amont des erreurs éventuelles, ce qui est louable. Trois exemples d’application sont disponibles avec la bêta, et pour avoir joué un peu avec, ce changement ralentit pas mal la compilation des templates : là où on passait son temps à rafraîchir le navigateur pour avoir instantanément le résultat, on attend maintenant un peu que la compilation se fasse, malgré le fait que mon laptop (MacBook Pro) soit relativement puissant. Le système de template Groovy sera peut être sauvé par la communauté  et réintroduit.

Et Scala est certainement un très bon outil lorsqu’on le maîtrise mais il demande globalement plus d’investissement, et là ou la v1 permettait de se plonger rapidement dans le code, cette v2 inquiète un peu par sa complexification inutile. La documentation est encore un peu légère (normal pour une bêta) donc ces craintes sont peut être inutiles mais j’en doute…

La compatibilité est de plus brisée, vous ne pourrez pas upgrader votre application sans un peu de travail. Le système de build est maintenant confié à SBT, le maven-like de Scala : plus de fichier dependencies.yml donc, et l’ensemble de commande est devenu un wrapper de SBT. A voir à l’utilisation, un peu de lecture si vous voulez approfondir.

Hopes

Tout n’est heureusement pas à jeter dans cette nouvelle version! On peut noter l’utilisation d’IO non bloquant (à la nodejs entre autre), et le traitement asynchrone plus développé (concept Iteratee/Numerator issu de Haskell). L’introduction d’Akka permet de supporter une lourde charge tranquillement et le framework Play! a lui même été en partie réécrit pour en utilisant ces concepts. La démo montre que 10000 requêtes ne posent pas de problème au serveur qui monte au maximum à 15Mo de RAM, et redescend à 2Mo une fois la vague passée : impressionnant, même si les requêtes ne faisaient aucun traitement métier. Play! pourrait devenir un outil de choix pour les applications à très fortes volumétries.

L’abstraction de l’accès aux données est réduite au maximum pour laisser aux développeurs le choix du datastore approprié. On retrouve tout de même les entités avec annotations JPA, et Ebean a remplacé Hibernate et amène un finder pratique pour requêter la base, et plus stateless que son prédécesseur. Dans mes rapides tests, on n’est pas vraiment dérangé par cette nouveauté, à creuser plus en détails.

Côté client, l’objectif est de permettre d’intégrer les excellentes technologies que l’on voit apparaître comme Jade, Less (c’est mon prochain billet de la série Nodejs), Backbone.js, Coffeescript. Un répertoire ‘assets’ a été ajouté à la structure du projet et les fichiers contenus sont automatiquement compilés et disponibles comme si ils étaient des ressources (par exemple les .coffee sont compilés en js et disponibles comme si le js était dans le répertoire public).

Les routes sont également compilées et ça c’est très pratique ! Si le controller ou la méthode indiqué dans le fichier route est inexistant, vous le savez immédiatement.

Dans les petits bonus plaisants, on peut maintenant écrire (en Scala) « def index = TODO » qui permet de continuer à écrire son code sans se préoccuper de l’implémentation du controller. Si on appelle cette méthode, elle affiche dans votre navigateur une belle page avec TODO. Le genre de détail ‘nice to have’.

Si vous voulez approfondir et vous faire votre avis, voici quelques liens qui peuvent vous intéresser :  la page officiellele blog Ipponle blog du Touilleur.

So what ?

Play est définitivement devenu populaire, et apprécié par beaucoup. Je fais partie de ceux qui apprécient son côté simple, productif, efficace et fun et qui l’ont utilisé pour faire des sites actuellement en ligne. Cette v2 me laisse un peu sceptique, n’étant pas spécialement un fanatique de Scala. C’est un excellent langage et très puissant, mais aussi très exigeant à produire et maintenir (des personnes autrement plus qualifiées que moi se sont déchainées sur le sujet ces derniers temps). Là où Play! faisait merveille pour commencer une application en 10 minutes après la lecture de 3 pages de tutorial, la v2 s’oriente vers une stack haute performance plus élitiste. Peut être que dans un an Scala/Play nous aura conquis. Dans tous les cas la hype est toujours là, il va falloir tester ça!

About these ads

À propos de Cédric Exbrayat

Cédric Exbrayat, développeur et fondateur Ninja Squad, se réunit avec ses semblables régulièrement que ce soit au Lyon JUG ou à Mix-it, dont il est le fondateur. Java et JS for food and fun.

Publié le 29/11/2011, dans Conference, News, et tagué , , . Bookmarquez ce permalien. 3 Commentaires.

  1. Merci pour cet excellent retour Cédric! Je partage tes Fears… ;-) Je t’en dirai plus quand je l’aurai mieux testé!

  2. Hello,

    Petit commentaire pour rebondir sur ce que tu viens de dire.

    Comme tu l’as souligné Play 2.0 va pouvoir supporter de très grosses charges. Et ceci grâce à la compilation des routes et templates, le tout dans un environnement complètement asyncrone et très fortement typé.

    Maintenant cela se fait au prix de moins de magie et de « full-stack ». En réalité c’est une volonté qui semble affirmée de faire quelque chose de très structuré et cohérent afin d’aider la maintenance et garder une vision claire (cf. Google group). La magie est transférée sur les plugins, il faut donc compter sur la communauté pour créer des raccourcis. Un plugin MongoDb semble être démarré, Typesafe a créé un mini-play qui s’assimilerai à quelque chose proche de Ruby-Sinatra, un plugin Groovy est dans le pipe… Au final, là où Play1 est un framework fullstack (ce qui a perdu RoR à un moment), Play2 est plus composable.

    Pour ce qui est de la simplicité / rapidité à bootstrapper, c’est vraiment à imputer à la jeunesse de la beta à mon avis. Si tu regardes cette page ( https://github.com/playframework/Play20/tree/master/framework/resources ), on voit que les projets par défaut bougent encore pas mal, et le démarrage d’une appli en dix minutes n’est pas très loins. En plus on devrait pouvoir mettre nos propres templates de projets et donc avoir par exemple : play-scala-mongo — play-java-postgres — play-java-mysql-groovy…

    Pour terminer, les différences de simplicité & productivité entre les deux versions selon moi:

    – Les routes sont plus strictes, on ne peux plus mettre des trucs en travaux n’importe comment (le système de routes par annotations de play-mini peut corriger ça)
    – Les templates scala doivent référencer les paramètres qui lui sont passés (perso je suis fan des templates en scala, mais un plugin Groovy ou Mustache serait plus souple)
    – Les dépendances ne sont pas dans un fichiers simple, mais dans build.scala, mais il suffit de copier-coller ses jars dans /bin/ si on veut aller vite.
    – Les controllers ne détectent pas automatiquement le template associé, et la syntaxe Ok( [Result] ) est plus verbeuse, perso c’est ce qui me gêne le plus.
    – Il n’y a plus de CRUD (surement parce qu’il n’y a plus un gros support des datastores)

    Je pense que tout ce qui sera chiant à l’usage fera l’objet de plugins / améliorations, et pour le moment le framework n’est pas mature donc il est assez difficile de s’en rendre compte.

    A.

  1. Pingback: Un an de hype! « Hype Driven Development

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 076 autres abonnés

%d blogueurs aiment cette page :