Traduction par Baptiste Meurant de l'article The Case for Ember d'Andrew Walton.
Dans cet article, Andrew Walton explique les raisons du choix d'Ember au sein de son entreprise et détaille ce qui le pousse à considérer ce framework comme le meilleur dans un tel contexte.
Pour les entreprises
Avec le temps, les entreprises commencent à adopter de manière bien plus importante les frameworks web côté client. Le mouvement de fond en direction des clients riches a atteint l'entreprise et il a frappé fort. Les leaders techniques des grandes entreprises prennent conscience des bénéfices qu'apportent les Single Page Applications (SPA - dont nous ne développerons pas les concepts ici) et tentent de les généraliser à l'échelle de l'entreprise.
Cela est vrai pour mon employeur actuel. Mon entreprise a fait face à de nombreuses transformations au fil des ans. De l'époque de PowerBuilder à de simples WebForms ASP.NET puis à Silverlight et aux applications web riches aujourd'hui. Notre volonté est d'utiliser les technologies web modernes pour créer la meilleure expérience utilisateur possible de manière à ce que nos clients soient satisfaits du service que nous leur fournissons.
Nous avons finalement commencé à utiliser Ember pour atteindre nos objectifs. Mon propos, en écrivant cet article, est de vous faire partager comment nous en sommes venus à utiliser Ember et pourquoi je suis convaincu qu'Ember est le meilleur choix que les grandes entreprises puissent faire, à l'heure actuelle, dans le paysage des frameworks web côté client.
Objectifs
Notre entreprise utilise actuellement un produit appelé "KendoUI" édité par Telerik pour créer des SPA. Kendo dispose d'une multitude de composants différents (framework de binding, routeur, etc.) correspondant à autant d'éléments indépendants qui ne sont absolument pas reliés les uns aux autres. Ce qui conduit à de nombreuses difficultés dans un contexte d'entreprise (nous aborderons ce point en détails dans le chapitre "facilité d'utilisation" plus loin). Après avoir travaillé pendant un certain temps sur ces difficultés, nous sommes parvenus à convaincre les bonnes personnes qu'il serait préférable de passer à un framework plus mature et plus complet.
Lorsque nous avons évalué les différents frameworks disponibles, nous avons pris en considération les éléments suivants :
- Facilité d'utilisation
- Est-il facile de maintenir une cohérence sur l'ensemble des projets de l'entreprise ?
- Est-il facile pour de nouveaux développeurs de monter en compétence sur ce framework ?
- Problématiques résolues
- Quelles sont les problématiques récurrentes que le framework résout pour nous ?
- Quels bénéfices concrets tirons-nous de l'utilisation de ce framework ?
- Prêt pour l'avenir
- Comment le framework prend-il en compte l'évolution et l'avenir du web ?
- Quelle est la probabilité qu'il se transforme radicalement ou soit abandonné ?
A ce moment-là, les deux principaux frameworks concurrents que nous avions identifiés étaient Angular et Ember. Vous pouvez évidemment vous demander "pourquoi n'ont-ils pas considéré X ?". Il existe en effet de nombreux autres frameworks que nous aurions pu prendre en considération tels que Backbone, Knockout, Sammy et j'en passe ... Le fait est que ces deux frameworks, Angular et Ember, représentent les deux poids lourds dans leur catégorie, celle des frameworks web complet, côté client.
Angular et Ember fournissent tous les deux un ensemble de fonctionnalités nécessaires à la création d'une application web riche complète (telles que le routage, le binding des données, etc.). Les autres outils ne fournissaient pas réellement l'ensemble de ces fonctionnalités et nous nous sommes donc concentrés sur ces deux frameworks. Examinons-les.
Facilité d'utilisation
Lorsque vous travaillez dans un environnement d'entreprise, vous n'avez pas seulement à prendre en compte comment telle ou telle technologie va fonctionner pour vous ou votre équipe mais également comment elle va affecter l'ensemble de votre organisation. Cela est particulièrement vrai lorsque l'on prend une décision aussi importante que le choix d'un framework web qui sera éventuellement utilisé au sein de l'entreprise entière. Dans ce domaine, Ember est sorti du lot pour plusieurs raisons.
Convention plutôt que configuration
Si vous n'êtes pas au fait de ce qu'est le principe de convention plutôt que configuration (convention over configuration), voici une courte définition (Wikipédia) :
Convention plutôt que configuration est une pratique informatique qui tend à faire décroître le nombre de décisions qu'un développeur doit prendre.
Je ne sais pas pour vous mais après avoir travaillé successivement sur des technologies se trouvant à chaque extrémité du spectre (à base de configurations uniquement puis à base de conventions pures), j'ai tendance à préférer les conventions presque à chaque fois.
Dans un contexte d'entreprise composé de nombreux développeurs répartis dans de multiples équipes, l'utilité de ce paradigme de conception n'est pas surévalué. Si le principe de convention plutôt que configuration n'est pas appliqué dans un contexte d'entreprise, vous allez plus que probablement finir avec d'interminables réunions, discussions et argumentations sur la moindre décision conceptuelle. En utilisant le principe de convention plutôt que configuration, au contraire, bon nombre de ces décisions sont effectuées pour vous par les conventions choisies et ne sont alors plus sujet à débats.
Ember est conçu avec ce principe de convention plutôt que configuration à l'esprit. En choisissant cette approche, le nombre de questions qu'un développeur doit se poser à propos de la manière de développer une application avec ce framework est considérablement réduite. Si vous rencontrez, cependant, une situation pour laquelle la convention ne fonctionne pas, Ember fournit l'ensemble des mécanismes nécessaires pour surcharger cette convention et traiter la situation à votre façon.
Vous avez peut-être entendu dire qu'Ember était un framework ayant des opinions très fortes, ce qui est parfaitement vrai et le résultat direct de cette philosophie. Ember s'appuie sur des opinions et principes forts et éprouvés. Cela aide les équipes de développement à se concentrer réellement sur les fonctionnalités et l'ajout de valeur métier plutôt que d'être rattrapé par d'interminables réunions et discussions sur la manière d'implémenter tel ou tel concept technique général. L'équipe d'Ember a largement contribué à Ruby on Rails qui a lui-même inspiré le framework MVC ASP.NET. Comme notre entreprise est composée en grande partie de développeurs .NET, ceci leur permettra de retrouver des patterns similaires et de réaliser plus facilement les ajustements nécessaires.
Angular n'a pas été conçu selon le principe de convention plutôt que configuration. Avec ce framework, la grande majorité des décisions conceptuelles sont laissées au développeur. Un grand nombre de ces décisions sont débattues y compris au sein même de la communauté Angular. Par exemple, si vous allez sur un forum et posez une question telle que "Où dois-je gérer mes modèles avec Angular ?", vous recevrez des réponses très différentes. Il n'existe pas de conventions qui dictent comment les différents éléments doivent s'assembler ou comment certaines tâches doivent être implémentées. Cela augmente l'ambiguïté pour un développeur et se traduit par des réunions dans le but de prendre des décisions de conception simples, engendrant une baisse de productivité.
En outre, s'agissant d'une entreprise, toutes ces décisions doivent être documentées pour que les futurs développeurs puissent rapidement être efficaces. Cela vous oblige donc à gérer deux sources de documentation différentes : la documentation officielle d'Angular et celle de votre entreprise. Vous vous retrouvez donc avec la charge d'enseigner aux nouveaux développeurs la bonne manière d'écrire des applications avec Angular.
Un certain nombre de gens apprécient la liberté que leur laisse Angular de par son manque de conventions et je ne critique pas du tout cela. Cependant, dans un environnement d'entreprise, cela augure des ennuis 9 fois sur 10. En réalité, l'équipe d'Angular apprécie vraiment le paradigme de convention plutôt que configuration. Lisez plutôt cet article qui explique comment ce paradigme va être introduit dans la version 2.0 du framework.
Documentation
Lors de l'adoption d'un nouvel outil ou d'une nouvelle technologie au sein d'une organisation d'entreprise, la documentation est un élément clé. La capacité à faire rapidement monter en compétences les développeurs est intimement liée à la documentation, qu'elle soit interne ou produite par la communauté. Dans le premier cas, l'organisation doit consacrer le temps et les efforts nécessaires pour la production d'une documentation de qualité. Dans le second cas, elle peut se contenter de renvoyer les développeurs vers la documentation officielle sans avoir à investir des ressources significatives dans la production d'une documentation spécifique.
Bien qu'Ember ait eu, un temps, des faiblesses dans ce domaine, il a depuis fait d'énormes progrès et est l'un des frameworks les mieux documentés. Son site principal est rempli à ras-bord de tutoriels, d'exemples de codes et de conseils sur l'utilisation de chaque élément du framework MVC. L'API publique d'Ember est également très bien documentée bien qu'il s'agisse d'un aspect bien souvent sous-estimé ou tout simplement ignoré.
Du côté d'Angular, la documentation a été longtemps source de difficultés pour les développeurs. La documentation de l'API publique manque bien souvent d'exemples de code. Par exemple, si vous examinez la documentation des routes, vous la trouverez sans doute insuffisante. Ce point et particulièrement inquiétant car le routage constitue l'épine dorsale d'une Single Page Application.
Problématiques résolues
Lors du choix d'un nouveau framework, vous devriez toujours vous poser ce genre de questions :
Que m'apporte l'utilisation de ce framework ? Une réduction de la complexité du code ? Des solutions éprouvées aux problématiques fréquentes non triviales ?
Pourquoi devrais-je utiliser ce framework plutôt que développer tout moi-même ?
Les principaux acteurs du domaine des frameworks client vous permettent assurément de répondre à ces questions dans un sens favorable à l'utilisation de frameworks. La question devient alors :
Quel framework m'apporte le plus et m'aide à résoudre le maximum de problématiques habituelles de la meilleure des manières ?
Pattern d'état
Lorsque l'on travaille sur d'importantes applications disposant d'une interface utilisateur riche, utiliser le pattern d'état rend la vie beaucoup plus simple. L'usage du pattern d'état est très répandu en informatique et il existe des livres entiers écrits sur le sujet. Je ne rentrerai donc pas dans les détails ici. Il suffit de savoir que l'usage dudit pattern est très utile dans la cadre d'applications à interfaces utilisateurs riches.
Avec Ember, le pattern d'état est une "règle d'or" et est intégré au sein même du coeur du framework. Angular, de son côté, n'affiche pas cette opinion. Puisque nous parlons d'applications aux interfaces utilisateurs riches, nous aurions besoin de construire notre propre pattern d'état avec Angular. A cela s'ajoute les tâches liées à la nécessité de créer la documentation de notre code et de s'assurer de l'application par tous de ces règles.
Le fait que le pattern d'état soit au coeur d'Ember nous dispense d'avoir à écrire le nôtre et à réinventer la roue.
Gabarits
La plupart des frameworks client font des choix différents concernant le langage utilisé pour les gabarits. Cela peut parfois être négligé mais je pense qu'il s'agit d'un point important. Choisir un bon langage pour vos gabarits vous permettra de mettre en place une véritable séparation des préoccupations et vous évitera de nombreux maux de tête.
Ember s'appuie sur des gabarits Handlebars qui sont, par nature, logic-less. Les gabarits logic-less fournissent un modèle robuste pour la construction de tests unitaires. Ils vous forcent également à découpler votre logique client de votre structure de page, créant ainsi une séparation claire des préoccupations.
En revanche, vous pouvez intégrer la logique au sein de votre structure de page avec Angular. Cela rappelle fortement le modèle ASP classique avec des if éparpillés un peu partout. Afin de maintenir une séparation claire des préoccupations, il serait nécessaire que vous produisiez une documentation stricte sur la manière de produire vos gabarits et que vous mettiez en place un mécanisme pour faire appliquer cette stratégie. Tout comme la non application des principes de convention plutôt que configuration, cela peut rapidement poser problème au sein d'un environnement d'entreprise.
Persistance des données
La création d'un mécanisme permettant, d'une manière ou d'une autre, de persister les données est essentielle pour une application web. Si vous travaillez sur une application web dans un environnement d'entreprise, vous aurez forcément à vous occuper, à un certain moment, de la persistance des données.
Bien qu'il soit encore en beta, Ember Data fournit une couche d'abstraction très intéressante qui prend en charge les interactions avec de multiples sources de données telles qu'une API REST ou encore un stockage local dans le navigateur (pour un usage déconnecté). Ember Data permet également la création de fournisseurs de données personnalisés.
Angular, de son côté, ne propose pas de méthode de gestion de la persistance des données. La logique d'accès aux données doit être implémentée manuellement. Si vous interagissez avec une API REST, cela signifie faire un usage intensif de l'AJAX de jQuery ou des APIs XHR bas niveau. Cela n'adresse pas non plus les problématiques de comportement en mode déconnecté.
Le fait qu'Ember dispose d'un mécanisme natif de gestion de la persistance des données permet la résolution d'une problématique très fréquente et bien souvent non triviale que la plupart des applications web doivent appréhender. Le fait que ce mécanisme marche très bien et soit en constante amélioration en fait un avantage encore plus important.
Prêt pour l'avenir
Afin de répondre par avance à toute remarque quant à mon utilisation de l'expression "prêt pour l'avenir", je tiens à préciser que je ne suis pas en train d'affirmer qu'Ember est aujourd'hui "prêt pour l'avenir". Je dirais d'ailleurs qu'aucun framework actuel ou futur n'est ou ne sera "prêt pour l'avenir". Mais laissez-moi définir ce que j'entends par "prêt pour l'avenir" :
"Prêt pour l'avenir" : capacité d'un framework à prendre en compte l'évolution permanente du web et à s'adapter au changement.
Lorsque l'on regarde la manière dont s'est construit Ember ainsi que l'état actuel des choses, il apparaît clairement que l'équipe de développement principale est résolue à maintenir le framework à jour et à utiliser les dernières technologies. Non seulement les développeurs y sont résolus mais ils ont également précisé dans "The Road to Ember 2.0 RFC" qu'ils comptaient le faire sans détourner d'eux les développeurs utilisant la version 1.x du framework.
Le fait qu'Ember utilise un mécanisme de RFCs pour partager leur roadmap avec leur communauté en dit long sur leur engagement vis-à-vis de celle-ci. Pour ceux qui sont peu familiers du concept, une RFC (Request For Comment(s)) est une demande de commentaire(s). On trouve sur la page Github des RFCs Ember :
Le processus de "RFC" (demande de commentaires) est destiné à fournir une manière cohérente et contrôlée d'intégrer de nouvelles fonctionnalités au framework.
Si vous suivez le lien ci-dessus, vous remarquerez qu'il existe un processus pour soumettre une RFC. Au sein de ce processus, il existe une étape permettant de créer une RFC et de soumettre une pull request sur leur dépôt Github. Cette étape est extrêmement importante car tout l'objectif consiste à recueillir non seulement les réactions de l'équipe principale mais également celles de la communauté dans son ensemble. Ceci permet de prendre en compte de nombreuses idées et scénarios issus du monde réel avant toute action. C'est un énorme avantage pour la communauté !
Tout au long de l'année (2014), l'équipe Ember a réalisé de nombreuses avancées permettant de garder le framework à la pointe de la modernité. Ils ont investi dans les standards ouverts tels que les modules JavaScript (ES6), les promesses et les web components. Ils ont également investi massivement dans ember-cli afin que les développeurs n'aient plus à mettre en place leurs propres pipelines pour leurs applications Ember.
L'équipe Ember n'a pas non plus l'intention de ralentir à l'avenir. Ils se basent sur un cycle de releases agressif de 6 semaines et ajoutent en permanence de nouvelles fonctionnalités. Comme indiqué dans la RFC, l'équipe prévoie de faire d'ember-cli et des modules ES6 des composants centraux et ils adoptent également progressivement des nouveaux concepts en provenance d'autre frameworks (tels que le virtual DOM de React). Cela montre que l'équipe est entièrement dévouée à garder le framework "prêt pour l'avenir" selon la définition que j'ai donné plus haut de cette expression.
Maintenant, je ne veux en aucune façon dénigrer tous les progrès effectués par l'équipe Angular tout au long de cette année. Ils ont fait beaucoup de choses vraiment cool et Ember a tiré de nombreux enseignements des travaux sur Angular. Une saine compétition dans ce domaine est un atout pour la communauté et doit continuer. Sans cette compétition, nous risquons la stagnation et nous ne souhaitons certainement pas cela !
Avec la récente annonce d'Angular 2.0, les développeurs principaux d'Angular ont également publiquement déclaré qu'il n'y avait pas de voie de migration de la 1.X à la 2.0. Bien que je puisse voir les bénéfices d'une telle situation, j'ai vraiment le sentiment que l'équipe d'Angular peut être amenée, par les retours de la communauté, à reconsidérer sa décision. En réalité, l'article "All about Angular 2.0" de Rob Eisenberg est une indication claire que l'équipe subit actuellement de nombreuses critiques de la part de sa communauté. Rob est l'un des développeurs principaux et il plaide pour que les autres développeurs de l'équipe reconsidèrent leur position et encourage également la communauté à faire part des difficultés et des inquiétudes qu'elle peut avoir à ce sujet. Mais dans l'ensemble, je suis sûr que ce sera un excellent produit et je suis impatient de découvrir la nouvelle version d'Angular qui devrait voir le jour vers la fin 2015. En réalité une saine compétition entre les différents frameworks client ne peut être que bénéfique pour nous en tant que consommateurs !
Parce que l'annonce d'Angular 2.0 n'avait pas encore été faite quand nous avons pris notre décision, celle-ci n'a pas influencé notre décision. Elle nous a cependant assurément confortée dans notre décision de choisir Ember. Elle serait en revanche un facteur décisif si nous avions à faire ce choix aujourd'hui plutôt qu'il y a quelques semaines.
Engager l'entreprise
En guise de (très) brève parenthèse, je tiens à pointer une RFC particulière qui démontre la capacité de l'équipe d'Ember à reconnaître la nature même de leur base d'utilisateurs. Cette RFC a été créée par Tom Dale et porte sur le fait que de nombreuses entreprises ont adopté Ember. D'après cette RFC :
De grandes entreprises adoptent de plus en plus fréquemment Ember.js pour réaliser l'ensemble de leur gamme de produits. Souvent, cela signifie des équipes séparées (parfois réparties dans le monde entier) travaillant sur la même application. En règle générale, la responsabilité est partagée entre ces équipes en divisant l'application en une ou plusieurs "sections".
Parfois, chaque "section" constituera une application Ember à part entière et une barre de navigation permettra aux utilisateurs de basculer d'une application à une autre.
Il se trouve que mon entreprise va se retrouver dans ce cas précis dans un an ou deux. Nous avons beaucoup de "sections" qui seraient mieux structurées en devenant des applications Ember à part entière. Le fait que l'équipe d'Ember ait pris en compte ce scénario en dit long sur leur engagement envers leur framework et leurs développeurs.
Conclusion
En fin de compte, l'utilité d'Ember dès aujourd'hui combinée avec des évolutions fréquentes et l'engagement de l'équipe principale ont rendu la décision assez simple.
S'agissant de la facilité d'utilisation, Ember est vainqueur :
- Convention plutôt que configuration
- Très bien documenté
Ember permet de résoudre de nombreuses problématiques récurrentes et les résout bien :
- Pattern d'état
- Gabarits
- Persistance des données
L'équipe d'Ember a également montré qu'elle était engagée dans le processus de "Stabilité sans stagnation" :
- Modules JavaScript (ES6)
- Promesses (promises)
- Web components
- Introduction progressive des évolutions tout en conservant un processus de migration clair pour les utilisateurs actuels
- Conscience aiguë de l'adoption du framework par les entreprises
Dans l'ensemble, la version actuelle d'Angular a accumulé juste assez de dette technique pour qu'Ember soit aujourd'hui le net vainqueur pour notre entreprise. Ne me prenez cependant pas au mot et prenez connaissance du lien suivant : http://eisenbergeffect.bluespire.com/angular-and-durandal-converge/. Rob Eisenberg est le créateur de Durandal et désormais l'un des membres de l'équipe Angular. Ce lien décrit en détails comment il participera à la réécriture pour Angular 2.0 et y intégrera certaines des idées fondatrices de Durandal. Je recommande vivement la lecture de cet article pour comprendre le raisonnement qui a conduit à la décision de réécrire Angular complètement ainsi que se faire une idée plus précise de ce que sera l'avenir d'Angular.
NDT : depuis l'écriture de cet article, Rob Eisenberg a décidé de quitter l'équipe Angular et a expliqué son choix ici : Leaving Angular.
Au sujet de l'Auteur
Andrew Walton vit en Ohio, USA. Cela fait plus de 5 ans qu'il développe de manière active des applications web, principalement sur des plateformes Microsoft telles que ASP.NET MVC, et récemment sur des plateformes plus modernes telles que NodeJS, MongoDB et EmberJS, que ce soit en back-end ou en front-end.