Amélioration progressive vs applications sur une seule page


33

Je viens de rentrer d'une conférence à Boston intitulée An Event Apart .

L'idée de l'amélioration progressive était un thème très populaire parmi les intervenants: le contenu d'un site devrait être enregistré en 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. Il s’agit non seulement d’un modèle solide permettant de prendre en charge les anciens navigateurs et les périphériques d’un réseau à faible bande passante, mais le code HTML échoue beaucoup plus gracieusement que le JavaScript (c’est-à-dire que les balises qui ne sont pas prises en charge sont simplement ignorées. script - vous êtes arrosé).

Jeremy Keith a donné une conférence particulièrement perspicace à ce sujet.

Mais qu'en est-il des applications Web à page unique telles que Backbone et Angular? La conception de ces frameworks semble pousser le développeur à déplacer le contenu du code HTML vers une API JSON.

Je n'arrive pas à geler ces deux modèles: 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 s'agit-il même pas de technologies antagonistes, et il me manque quelque chose ici avec mon modèle mental?


Ils ont deux cas d'utilisation différents. Oui, il y a un chevauchement lorsque le serveur effectue le gros du travail.
BobDalgleish

5
Je pense qu’il est juste de dire que les exigences du navigateur pour les applications à page unique sont plus strictes que celles des applications Web "ordinaires", de par leur conception.
Robert Harvey

3
vous devriez demander à Jeremy Keith de vous donner un exemple concret où l'amélioration progressive vaut vraiment la peine de plaire à un total de 1 à 10% d'internautes et demandez aux données des autres 90% d'utilisateurs de savoir s'ils se soucient réellement de l'amélioration progressive ou s'ils sont satisfaits. s'ils peuvent visiter le site web avec IE 5.0 ou sans javascript
kirie

1
Si le type de personnes qui désactive JS / images / etc ne fait pas partie de votre population cible, il n’existe aucune raison valable de poursuivre Progressive Enhancement.
Graham

1
La prise en charge de «périphériques sur un réseau à faible bande passante» est en réalité un argument pour SPA, pas contre! Dans SPA, vous ne faites qu'une seule demande importante, où sans JS vous l'avez à chaque fois!
Dmitri Zaitsev

Réponses:


21

Il me semble que les applications d'une seule page tracent une ligne dans le sable de l'amélioration progressive. Alors que nous essayions peut-être de contourner le fait que les implémentations et les fonctionnalités varient d'un navigateur à l'autre depuis des décennies, les SPA supposent qu'il existe une certaine base de référence que nous pouvons raisonnablement convenir que la plupart des visiteurs d'un site donné se rencontreront. Je ne pense pas que les deux sont en désaccord. Vous pouvez toujours continuer à améliorer progressivement après le démarrage du SPA, par exemple en commençant par un <video>tag, puis en superposant votre propre lecteur riche en fonctionnalités.

Ensuite, il y a des visiteurs dont les scripts sont désactivés, mais ils savent dans quoi ils s'embarquent. Je ne vois pas pourquoi les développeurs devraient se mettre en quatre pour ces visiteurs, mis à part la 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é? Qu'en est-il des images désactivées? Ce sont des technologies Web de base. Ils ne doivent pas s’attendre à une expérience Web pleinement fonctionnelle lorsqu’ils choisissent des pièces.

Pour m'assurer de ne pas m'égarer sans analogie avec une 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 éteint mes phares, alors assurez-vous d'installer des réverbères tous les 125 pieds partout où je pourrais me rendre." Sans phare, ma voiture fonctionnerait souvent, mais je ne pourrai pas visiter certains endroits.


3
I don't see why developers should bend over backwards for those visitors. Si votre contrat spécifie que vous devez fournir une version accessible de votre site Web, l'utilisation d'un SPA peut s'avérer plus difficile. Et qu'en est-il du référencement?
Simon Bergot

