Cela fait maintenant 6 ans que je fais du Java de manière professionnelle, que je collectionne les jars et empile les frameworks tel un jeu de légo. Mais voilà c'est terminé ! Depuis 6 mois je fais du Ruby on Rails (aka Rails), aussi bien sur mes projets persos que professionnels ... laissez-moi vous expliquer pourquoi.
Lorsque l'on parle de Rails, on pense le plus souvent à ses caractéristiques totalement orientées vers la productivité du développeur :
#Exemple de manipulation de collection avec une closure
print ["google", "yahoo", "bing"].map{|host| "http://www.#{host}.com" }
> ["http://www.google.com", "http://www.yahoo.com", "http://www.bing.com"]
Ces caractéristiques ont sans aucun doute marqué le monde du développement, mais elles ont désormais été intégrées par de nombreux langages. Ainsi, Spring ou JEE sont profondément emprunts de c****onvention over configuration et de d****on't repeat yourself permettant d'alléger les fastidieux fichiers de configuration XML. Les langages JVM de nouvelle génération (dynamiques ou non) comme Groovy ou Scala sont désormais matures. Et pour finir, l'outil JRebel propose une solution efficace au problème de "hot deploy" en Java. Ces 3 points ne justifient donc pas en eux même de privilégier Rails à une stack Java.
Mais ne nous méprenons pas, la principale force de Rails est d'être un framework web ; en effet, point d'embarqué ou de client lourd en Rails. Mais cette spécialisation, qui correspond malgré tout à 95% de mon utilisation de Java en entreprise, est réellement un atout. En parlant de Java j'ai maintenant l'image d'un tank : ça fait tout, ça finit par passer partout, mais pas forcément de la plus efficace et la plus élégante des manières.
Le reste de cet article sera donc consacré à opposer Rails à Java en tant que frameworks web.
Mais au fait, Java peut il concourir dans la catégorie framework web ? Oui et non : Java n'est pas un framework web en tant que tel et l'on considérera en fait Java comme une pile de frameworks. On peut aussi bien utiliser la pile Java officielle (JEE), une pile alternative (comme Spring ou JBoss Seam) ou encore un assemblage à façon des nombreux frameworks existants.
Et en fin de compte, cette variété de frameworks nuit à Java : elle apporte beaucoup de complexité, aussi bien dans le choix des briques que dans leur assemblage. Ainsi la communauté Java s'est longtemps consacré à simplifier l'intégration entre les frameworks et entre les couches d'une application (l'IOC n'a jamais été aussi simple et peu verbeux). Cet objectif est aujourd'hui atteint et la pile standard Java est enfin devenue aussi légère à utiliser qu'elle devrait l'être.
Mais ceci s'est fait au détriment de ses fonctionnalités ! On s'estime aujourd'hui heureux en Java lorsque le framework que l'on utilise nous permet de mettre en oeuvre simplement le pattern MVC, de binder des objets sur des composants graphiques, de faire de la validation et éventuellement de faire un peu d'Ajax. C'est bien, mais c'est le b.a.-ba du web.
Si j'utilise aujourd'hui Rails, c'est parce que ce framework est définitivement plus abouti et plus riche en terme de fonctionnalités web. Rails (contrairement à Java) est le fruit de centaines de contributeurs oeuvrant tous dans le même sens : faire de ce framework le plus productif pour réaliser des applications web. Voici quelques exemples de fonctionnalités natives en Rails, et à mon sens vitales pour faire une application web en 2010 :
#controlleur MVC pour retourner un objet sérialisé en JSON
class BooksController < ApplicationController def show render :json => Book.find_by_id(params[:id])
end
end
class User < ActiveRecord::Base
#la classe est vide, les attributs de la classe sont induits depuis le schema de la base : schema.rb
end
#exemple de méthode dynamique : Rails interprète dynamiquement le nom de la méthode pour exécuter le code SQL correspondant
User.find_by_name
Et ce n'est pas parce que Rails bénéficie d'une direction claire et contrôlée qu'il n'existe pas de communauté. La contribution externe est très riche, et les frameworks pululent sur github. Voici quelques exemples de gem (i.e. librairie Ruby) absolument bluffantes :
Il y a bien entendu le risque de retomber dans une situation similaire à Java ou l'on se retrouve à assembler des stacks de gems totalement hétérogènes d'un projet à l'autre avec un surcoût d'intégration important. Mais Rails s'en sort mieux sur ce point car d'une part la "colonne vertébrale" d'un projet Rails est standard alors que ce n'est pas le cas en Java (où l'on peut être basiquement en JEE, Spring ou Seam), et d'autre part les meilleurs innovations sont régulièrement injectées dans le coeur de Rails (tandis que la standardisation d'un Hibernate en JPA reste une situation exceptionnelle)
La communauté Rails est extrêmement importante et les contributions sont variées :
Un critère devenu extrêmement important ces dernières années lors de l'évaluation d'un framework est sa testabilité. Qu'en est-il avec Rails ?
Et bien soyez rassurés, il n'y a aucun doute à avoir : Rails est le framework le plus testable que j'ai pu utiliser ces dernières années. La première raison est que par défaut un projet Rails embarque toute la mécanique permettant de mettre en oeuvre 3 stratégies de test différentes, toutes complémentaires, pour tester votre application :
#exemple de test d'intégration
class UserFlowsTest < ActionController::IntegrationTest
fixtures :users
test "login and browse site" do
https!
get "/login"
assert_response :success
post_via_redirect "/login", :username => users(:avs).username, :password => users(:avs).password
assert_equal '/welcome', path
assert_equal 'Welcome avs!', flash[:notice]
https!(false)
get "/posts/all"
assert_response :success
assert assigns(:products)
end
end
Et pas la peine de vous demander comment est géré l'état de la base de donnée pour ces tests : Rails gère pour nous toute cette configuration fastidieuse. Souvenez-vous donc ce que l'on doit faire en Java : configuration d'une base de données mémoire, génération automatique du schéma avec JPA, gestion des jeux de données DBUnit ...
La seconde raison est que la communauté Rails propose des outils de tests bluffants (et pour le coup, bien loin de ce qui existe en Java). Les deux que j'ai envie de retenir sont:
Sans aucun doute, Ruby on Rails peut donc être utilisé en contexte agile. Et comme l'agilité ne s'arrête pas aux tests, Rails va plus loin :
Alors vous pourriez me rétorquer que des frameworks similaires à Rails ont vu le jour en Java (ils sont nommés "frameworks productifs" en Java, le sous-entendu pour le reste de l'écosystème Java est on ne peut plus clair !) :
Ces frameworks productifs sont certes intéressants, mais vous vous mettriez clairement en retard de quelques années en utilisant un framework qui court derrière Rails. Et d'autre part vous vous priveriez d'une communauté extrêmement importante ... Rails est pour sa part un projet toujours extrêmement actif et la version 3.0.0 du framework vient tout juste de sortir. Un prochain article sera consacré à l'utilisation de Ruby on Rails en entreprise.
Cet article aura pu vous sembler partisan, mais il est difficile de contenir son enthousiasme lorsque l'on écrit sur une technologie aussi séduisante. Sachez tout de même que les principaux manques que j'ai pu constater tournent autour de l'industrialisation (qui pour le coup est un sujet très mature en Java) :
J'espère que j'aurai su vous éveiller votre curiosité au sujet de Ruby on Rails. Pour ma part, je n'ai pas autant pris plaisir à développer que depuis que j'ai découvert cet outil !
Alors, vous vous y mettez quand ?