Quand vous faites du développement Javascript depuis un certain temps, vous finissez forcément par vous apercevoir que le langage n'est pas forcément simple à utiliser proprement. Rappellez-vous : au début, document.write() était considéré comme le net plus ultra de la génération dynamique de code. Ca date.

Au fur et à mesure de la prise de conscience générale que le JS, c'est quand même vachement cool, un besoin s'est de plus en plus fait sentir : celui d'établir des process clairs en ce qui concerne le développement d'applications enrichies. Des initiatives ont été prises petit à petit, mais se sont pendant longtemps bornées au rôle de bibliothèque : Prototype, Scriptaculous, jQuery, Dojo, ... sont autant de bibliothèques relativement vieilles ayant facilité l'écriture de tâches spécialisées.

Cependant, c'est très récemment que le concept d'application enrichie s'est véritablement démocratisé. Cela a plus ou moins coincidé avec la création de la bibliothèque Backbone. Cette dernière fournissait non pas des fonctionnalités, mais plutôt des process de développement. Elle définissait ce qu'était un modèle, une collection et une vue, permettant aux développeurs sur des bases relativement solides. C'était une première, très peu de bibliothèques allaient dans ce sens à cette époque (on peut citer par exemple Ext.js, mais cette dernière était très spécialisée et n'était pas adaptée aux sites classiques).

Durant les derniers mois (les dernières années, en fait), j'ai pratiqué beaucoup de Backbone. D'abord par effet de mode, puis parce que j'aimais bien ce côté structuré de la bibliothèque : j'aime beaucoup tout ce qui se rapproche à de la conception. Cependant, j'ai toujours trouvé qu'il y avait plusieurs problèmes inhérents à la bibliothèque : la gestion de template était très erratique, le binding (et surtout unbinding) d'évènements était limité, et il n'y avait pas vraiment de consensus sur la façon de faire du bon backbone. En conséquence, il était souvent possible de faire du bon travail avec la bibliothèque, mais également souvent au prix d'efforts de réflexion dès lors que l'on voulait faire quelque chose de propre.

Il y a environ trois mois, j'ai entrepris la création d'un projet personnel dont je parlerais peut-être un jour. Conscient des limites de Backbone que j'ai évoqué ci-dessus, j'ai voulu me tourner vers une des autres bibliothèques qui ont vu le jour à la suite de Backbone. M'étant précédemment essayé à Ember.js, je suis tout d'abord retourné dessus. Autant dire que je n'y suis pas resté longtemps. Un framework qui me parle de machine à état lorsque l'on touche à du routing rate clairement quelque chose dans mon esprit. Bref, je n'ai pas du tout aimé Ember, et m'en suis donc rapidement détourné.

Mon second essai a été avec Angular. Et là, je dois le reconnaitre, je suis assez épaté.

Pour ceux qui ne la connaisse pas, Angular est une bibliothèque créée par les équipes de Google et censée apporter leur réponses à la question : "comment faire une application enrichie en utilisant les deux technologies natives : HTML et Javascript ?". Cette bibliothèque est particulière à plusieurs niveaux :

  • Elle s'intègre directement au sein du document lui-même. Vous n'avez (à ma connaissance) pas de template en Angular. Et s'il en existe, je pense que les use case sont particulièrement bien cachés
  • Elle étend l'HTML en rajoutant des balises logiques telles que if ou forEach
  • Elle gère en interne toute la magie de la mise à jour des éléments au fur et à mesure de la modification des collections
  • Chaque composant peut posséder son propre controlleur, en réalité une simple fonction Javascript

Ce billet ne rentrera pas en détail dans son fonctionnement, pour cela vous devrez le découvrir par vous-même (ou me recruter :). Cependant, sachez que j'ai été véritablement impressionné par la simplicité du fonctionnement d'Angular. La courbe d'apprentissage est très rapide (une seule notion nécessaire : le scope), l'écriture tout aussi rapide (quelques balises nécessaires pour les forEach, quelques lignes pour remplir un tableau JS, Angular se charge du reste), et l'ensemble est partiulièrement scalable. Si vous supprimez un élement d'une collection, vous supprimerez aussi les handlers qui y sont attaché, ne changeant ainsi rien à la fluidité de l'application.

En bref, utilisez Angular. Ne serait-ce que dans un projet personnel. Faites une todo, puis comparez avec le code Backbone qu'il vous aurait fallu. Vous constaterez une nette différence dans la clareté du code, ce qui le rendra plus facilement modifiable lorsque vous voudrez plus tard l'adapter à de nouveaux besoins.

Mon dernier travail en freelance concerne du Backbone. Je ne peux m'empêcher de remarquer qu'utiliser Angular aurait permis de résoudre un très grand nombre de problématiques en un claquement de doigts, et d'éviter un énorme travail 'inutile' pour 'chauffer' l'environnement avant de commencer le code de l'application proprement dit.