Accueil > Web > AngularJS : LE framework SPA incontournable ? Pas si simple…

AngularJS : LE framework SPA incontournable ? Pas si simple…

Depuis 2013, AngularJS est devenu LE framework à la mode par excellence. Porté par Google, il fait l’unanimité chez les développeurs. Depuis, nous avons assisté à une ruée vers AngularJS. Lorsque les entreprises démarrent un projet web, elles décident de le faire en AngularJS, parfois sans une réelle étude d’impacts. Du coup, pour pouvoir suivre, les SSII ont embauché ou formé à tour de bras des développeurs AngularJS. L’hégémonie du framework de Google est elle sans partage ? Mais que deviennent les autres frameworks SPA (Single Page Application) pendant ce temps ? N’avons-nous pas été un peu trop prompts à tout investir sur un unique outil ? Dans cet article, je vais essayer de vous faire partager mon point de vue sur l’évolution actuelle des frameworks SPA et sur les questions que l’on doit se poser en démarrant un projet.

 

Une hégémonie toute relative

 

Quand on regarde sur github, AngularJS est clairement beaucoup plus suivi par les développeurs que ses concurrents, comme le montre le diagramme suivant :
github

On notera la progression importante de ReactJS. Le framework de Facebook commence vraiment à se rapprocher d’AngularJS qui reste encore la technologie la plus à la mode chez les développeurs.

En revanche, lorsqu’on consulte les statistiques d’utilisation des frameworks sur les principaux sites, l’hégémonie d’AngularJS vole en éclat. En analysant les détections de frameworks sur wappalyzer (backboneJS & angularJS), on obtient environ 360,000 détections de backboneJS et environ 95,000 d’AngularJS. Des résultats confirmés par builtwith (backboneJS & angularJS) pour qui 638 des 10000 sites ayant le plus de trafic utilise Backbone, contre 551 pour AngularJS. * chiffre au 22 octobre 2015

On observe donc que la réalité est bien loin de l’effet de mode observé dans la communauté des développeurs.

 

Un framework ou un autre

 

Pour essayer de comprendre cette utilisation contrastée d’AngularJS on peut faire un tour d’horizon des principaux frameworks du moment, à savoir, AngularJS, Backbone, Ember et ReactJS.

 

AngularJS

angularjs

AngularJS est un couteau Suisse génial pour les développeurs web. Il simplifie la gestion du rafraîchissement des données avec le double data-binding. Il permet de réutiliser des bouts de code entier avec l’utilisation des directives. Il structure votre code avec les modules, les contrôleurs, les services, les factory… Pour résumer AngularJS est bon à tout faire.

Mais il n’est pas parfait pour autant. Le data-binding est certes très puissant mais en retour très gourmand en ressources (ce qui est problématique sur les appareils mobiles). Les directives introduisent une meilleure réutilisabilité des composants mais leur utilisation avancée n’est pas des plus triviales et demandera une certaine expérience. Il est très structurant, mais impose une certaine montée en compétence afin de respecter les best-practices.

 

Backbone JS

backbone-js

Backbone JS est un framework léger, rapide, qui a une empreinte mémoire faible. Le but de backbone est de fournir le socle de votre application. A vous d’ajouter les modules dont vous avez besoin (JQuery sera incontournable). Le point fort de Backbone provient de ses mécanismes de gestion de données avec les collections et les modèles. Bien qu’il gère également les vues et le routing, cette partie restera très sommaire et on pourra privilégier des modules tels que MarionnetteJS pour compléter cette gestion.

En revanche l’aspect très modulaire de Backbone fait qu’il n’est pas très structurant. Il vous laisse faire vos propres choix de librairie et impose une très grande rigueur dans l’architecture de votre application afin qu’elle reste maintenable. L’ajout de nombreuses librairies peut aussi occasionner quelques difficultés pour les choisir, dans un premier temps, puis pour les maintenir ensuite.

 

Ember JS

Ember.js_Logo_and_Mascot

Ember contient à la fois un excellent routeur et une couche de gestion des données optionnelles. Il permet également de s’interfacer très rapidement avec un backend ruby-on-rails ou JSON Restful. Ember a été construit pour assurer des performances optimales. Des concepts tel que le “Run loop” s’assure qu’une mise à jour d’une donnée n’entraîne qu’une seule mise à jour du DOM, même si la donnée a évolué plusieurs fois.

Toutefois les APIs d’Ember évoluent de manière très rapide. De ce fait, il existe un grand nombre de contenus disponibles obsolètes, voir des exemples qui ne fonctionnent plus avec la dernière version d’Ember. De plus l’accès au framework demande un temps de montée en compétence relativement important. Pour finir Ember ajoute de nombreuses balises ‘script’ aux templates afin de garder le DOM à jour avec le model.

 

ReactJS

react-js

Bien qu’il ne soit pas un modèle MVC comme les frameworks précédemment décrits, il serait injuste de ne pas parler de ReactJS. Il s’agit d’une librairie destinée à créer des composant UI et disposant d’un mécanisme performant pour le rendu, le virtual DOM. Il est donc spécialisé dans la gestion des vues et peut s’interfacer très facilement avec d’autres outils tels que Backbone. Cette librairie connaît depuis quelques mois une évolution très importante, un peu à l’image de ce qu’a connu AngularJS il y a quelques années, comme le montre le graphique suivant :

google

 

Mon projet AngularJS ? Pas si vite

 

La première chose à faire quand on veut faire un site web est de s’interroger sur l’architecture de ce site. Ai-je besoin de faire une single page application ou est-ce que je peux me contenter d’un site web “classique” ? Il faut savoir qu’aujourd’hui une écrasante majorité du web est constituée de site web “classique” utilisant jquery et que les SPA restent très minoritaires, notamment en raison de leur contrainte en termes de SEO. Si vous choisissez de faire une SPA, alors viendra forcément le choix de la librairie à utiliser.

