Choix d’un framework JS pour site mobile en single-page

Le site Web que je gère au quotidien repose sur Drupal. Pour faire une version mobile, la 1ère idée qui vient est simplement de faire un thème mobile et de continuer de se servir de Drupal pour desservir les pages. Mais je suis joueur, et j’avais envie depuis longtemps d’aller taquiner le JS de façon plus poussée, en faisant autre chose que du jQuery (Article très intéressant sur le sujet), étant une technologie de plus en plus utilisée, tant pour le mobile que pour des applications Web.

L’idée est donc naturellement venue de créer un site mobile « à part », appelant des Web-services Drupal qui retourneront le contenu (et seulement le contenu utilisé = perf). J’espère ainsi apprendre de nouvelle technologies, créer une application structurée, innovante, performante…

Voici donc plusieurs mois que j’étudie les frameworks JS avant de faire un choix pour la création de ce site Web mobile.
J’ai donc pu essayer EmberJSjQuery MobileBackbone.js et AngularJS.
L’objectif ici n’est pas de comparer les frameworks points par points, notamment sur le paradigme MVC et d’ajouter un énième article sur le sujet, mais de faire un retour d’expérience concret sur le choix qui a été fait.

Venant du monde PHP, technologie « serveur », le JS oblige à repenser un peu sa façon de concevoir un site. Quel que soit le framework, on retrouve principalement le principe du « single page application« . La partie MVC est donc pour partie déportée côté client.
C’est donc le JS qui s’occupe du routing en fonction de l’URL, d’appeler les traitements métiers qui vont bien, qui calcule la vue (template) et la restitue. Il y a souvent des appels Ajax à des Web Services lors du traitement (récupération de contenu, sauvegarde, authentification, etc.)

