Dans quel cas doit-on choisir une SPA ?

Dascritch me pingue sur le tweet suivant :

Et en effet, en lisant l'article, il y a de quoi rire. Il s'agit de cinq points sur lesquels l'équipe de SourceGraph a regretté le choix d'une Single Page Application au lieu d'un site classique généré coté client.

Je vais insister lourdement sur le premier point remonté par SourceGraph : la difficulté à référencer un site en SPA par les moteurs de recherche.

Une SinglePageWebapp est une Application. En tant que tel, il est logiquement aberrant de choisir cette architecture pour construire un site de publication. On peut le faire, bien entendu, mais avant de se plaindre de la difficulté à être indexé et de chercher des bidouilles lourdes et couteuses comme certains le font, il serait bien de se demander si le choix est judicieux. Ce n'est pas lié à Javascript mais au concept d'application. On retrouve exactement la même problématique du coté des applications natives sur mobile : écrire une app native pour reproduire le site "Le Monde" est contre productif, un design responsif est une bien meilleure option.

Prenons une plateforme de blog. D'un coté, un backoffice, donc un outil, une application, qui permet de modifier le contenu de son blog. De l'autre, le blog, qui affiche des pages web contenant vos articles de blogs dans le but d'être lus par le plus grand nombre. Nous avons bien deux produits clairement différents. On pourrait prendre pour analogie : la presse d'imprimerie d'un coté, et le journal papier de l'autre. L'un est un outil, l'autre est un média.

L'outil devra afficher des pages constamment renouvellées. Pas de mise en cache, des requêtes en temps réel en base de données. Ce qui a généralement pour incidence de ralentir la génération des pages par le serveur et de couter plus cher. C'est pourquoi une architecture en SPA est judicieuse. On décharge le serveur de tâches que le client peut gérer sans problème sans être lésé par ses inconvénients.

Le site de publication devra quant à lui afficher du contenu le plus rapidement possible. En contrepartie, on sera plus clément si le contenu est légèrement en retarde par rapport à l'état réel de la base de données. Ça veut dire qu'on peutqu'on doit mettre ces pages en cache. On n'est même pas encore à la problématique de SEO qui est en réalité une problématique d'accessibilité, mais simplement de mise en cache du contenu. Avec une SPA, c'est chaque client qui va faire ses propres requêtes vers la base de données (au sens large, SGBD ou API) et générer la même page. La page étant identique, il vaut mieux laisser le serveur mutualiser cet effort en le laissant générer une seule et unique fois la page puis renvoyer le résultat à tous les clients.

La Single Page WebApp, c'est pour les backoffice !

On pourrait parler des autres arguments rapidement aussi :

  • les stats ? Google Analytics fonctionne parfaitement et sait gérer les changement d'url avec pushState avec une seule ligne de code. Il est aussi capable de tracker des évenements.
  • Lent ? Installez des SSD sur vos machines ? Non, je dois avouer que grunt est assez lent… quand on lui demande de faire tout un tas de trucs à chaque sauvegarde de fichier ! Je ne crois pas qu'il soit nécessaire de vérifier la validité du fichier avec jshint, compresser les css et les js, etc à chaque sauvegarde du fichier ! Toutes ces tâches lourdes, il faut les faire à part ! JSHint, juste après avoir lancé les TUs, et la compression, seulement lors du build.
  • Tests lents. Et bien prenons les test d'Overblog. Coté client, les tests sont effectués dans un navigateur ou via casperjs. Ils prennent entre 5 et 10 minutes selon les machines. C'est beaucoup en effet. Maintenant, prenons les TUs du core, donc la partie PHP avec Symfony. Ils prennent 30 minutes. Et oui, des tests, c'est long quand il y en a beaucoup.
  • La lenteur éventuelle de l'interface. "You can argue that a good development team should avoid these mistakes". Ben ouais.

Si vous voulez en savoir plus, vous pouvez écouter ma conférence à ToulouseJS en février 2013 qui parle d'une expérience de SPA réussie : le backoffice d'Overblog.


Toulouse JS #3 - Hadrien Lanneau par hadrienl

Hadrien

Hi, I'm a french Javascript Lead Developer, Web Architect from Toulouse, France. I've worked for 12 years for many projects with YUI, AngularJS, Aurelia.io and now React and React native.

Toulouse, France https://hadrien.eu