Mon opinion sur Ember

Depuis quelques années, la mode est au framework JavaScript afin de créer des applications Web conviviales. En tant que développeur Rails, j’ai toujours voulu offrir des applications de qualité. Dans cet objectif, depuis plusieurs mois, j’apprends à utiliser Ember et je suis maintenant prêt a partager mon opinion.

Convivialité du résultat

L’objectif de l’utilisation accru du JavaScript est de donner à l’utilisateur une application d’une meilleure qualité, agréable à utiliser et rapide. Il est possible de créer ces applications en utilisant du bon vieux JavaScript et des bibliothèques simples comme JQuery, cependant c’est souvent ardu et fastidieux. Des frameworks plus complexes comme Backbone, AngularJs et Ember ont vu le jour afin de simplifier la création de ce type d’applications. Ils ont comme objectif de simplifier le code et nous donnent des solutions déjà faites pour un bon nombre d’opérations répétitives. Le fait d’avoir moins de code à écrire augmente la lisibilité du code et donc notre capacité à le maintenir. Grâce a cela, il est possible d’ajouter de la réactivité à une application plus simplement et donc d’augmenter la qualité de l’expérience de l’utilisateur.

Meilleure architecture

J’ai toujours trouvé que le point faible de Rails était la partie Vue de l’architecture (MVC). Les bonnes pratiques recommandent d’extraire au maximum la logique de la vue en créant des helpers, des presenters, des décorateurs, etc. Malgré cela, je trouve que le résultat final, au niveau de la vue, est toujours moins beau que pour le reste de l’application. C’est particulièrement vrai quand vient le temps d’ajouter du JavaScript. En effet, comme beaucoup, j’ai tendance à négliger le code produit en JavaScript au niveau tant de l’architecture que des tests unitaires. Pour tous ces points, Ember nous offre des outils pour faire du code à la fois plus simple et plus souple étant donné que cet outil est dédié à cette partie.

Ember prône l’utilisation d’EmberCli qui fait en sorte que la partie front-end, en JavaScript, devient complètement séparée de l’API en backend. Le fait de faire une API nous oblige à limiter le nombre d’éléments exposés par le backend. La logique du serveur devient donc plus simple et se concentre sur le métier et la persistance des données. De son côté, Ember permet de se concentrer sur la partie client et le fait d’offrir une interface rapide, réactive et conviviale. Cette séparation est, selon moi, tout à fait en accord avec le principe de responsabilité unique.

Le fait que la partie front-end soit découplée de la partie backend offre également la capacité de changer l’un ou l’autre si besoin. Même si, en pratique, il y a peu de chance que cela arrive, j’aime le fait de me sentir libre de choisir plus facilement.

Rapidité

Avec EmberCli, l’application est chargée en entier sur le navigateur. Cela a pour effet d’améliorer la navigation, car il n’est plus nécessaire de demander au serveur du HTML. De plus, la communication avec le serveur est asynchrone et donc la page s’affiche avant que les données soient chargées. Une fois reçues, les données sont affichées correctement.

Apprentissage difficile

Ember n’est pas fait pour les développeurs débutants. En lisant le guide d’Ember, on peut penser que tout est facile, mais, en pratique, on tombe rapidement sur des cas un peu moins standards qui font mal. Je dirais qu’il faut au moins un mois pour commencer à être à l’aise avec Ember.

Read The Fucking Manual

En Ruby, lorsque j’ai une erreur, j’ai tendance à googler rapidement et je tombe souvent sur une question sur StackOverflow ou une issue sur Github. Avec Ember, la plupart du temps, ça ne fonctionne pas. Ember est encore récent et bouge rapidement. Si vous trouvez une solution qui date d’il y a plus d’un an, il y a des chances que celle-ci ne fonctionne plus, car l’API a changé et des pans entiers du framework ont disparu. Les sources les plus fiables que j’ai trouvées sont, tout simplement, le guide d’Ember et la documentation de l’API. J’ai souvent trouvé les solutions à mes problèmes dans ces deux sources. Il faut parfois prendre le temps de s’arrêter et lire un peu.

Prenez le temps de lire un livre ou deux

La documentation officielle d’Ember va vous donner beaucoup de détails sur des éléments précis, mais assez peu sur l’intégration entre eux. Ces pour cette raison que je conseille de prendre le temps de lire des livres. Deliver Audacious Webs Apps with Ember 2 et Rock And Roll with Ember m’ont aider à avoir les bases pour commencer à créer une application. Ils vont vous donner une bonne base pour commencer et vous serez moins perdus quand viendra le temps de coder. Avant d’acheter un livre, faites attention à ce qu’il traite de la version à jour d’Ember.

Github est votre ami

N’ayez pas peur de lire le code. Ça fait toujours un peu peur de regarder ce qu’il se passe sous le capot d’un projet qu’on ne maîtrise pas. Cependant, je trouve que le code d’Ember est bien fait et souvent relativement simple à comprendre. Cela vaut également pour les add-ons.

Pourquoi Ember?

La plupart des éléments cités plus haut sont valables pour des frameworks comme Angular ou Backbone. On peut légitimement se demander pourquoi choisir Ember plutôt qu’un autre. Selon moi, Ember possède une philosophie similaire à Rails. Par défaut, Rails et Ember viennent avec une architecture et une philosophie similaire. Les opérations les plus triviales sont masquées sous une couche de « magie », et il n’est donc pas nécessaire de s’en occuper. Pour résumer, je dirais qu’Angular est l’équivalent de Sinatra en Ruby tandis qu’Ember est similaire à Rails.

Apprendre à sortir d’Ember

Lorsque l’on sauvegarde un modèle avec une association dans Rails, celui-ci va comprendre tout seul que les associations doivent être sauvegardées en même temps que le modèle. Ember ne possède pas encore autant de magie. Il est possible de trouver des solutions en utilisant du code Ember plus au moins pur, mais je crois qu’il faut parfois sortir d’Ember et ne pas oublier que ce n’est que du JavaScript. Il est toujours possible de faire de bonnes vieilles requêtes Ajax et du code à la main pour parvenir à notre but. Ember ne nous tient pas en otage.

La suite

Je pense continuer à apprendre Ember et à l’utiliser dans de nouvelles applications. Si l’aventure vous tente, lancez-vous! Si vous besoin d’aide, n’hésitez pas à me contacter. Ça me fera plaisir de vous aider.