Cette techno permet également l’utilisation de services comme phoneGap qui permet d’encapsuler un site HTML/CSS/JS en single-app, dans une application mobile disponible ensuite pour Android, iPhone, Windows Phone, etc. C’est pas non plus magique, il y a quelques éléments à prendre en compte (car l’appli créée est ensuite exécutée côté mobile, appelant le point d’entrée en local : files://index.html, apportant son lot de difficultés).
Je vous ai recensé les ressources que j’ai pu trouver sur le sujet dans un nouvel article sur PhoneGap.

Frameworks testés et choix

On trouve beaucoup de ressources sur chacun. AngularJS et EmberJS disposent même de tutoriaux progressifs, pratiques pour évaluer ces frameworks sans y passer trop de temps, mais trop léger pour répondre à tous les questions, bien souvent.
En plus de ces tutoriaux, vous avez la célèbre application « TODO List » développée avec un grand nombre de frameworks JS, permettant de voir les différences de chacun. Mais selon votre besoin, idem, ce sera limité, car les fonctionnalités explorées restent « de base », ce qui est normal pour une application de démo…

EmberJS : bien que la doc soit bien faite, il souffre, je trouve, de trop de conventions de nommages, et m’a semblé de prime abord complexe, mais maintenant que je commence à maîtriser, peut-être qu’en essayant de nouveau, je verrai ça d’un nouvel oeil. Mais je souhaitais une techno dans laquelle on entre sans trop de difficulté (notamment pour mon équipe de développeurs qui devra se faire la main), et avec laquelle il est facile de retrouver ces petits. Je n’ai pas eu ce sentiment avec EmberJS.

jQuery mobile : il est bien fait, intègre son système de routing, mais pas de MVC => pas cool ! Du coup, soit on le couple à un framework MVC, mais dans ce cas, bonjour l’usine à gaz (choix de qui doit s’occuper du routing, etc.), soit on oublie le framework, et on fonctionne « à la jquery » classique, sans grande structure de code/projet. Depuis, ils ont créé le projet M En gros, ça aurait pu être un bon choix si j’avais conservé la logique métier côté Drupal, car JQM est bien pour la restitution, widgets adaptatifs, etc. Un peu bridé en terme de design (complexe à customiser).

Backbone.js a été mon choix pendant quelques semaines, j’ai commencé un site avec (recherche, liste, détail), mais j’ai vite trouvé que le code se complexifiait très vite pour un besoin simple, du fait de devoir créer à chaque fois des modèles, des collections, l’attachement des événements est lourd, etc.
Ca m’a servi de découvrir ce framework d’autant que Drupal 8 et WordPress tendent à l’utiliser dans leurs versions futures. De là à créer un projet complet reposant dessus, je trouve trop lourd les développements/maintenance associés. Et enfin, il ne comporte pas d’emblée d’outil de tests unitaires/fonctionnels, bien qu’une multitude de plugins existent.
[EDIT] Depuis, j’ai revu ma position ! [/EDIT]

AngularJS est mon choix final, bien que j’y soit venu puis reparti (vers backbone) puis revenu, et là, c’est devenu beaucoup plus limpide et clair. Il faut un certain temps pour rentrer dedans, je me retrouve complètement dans ce graphique : http://www.bennadel.com/blog/2439-My-Experience-With-AngularJS-The-Super-heroic-JavaScript-MVW-Framework.htm Je ne détaille pas la raison du choix, car il vaut nettement mieux essayer et mettre les mains dans le cambouis pour évaluer ces frameworks, d’autant que des tonnes d’articles les expliquent déjà.

 

Technologies gravitant autour du JS

En plus de votre framework, on dispose d’un grand nombre d’outils géniaux pour automatiser des tâches, compresser, tester, pour installer des librairies, etc.

  • Grunt : tâches en ligne de commande (« à la » drush de Drupal, Ant de Java ou phing de PHP) permettant de compiler les fichiers LESS, passer un coup de jsHint pour vérifier la syntaxe JS, lancer les tests, créer une version de dev ou de prod compilée/compressée/concaténée…
  • Bower : outil permettant d’installer des librairies/dépendances, avec gestion des versions, exactement comme Composer en PHP. Les librairies sont hébergées sur github.com, et doivent disposer d’un package.json ou bower.json contenant les informations de version, le nom de la librairie, etc.
  • Npm : un peu comme bower, mais ce sont des packages pour NodeJS. Lorsqu’on développe en NodeJS, on l’utilise pour télécharger les dépendances, et gérer les versions de chacune, exactement comme Composer.
  • NodeJS : souvent les applications Web ont un backend en NodeJS, j’ai donc également étudié ce formidable serveur, hyper performant. Dans le cas de mon application, il ne sert que pour tous les modules nécessaires à grunt (jshint, concat, uglify, karma, ngmin, html2js, recess, …)

Association d’une librairie graphique (UI)

Le framework JS apporte tout le nécessaire pour structurer les développements, les tests, etc. Il manque cependant une brique essentielle : la gestion de l’interface graphique.

Ici, le choix dépend beaucoup du type de site/application que l’on souhaite.

  • Soit on crée tout de A à Z, ce qui peut s’avérer très coûteux en temps, pour bien gérer les soucis de navigateurs (décuplés par le nombre de terminaux), mais peut aussi permettre d’arriver exactement à ce que l’on souhaite, de façon légère et optimisée. Ça dépend aussi des compétences en interne à votre équipe.
  • Soit on s’appuye sur un framework CSS, voire UI :
    • jQuery mobile est bien mais pour le coupler avec AngularJS, c’est carrément lourd ! ( Adaptateur )
    • Bootstrap est une bonne solution : il permet de disposer d’une grille adaptative, de composants tout fais, de widgets, etc. Permet d’aller plus loin que le mobile, ce qui est une bonne chose (tablette, etc.) car responsive. Se customize assez facilement. Reste complètement indépendant du framework JS choisi (très bon point)
    • FlatUI ou autre : surcouche à Bootstrap 2, intéressant, surtout que suivant la mouvance actuellement du « flat design ». Mais s’appuie pour le moment sur bootstrap 2, qui vient de passer en 3 récemment.
    • Junior
    • Autres frameworks payant (kendo, etc.)

Pour inspiration, des sites proposent des exemples d’interfaces mobile, une mine pour trouver des idées : http://www.mobile-patterns.com/detail-views

Conclusion

Toutes ces technologies JavaScript sont de plus en plus matures, bien qu’évoluant encore très vite. D’autre frameworks voient régulièrement le jour (je pense à Meteor par exemple). Le choix dépend beaucoup de vos besoins (site web ? application ? mobile ? backend disposant de Webservices ?).

Quel que soit votre choix, vous aurez quasiment toujours besoin de plugins ou librairies externes à votre framework pour ajouter les fonctionnalités manquantes. Celles-ci dépendent du framework, mais il manque toujours quelque-chose, qu’on trouve généralement très facilement, et bien souvent hébergé sur un github.com, donc gérable via bower.

  • Etienne

    test disqus

  • Pingback: Ressources pour débuter avec AngularJS | La petite pause technique()

  • joeisfat

    Super article merci 🙂

  • Etienne

    avec plaisir 🙂

  • loulzzz

    Merci pour ton article et ton retour d’expérience précieuse, après plusieurs projets phonegap avec jquery je vais tester phonegap et Angular, visiblement aussi très apprécié du
    coté de San Francisco