L’heure du bilan pour le mois du JS

Le mois du JS se termine chez Xebia et il est temps de faire le point sur ce qui est ressorti de ces soirées dédiées aux frameworks MVC Javascript Angular, Backbone et Ember.

Les 3 premières soirées furent consacrées, sous forme d’atelier, à présenter chacun des frameworks. La dernière soirée était une table ronde réunissant les animateurs des ateliers sus-cités. Vous pouvez retrouver l’intégralité des échanges de cette soirée dans la vidéo ci-dessous.

L’objectif affiché de cette série d’événements était de permettre au public de se faire une idée des acteurs majeurs du marché des frameworks JavaScript, non seulement en testant eux-mêmes les frameworks via un atelier, mais aussi en discutant avec les organisateurs qui utilisent ces frameworks au quotidien dans leur mission. Le fait d’étaler cet événement sur 4 soirées a permis d’aller plus loin que le simple comparatif asséné à l’assemblé en permettant à chaque personne de se faire un avis, au moins sur la prise en main du framework.

On pourra résumer les forces et faiblesses de chaque framework :

Backbone

Backbone est un framework simple canalisant la puissance des deux célèbres librairies $ et _, auxquelles il ajoute une interface restful et une liste d’évènements custom. À l’aide de 4 classes, Modèle/Collection, Vue, Routeur, il structure les applications web sans essayer de réinventer la roue, plutôt de pousser un cran plus loin la manière dont elles ont été construites jusque-là.

Backbone est un cadre de travail ouvert : de nombreux choix sont laissés à la discrétion du développeur — requiérant une écriture de code parfois fastidieux. Des librairies comme Marionette, Chaplin ou  Rendr s’appuient sur Backbone pour offrir une opinion plus appuyée.

Les retours des 3 heures d’atelier ont salué la facilité de prise de main et l’adaptabilité de l’ensemble.

Ember

Ember est un framework full-stack et gère donc toutes les couches applicatives : routeur, contrôleur, vue et modèle. Le modèle de programmation objet poussé par Ember est un modèle à classe avec des mixins, ce qui facilite l’entrée dans le framework des développeurs provenant de langage ayant déjà une approche orienté objet du même type (Java, Ruby, etc.). Une des grandes forces d’Ember est le databinding, non seulement au niveau de la vue, mais aussi au niveau de tous les objets Ember. 

Le plus gros point noir d’Ember est sa difficulté d’apprentissage, le framework étant bâti suivant la philosophie « convention plutôt que configuration », l’apprentissage des conventions peut être un peu long et fastidieux. D’autant plus que la relative instabilité du framework (5 versions depuis janvier 2013, dont certaines avec des changements majeurs) fait que la documentation n’est pas toujours à jour.

Angular

Angular est aujourd’hui le framework MVC qui a le vent en poupe, le fait qu’il soit supporté par Google n’y étant sans doute pas pour rien. Parmi ses principales caractéristiques, on pourra noter l’injection de dépendance qui permet d’avoir un code mieux structuré et plus testable, le databinding bi-directionnel qui synchronise en permanence la vue et les objets gérés dans le scope des contrôleurs et ses directives qui permettent au développeur de réduire au minimum ses interactions avec le DOM de la vue. Les directives permettent aussi de créer de véritable DSL HTML (une sorte d’approche composant). Par ailleurs, Angular met l’accent sur les tests à la fois unitaires et end-to-end avec un outil intégré.

Cependant, Angular pèche encore un peu par une certaine complexité exposée au développeur lorsque celui-ci doit écrire ses propres directives. De plus, le dirty checking induit par le binding bi-directionnel implique une dégradation des performances lorsque le nombre d’éléments gérés par Angular augmente.

Conclusion

Comme souvent, il n’y a pas de réponse définitive à la question « Quel est le meilleur framework ? ». En effet, à la problématique du développement d’application single page, chaque framework apporte une réponse différente, laissant plus ou moins de liberté aux développeurs, étant plus ou moins facile à prendre en main ou encore étant plus ou moins performant dans certains cas. Le meilleur conseil que l’on puisse donner à une équipe voulant créer une application Web mono-page pour choisir son framework reste de tester chacun d’entre eux pendant quelques jours de façon à voir lequel correspond le mieux aux besoins (et aux développeurs) de l’équipe.