AngularJS est un des frameworks SPA les plus complets, si ce n’est LE plus complet. Il n’est pourtant pas incontournable. Comme nous avons pu le voir, d’autres frameworks tels que BackboneJS sont une alternative tout à fait crédible. La vraie question à se poser au démarrage d’un projet étant : De quoi ai-je besoin ?
Vous allez charger vos données au lancement d’une page et leur affichage sera statique ? Alors pourquoi mettre en place un double data-binding lourd en ressources.
Vous avez une très grande liste à afficher sur appareils mobiles ? AngularJS risquera d’avoir de moins bonnes performances.

Les exemples peuvent être nombreux et mettre en avant un framework plus qu’un autre. Avant de choisir une technologie il faut cerner son besoin et peser le pour et le contre de chaque framework. AngularJS est très complet, c’est indéniable, et il couvrira de très larges cas d’utilisation mais il n’est pas le seul. Il faudra, par exemple, surveiller de très près l’émergence du couple Backbone / ReactJS. L’un étant orienté donnée et l’autre vue, on obtient ainsi une stack qui peut répondre à de nombreuses problématiques.

 

Conclusion

 

Voilà 2 ans que l’on ne jure que par AngularJS mais aujourd’hui le soufflé commence à retomber. Peut-être dans l’attente d’AngularJS 2, sans doute avec l’émergence de ReactJS. Toujours est-il qu’on commence à se demander si l’on a pas été un peu trop prompt à tout investir sur AngularJS. J’ai pour ma part trouvé une illustration de cela lors de la conférence Best of Web, qui a eu lieu à Paris en juin 2015. Lors de cette conférence qui rassemblait 8 meetups, on a parlé de Backbone, d’API Rest, d’Ember, d’ES6 mais au final très peu d’AngularJS. Même si un des talks abordait le sujet, en réalité il s’agissait plutôt de voir comment utiliser ES6 avec AngularJS, qui était alors relégué au second plan.

En l’espace d’une année AngularJS est devenu incontournable, mais aujourd’hui plus que jamais on remet en question sa suprématie. Peut-être que dans un an ReactJS aura pris le dessus, peut-être qu’Angular 2 sera sorti et aura fait l’unanimité, ou peut-être qu’un autre acteur mettra tout le monde d’accord. Aujourd’hui, plus que jamais, un développeur web ne peut pas se permettre de ne connaître qu’une technologie comme AngularJS, il doit être ouvert à d’autres alternatives et toujours se remettre en question, mais n’est-ce pas ce qui fait la beauté de notre métier ?

  1. groov
    04/12/2015 à 23:22 | #1

    salut,

    comme tu le dis toi-même: Angularjs est très complet, Ember y ressemble, Backbone ne sert que pour le modèle (et s’il faut utiliser jquery… rien à voir avec Angularjs) et React que pour la vue… à quoi bon les comparer ? Je pense que la seule comparaison possible est Angularjs VS Ember (mais je ne connais pas ce dernier).

    Angular est très complet: double data-binding, requêtes http ajax, modularité, tests unitaires et end-to-end, interface avec une api,… backbone et react ne fournissent pas tout ça.

    On dirait que tu parles d’Angularjs seulement d’un point de vue pour un SPA (single page application, en fait), mais rien n’empêche de faire une appli mixe et de ne l’utiliser que pour une page ou un petit coin de page.

  2. Gauthier Boivin
    08/12/2015 à 14:11 | #2

    @groov
    Je les compare parce qu’ils ont le même objectif : facilité la création de SPA.
    Bien sur Backbone seul ne sert à rien, mais il est fait pour être modulaire. Tu l’utiliseras avec jQuery et toutes les libs dont tu as besoin et seulement celle dont tu as besoin.

    Angular embarque beaucoup de choses c’est vrai. Mais ajoute marionnette, jQuery a backbone et tu as le data-binding, les requêtes ajax…

    L’idée de l’article n’est pas de dire qu’un framework est meilleur que l’autre. Ils ont tous des avantages et des inconvénients. L’idée c’est de ne pas considérer Angular comme le choix de référence mais de réfléchir à son besoin avant de décider.

    En revanche utiliser Angular pour une appli mixte je ne vois vraiment pas l’interêt. Ce n’est absolument pas l’esprit du framework.

  3. Florian B
    08/12/2015 à 20:28 | #3

    @Gauthier: Bon article !

    Je suis assez d’accord sur le fait qu’il n y ai pas de solution idéale. Selon moi, pour simplifier à l’extrême, angular apporte un vrai cadre et convient ainsi bien aux débutant (notamment au niveau de la structuration de l’appli). Backbone, s’il est mal utilisé, peut vite faire partir le projet dans tous les sens et devenir lourd à maintenir … Les refontes backbone vers backbone + marionette + autres librairies sont monnaies courante …

    De plus, on peut aussi rajouter la problématique du full JS ou non ? Si on parle de Full JS on doit alors aussi aborder meteor.js …

    Ensuite, si on souhaite séparer les contextes BACK et FRONT on doit alors analyser la compatibilité entre technos back classiques comme php avec un framework front… Et là ça devient encore plus complexe… Comment gérer les moteurs de rendu comme twig sous SF2 ? Plutot techno back classique (php, python, ruby …) ou node ? Si on choisit node alors, encore une fois, pourquoi pas meteor ?

    Etc ….. Etc… Le sujet est particulièrement vaste !

  1. Pas encore de trackbacks


cinq × 7 =