7
@Simon: Vous pouvez également rendre un spa accessible (voir, par exemple, stackoverflow.com/questions/15318661/… ). De même pour le référencement (si le référencement est important, cela dépendra de l'application).
Sleske

2
Certaines de vos analogies sont un peu un homme de paille. La désactivation de Javascript a un objectif de sécurité; il serait difficile d'affirmer que l'ajout de phares à un soin le rend moins sûr.
Robert Harvey

1
Certes, la désactivation des scripts présente des avantages en matière de sécurité. Mais pour la plupart des visiteurs, la sécurité supplémentaire offerte par ce choix n’en vaut pas la peine. Sans script, Facebook refuse de travailler, des pauses LinkedIn, Pinterest, Instagram charge une page vierge, etc. Si les principaux acteurs le demandent, votre SPA le peut également.
Collin Allen le

Connaissant seulement FB et LinkedIn, il n’ya aucune raison valable pour que ces sites se séparent de JS, si ce n’est pour apaiser les développeurs qui ne veulent pas s’efforcer de créer un site Web qui fonctionne de manière acceptable (ou pour contraindre les utilisateurs à accepter des pratiques de navigation moins sécurisées qui peuvent bénéficier leurs résultats nets). Si elles étaient des applications Web complètes telles que Plunker, vous auriez peut-être un sens, mais la plupart des "applications Web" ne sont que des "applications" dans le sens où elles sont construites sur une sorte de cadre. En termes d'utilisation, ce ne sont que des sites Web avec plus de cloches et de sifflets qu'auparavant.
Dissident Rage

6

SPA est particulièrement utile si vous créez une application qui ne correspond pas au modèle classique des pages de demande / réponse. Il existe une tendance récente selon laquelle les sites Web normaux sont écrits en tant que SPA même s'ils s'intègrent parfaitement dans le cycle de demandes / réponses du Web. À mon humble avis, ce qu'ils font est une entreprise insensée. Ce que font ces sites Web, c’est de mal réimplémenter un navigateur Web avec beaucoup plus de bugs et moins de fonctionnalités.

L’idée d’amélioration progressive et de SPA n’est pas mutuellement exclusive pour ces stupides sites Web appli. Vous avez simplement besoin du javascript pour négocier le contenu (c.-à-d. L'en-tête Accept) afin qu'ils reçoivent une ressource JSON que le Javascript sur le SPA peut afficher eux-mêmes au lieu d'une page HTML pré-affichée. Les problèmes avec ce type de SPA de site Web sont évidents, vous devez avoir une implémentation dupliquée du rendu du site Web à la fois sur le serveur et sur le client.

Pour les applications Web véritables, c’est-à-dire celles qui doivent être véritablement 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 utilisent simplement un navigateur comme plateforme technologique pour écrire une application de manière portable. Le langage de script est un élément essentiel d’une véritable application Web, et pas seulement un outil qui peut éventuellement être amélioré. Certaines techniques d’amélioration progressive peuvent toutefois encore fonctionner (par exemple, remplacer la vidéo / l’audio flash par <video>/ <audio>tag), mais les applications Web véritables nécessitent le javascript comme base.


+1, mais il n'est pas toujours facile de décider si quelque chose nécessite vraiment un SPA. Par exemple, les applications métier qui consistent principalement en saisie de données, avec une grande complexité dans les formulaires. Si la plupart des formulaires sont simples, un SPA n'est pas "véritablement" requis, il reste donc une tension entre les solutions SPA et non-SPA.
Sinelaw

@sinelaw: La plupart des applications métier ne doivent généralement pas être un SPA. Il y a quelques exceptions, par exemple Tableur, Traitement de texte, mais ce sont les rares. Indicateurs indiquant que vous avez besoin de SPA: si vous devez transmettre des données du serveur au client, pas seulement pour une ou deux notifications, mais comme élément crucial de l'application, par exemple, jeu, suivi des stocks, application de discussion en ligne; si votre application n'a pas de concept sensible de "page" ou si le concept de "page" a été totalement déformé dans l'application, par exemple les applications Office. Les applications métier qui fonctionnent principalement sur des formulaires ont intérêt à rester non-SPA.
Lie Ryan

Se mettre d'accord. Un autre indicateur pour un SPA: si développer un SPA coûte moins cher que de développer un site Web "classique". Les applications professionnelles ciblant un public spécifique peuvent parfois imposer des exigences telles que "utiliser un navigateur moderne", de sorte qu'une amélioration progressive présente peu d'avantages.
Sinelaw

@sinelaw: Construire un SPA n’est presque jamais moins cher que développer un site de plusieurs pages; surtout si vous ne restaurez pas les anciens navigateurs de toute façon.
Lie Ryan

Si votre équipe est composée d’experts du SPA n’ayant que peu d’expérience dans les projets centrés sur le serveur, le coût sera moindre
Sinelaw

2

Je crois que les applications Web à page unique et l'amélioration progressive sont presque antagonistes. Si le code 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 avec élégance. Il peut toutefois 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 HTML aux navigateurs sans JavaScript (utilisé par les aveugles ou les robots des moteurs de recherche). Il s’agit d’un investissement, il s’agit donc vraiment de répondre à vos besoins.

Faites-vous une application web de gestion des ressources humaines 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, de sorte que vous aurez peut-être moins de tests à faire.

Faites-vous un site Web public pour une association avec des exigences d’accessibilité et des besoins de visibilité des moteurs de recherche? Ensuite, envisagez de créer le code HTML sur votre serveur. Ou créer un SPA avec une version statique, en fonction de votre budget.


1

Je pense que cela dépend du niveau d'avancement avec l'amélioration progressive: il s'agit d'un paradigme de conception plutôt que d'un ensemble de règles strictes et rapides.

Si vous utilisez un framework SPA, je pense que permettre Javascript est une donnée. Toutefois, le code Javascript que vous écrivez pour améliorer votre page doit être suffisamment intelligent pour traiter le code HTML que le cadre peut créer.

Vous pouvez également bénéficier d'autres techniques PE, telles que l'exploitation des dernières fonctionnalités CSS pour une version récente du navigateur ou la dégradation de HTML5 en HTML4.


1
Une partie de l'amélioration progressive est que le contenu de base devrait être disponible sans JavaScript. Je ne sais pas comment écrire un spa sans JavaScript.
Alan Shutko

@AlanShutko Peut-être avec des iframes. Plusieurs pages, mais techniquement, l'URL ne change pas ...;)
Izkata

1
Oui, je pensais plutôt à HTML 5 qu'à HTML 4 et à des éléments tels que les CSS spécifiques à un navigateur (par exemple, vous voudrez peut-être utiliser une fonctionnalité très récemment implémentée, disponible uniquement dans la dernière version de Chrome, mais dégradant davantage. contrôle primitif dans les anciens navigateurs). Se passer de javascript serait délicat dans un SPA, mais ce n'est qu'un aspect du concept d'amélioration progressive.
philicomus

L'amélioration progressive peut être aussi simple que d'utiliser CSS3 lorsqu'il est disponible pour arrondir les angles. L'idée de base n'a rien à voir avec JavaScript.
Daniel Little

1

Une 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 les suivants:

  • Tolérance aux pannes dans les cas où le téléchargement de fichiers HTML dans son intégralité, mais les scripts référencés échouent, grâce à la connectivité réseau entrante et sortante (possible sur les réseaux mobiles)
  • Potentiel d' amélioration des performances perçues lors du chargement initial de la page (en réduisant les temps de rendu de début)

Le rendu côté serveur (c'est pour les utilisateurs, pas seulement pour des raisons de référencement) et le «cut-the-mustard» sont deux techniques qui peuvent aider à créer des applications à une seule page progressivement améliorées avec des infrastructures JS côté client modernes.

Certains frameworks JS côté client sont plus faciles à utiliser que d'autres avec le rendu côté serveur ( attention, certaines solutions de rendu côté serveur et les combinaisons de frameworks ne produisent pas de SPA fonctionnels car la page rendue par le serveur est uniquement destinée à la consommation des moteurs de recherche. -utilisateurs ).

Au moment de la rédaction de ce document, React.js et Ember (avec la prochaine version de FastBoot) sont les deux dont je suis au courant qui ont ou tentent de faire du rendu côté serveur un citoyen de première classe. la page rendue côté serveur est toujours un SPA fonctionnel lorsqu'elle est analysée sur le navigateur du client.


0

Je suis d'avis que le chargement de page réduit est probablement un très bon pour les serveurs et le réseau. J'aimerais voir plus de SPA utilisés correctement.

Je suis hors de vue cependant que cela nécessite deux choses:

1) En configurant tous vos liens en tant que liens de requête / réponse standard lors du chargement initial, laissez votre infrastructure / bibliothèque SPA, puis remplacez-les par une version mise à jour (interactive) une fois le navigateur chargé et le moteur JS indiquant que le support SPA est disponible. C'est vraiment une amélioration progressive; JS est chargé par-dessus le site Web HTML existant, ce qui est préférable pour les moteurs de recherche, les technologies d'assistance et les navigateurs plus anciens.

et

2) Le serveur doit répondre aux itinéraires tels que / foo / bar / json et foo / bar en servant le format correct. de manière réaliste, si vous intégrez tout dans des mises en page et des partiels pour obtenir la première page, vous devriez pouvoir tout obtenir par l'intermédiaire de mises en page et de partiels pour la 2e page et les pages suivantes.

Il y a pas mal de travail ici; certes, mais si vous avez le contrôle de toute la pile, les deux technologies sont équilibrées.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.