Amélioration progressive par rapport aux applications à page unique
Je reviens tout juste d'une conférence à Boston intitulée An Event Apart .
Un thème très populaire parmi les intervenants était l'idée de amélioration progressive - le contenu d'un site devrait aller dans le HTML, et JavaScript ne devrait être utilisé que pour améliorer le comportement.
Les arguments avancés par les intervenants pour une amélioration progressive étaient très convaincants. Non seulement c'est un modèle solide pour prendre en charge les anciens navigateurs et les appareils sur un réseau à faible bande passante, mais HTML échoue beaucoup plus gracieusement que JavaScript (c'est-à-dire que le balisage qui n'est pas pris en charge est simplement ignoré, tandis que si un navigateur lève une exception lors de l'exécution de votre script - vous êtes arrosé).
Jeremy Keith a fait un exposé particulièrement perspicace à ce sujet.
Mais qu'en est-il des applications Web à page unique comme Backbone et Angular? L'ensemble de la conception derrière ces cadres semble pousser le développeur à déplacer le contenu hors du HTML et vers quelque chose comme une API JSON.
Je n'arrive pas à geler ces deux modèles de conception: amélioration progressive par rapport aux applications Web à page unique. Y a-t-il des cas où l'un est meilleur que l'autre? Ou ne sont-ils même pas des technologies antagonistes, et il me manque quelque chose ici avec mon modèle mental?
Il me semble que les applications d'une seule page tracent une ligne dans le sable de l'amélioration progressive. Alors qu'avant, nous pourrions essayer de contourner le fait que les implémentations et les fonctionnalités varient entre les navigateurs depuis des décennies, les SPA supposent qu'il existe une certaine base de référence que nous pouvons raisonnablement accepter que la plupart des visiteurs d'un site donné se rencontreront. Je ne pense pas que les deux soient en désaccord. Vous pouvez toujours continuer à vous améliorer progressivement après le démarrage du SPA, comme commencer par un <video> tag, puis superposez votre propre lecteur riche en fonctionnalités en plus de cela.
Ensuite, il y a des visiteurs dont le script est désactivé, mais ils savent dans quoi ils s'engagent. Je ne vois pas pourquoi les développeurs devraient se plier en quatre pour ces visiteurs, à part une note "Vous avez besoin de scripts pour ce site". Si nous permettons cela, pourquoi ne pas également répondre aux visiteurs avec CSS désactivé? Et les images désactivées? Ce sont des technologies Web de base. Ils ne devraient pas s'attendre à avoir une expérience Web entièrement fonctionnelle lorsqu'ils vont cueillir et choisir des pièces.
Pour m'assurer de ne pas m'en tirer sans analogie avec la voiture, je ne devrais pas m'attendre à ce que ma voiture fonctionne si je décide que je n'aime pas certaines fonctionnalités. Je pourrais dire aux ingénieurs civils: "J'ai désactivé mes phares, alors assurez-vous d'installer des lampadaires tous les 125 pieds partout où je pourrais visiter." Sans phares, ma voiture fonctionnerait la plupart du temps, mais je ne pourrais pas visiter certains endroits.
SPA est plus avantageux si vous créez une application qui ne correspond pas au modèle classique de pages de demande/réponse. Il y a une tendance récente où les sites Web réguliers sont écrits en tant que SPA même lorsqu'ils s'intègrent très bien dans le cycle de demande/réponse du Web, à mon humble avis ce qu'ils font sont des efforts stupides. Ce que font ces sites Web, c'est de réimplémenter mal un navigateur Web avec beaucoup plus de bogues et moins de fonctionnalités.
L'idée d'amélioration progressive et de SPA ne s'exclut pas mutuellement pour ces sites Web d'applis d'une seule page. Vous avez simplement besoin du javascript pour faire des négociations de contenu (c'est-à-dire accepter l'en-tête) afin qu'ils reçoivent des ressources JSON que le Javascript sur le SPA peut rendre eux-mêmes au lieu de pages HTML pré-rendues. Les problèmes avec ce type de SPA de site Web sont évidents, vous devez avoir une implémentation en double du rendu du site Web sur le serveur et sur le client.
Pour les vraies applications Web, c'est-à-dire celles qui doivent vraiment être un SPA car elles ne correspondent pas au modèle de demande/réponse standard; L'amélioration progressive est beaucoup plus difficile pour les vraies applications car elles n'utilisent vraiment qu'un navigateur comme plate-forme technologique pour écrire une application de manière portable. Le langage de script est une partie essentielle d'une véritable application Web, pas seulement une qui peut être boulonnée en option pour des améliorations. Certaines techniques d'améliorations progressives peuvent toujours fonctionner (par exemple, remplacer la vidéo/l'audio flash par <video>/<audio> tag) mais les vraies applications Web nécessiteront javascript comme ligne de base.
Je crois que les applications Web à page unique et l'amélioration progressive sont presque des antagonistes. Si le html est calculé sur le client à partir de données récupérées à partir d'une API json, il peut difficilement se dégrader correctement. Il peut cependant offrir une interface utilisateur plus riche et plus agréable.
Vous pouvez configurer un bot qui analysera votre application et enregistrera une version statique. Cette technique peut être utilisée pour servir du HTML aux navigateurs sans javascript (utilisé par les aveugles ou les robots des moteurs de recherche). Il s'agit d'un investissement, donc cela dépend vraiment de vos besoins.
Vous créez une application web de gestion des RH pour une entreprise spécifique? Vous n'avez pas besoin d'une dégradation gracieuse, et un SPA peut être plus simple à construire. La société peut imposer l'utilisation d'un navigateur spécifique, vous aurez donc peut-être moins de tests à faire.
Créez-vous un site Web public pour une association avec les exigences d'accessibilité et les besoins de visibilité des moteurs de recherche? Envisagez ensuite de créer le code HTML sur votre serveur. Ou faire un SPA avec une version statique, selon votre budget.
Je pense que cela dépend jusqu'où vous voulez aller avec l'amélioration progressive - c'est un paradigme de conception plutôt qu'un ensemble de règles strictes et rapides.
Si vous utilisez un framework SPA, je pense que permettre Javascript est une donnée. Cependant, le Javascript que vous écrivez pour améliorer votre page doit être suffisamment intelligent pour gérer le HTML que le framework peut créer.
Vous pouvez également bénéficier d'autres techniques PE, telles que tirer parti des dernières fonctionnalités CSS pour une version récente du navigateur ou de la dégradation HTML5 en HTML4.
L'amélioration progressive et une application à page unique peuvent coexister. Les deux arguments les plus convaincants que j'ai entendus pour créer des applications de cette manière sont:
- Tolérance aux pannes dans les situations où le téléchargement des fichiers HTML complets mais référencés ne parvient pas à se télécharger complètement grâce à la connectivité réseau qui entre et sort (possible sur les réseaux mobiles)
- Potentiel de amélioration des performances perçues lors du chargement initial de la page (en réduisant les temps de démarrage du rendu)
Le rendu côté serveur (c'est pour les utilisateurs, pas seulement pour des raisons de référencement) et la réduction de la moutarde sont deux techniques qui peuvent aider à créer des applications de page unique progressivement améliorées avec des cadres JS modernes côté client.
Certains frameworks JS côté client sont plus faciles à utiliser avec le rendu côté serveur que d'autres ( méfiez-vous de certaines solutions de rendu côté serveur et des combinaisons de framework ne produisent pas de SPA de travail car la page rendue par le serveur est uniquement destiné à la consommation des moteurs de recherche, pas aux utilisateurs finaux ).
Au moment de l'écriture, React.js et Ember (avec le prochain FastBoot) sont les deux que je connais qui ont ou tentent de faire du rendu côté serveur un citoyen de première classe; le La page rendue côté serveur est toujours un SPA fonctionnel lorsqu'elle est analysée sur le navigateur client.
Je suis d'avis que la charge de page réduite est probablement très bonne pour les serveurs et le réseau. J'aimerais voir plus de SPA utilisés correctement.
Je ne pense pas que cela nécessite deux choses:
1) en configurant tous vos liens en tant que liens de demande/réponse standard lors du chargement initial, laissez votre infrastructure/bibliothèque SPA puis remplacez-les par une version mise à jour (interactive) une fois que le navigateur se charge et que le moteur JS identifie que le support SPA est disponible. C'est vraiment une amélioration progressive; le JS est chargé au-dessus du site Web html existant, et c'est mieux pour les moteurs de recherche, les technologies d'assistance et les navigateurs plus anciens.
et
2) Le serveur doit être réactif aux routes comme/foo/bar/json et foo/bar en servant le format correct; de façon réaliste, si vous enveloppez tout dans des mises en page et des partiels pour obtenir la première page, vous devriez également pouvoir tout obtenir via des mises en page et des partiels pour la 2ème page et les pages suivantes.
Il y a pas mal de travail ici; Certes, mais si vous avez le contrôle sur la pile complète, cela équilibre les deux technologies.