Catégories
Astuces et Design

Spectre de rendu | Astuces CSS

Voici les grandes catégories de sites Web de rendu:

  • Client: expédier un

    et laissez un modèle JavaScript rendre tout cela.

  • Statique: pré-rendu tout le HTML.
  • Serveur: laissez un serveur en direct traiter les requêtes et générer la réponse HTML.

Ils ne s'excluent pas mutuellement.

  • Un site Web pourrait statiquement pré-afficher 75% de ses pages (par exemple, des articles de blog), mais les 25% restants ont un serveur qui répond (par exemple, des forums).
  • Un site Web peut pré-rendre statiquement toutes les pages, mais en avoir quelques
    s là-dedans qui contiennent du contenu rendu côté client (par exemple, un menu généré dynamiquement basé sur l'utilisateur connecté).
  • Un site Web peut être principalement rendu par le serveur, mais a une mise en cache devant lui de sorte qu'il se comporte de manière statique.
  • Un site Web pourrait afficher un rendu statique, mais ensuite «s'hydrater» lui-même en un site entièrement rendu par le client.
  • Un site Web peut être un mélange de rendu serveur et statique, mais il a des parties dynamiques similaires au rendu côté client, mais se produit en fait dans une fonction de périphérie, il finit donc plus comme un rendu côté serveur.

Next.js est intéressant en ce qu'il peut faire les trois. Voici Tim Neutkens dans une récente interview:

Next.js vous permet de pré-rendre les pages. Il crée du HTML sur un serveur au moment de la construction avec la génération de site statique ou utilise le rendu au moment de l'exécution côté serveur. Next vous permet de faire un hybride de ceux-ci. Contrairement à la plupart des autres frameworks, vous n'êtes pas lié par, oh, je vais créer mon application complètement générée statiquement. Au lieu de cela, vous êtes autorisé à afficher certaines pages côté serveur et certaines pages générées de manière statique.

Dans la nouvelle version, nous rendons possible la mise à jour de ces pages générées statiquement sans avoir à exécuter une nouvelle version, en reconstruisant toute votre application.

Cool. J'adore voir cela se produire au niveau du cadre. On dirait que devoir se concentrer sur un seul style de rendu n'est pas pratique pour de nombreux sites.

Le rendu client est le plus flexible, mais il s'accompagne de tous ces inconvénients graves tels que des performances médiocres, une fiabilité moindre, une pression accrue sur les appareils, un mauvais référencement, etc. Le pré-rendu statique est le plus robuste, rapide et sécurisé, mais il est le plus limité. . Les fonctions Edge en plus de la statique commencent à ouvrir des portes, mais le rendu serveur est le mélange classique de flexibilité et de vitesse qui a dominé le Web pour une bonne raison.

Le rendu client ouvre également la porte à cette sensation de «SPA» (application à page unique). J'aime toujours ça, personnellement. J'aime la sensation de non-rafraîchissement de la page. Cela rend un site accrocheur et ouvre la porte aux transitions de page. Gatsby est célèbre pour avoir popularisé l'hydratation, où vous obtenez le bonus statique pré-rendu, mais ensuite la mise à niveau vers SPA au fur et à mesure du téléchargement de JavaScript.

J'adorerais voir le Web arriver au point où nous obtenons tout ce bonus de «bonne sensation» d'un SPA sans avoir à créer un SPA. C'est remarquable lorsque les frameworks fournissent une sensation SPA sans avoir à gérer une grande partie de cela vous-même, mais quand même, quelque chose le gère et que quelque chose est un tas de JavaScript.

Tom MacWright a récemment écrit à ce sujet dans son "Si ce n'est pas les SPA, quoi?" Publier. Certaines des alternatives actuelles:

Turbolinks… quel est le strict minimum que vous devez faire pour obtenir l'expérience SPA sans aucune coopération de votre application?

Turbolinks est comme… cliquez sur le lien, le clic est intercepté, la demande Ajax pour une nouvelle page est faite, JavaScript floppe le contenu de la page avec le nouveau contenu. Super facile à mettre en œuvre, mais il s'agit toujours de JavaScript, et pas particulièrement intelligent pour envoyer moins de données sur le fil.

barba.js et instant.page sont des approches alternatives au même type de problème.

Barba est tout au sujet des transitions de page en cours (plus de détails sur ce concept). instant.page concerne le pré-chargement / rendu des pages juste avant de cliquer, donc même si vous obtenez une actualisation de la page, cela semble moins intrusif (en particulier avec la tenue de peinture). Les deux sont sympas, mais pas tout à fait des remplacements individuels pour un SPA. (Même avec la tenue de peinture, le pré-rendu et les pages légères, je ne pense toujours pas que l'expérience soit assez une douceur comme un SPA. Par exemple, vous obtenez toujours le spinner de chargement de page.)

Alors… est-ce que le reste est en train de cuire? Kinda. Il y a . Peut-être trop simplifié, mais voilà: les portails sont comme des iframes. Ils peuvent même être affichés visuellement comme une iframe. Cela signifie que le rendu de l'URL dans le portail est déjà terminé. Ensuite, vous pouvez «promouvoir» le portail en tant que page active, et même animer le portail lui-même ce faisant.

Je ne déteste pas ça. Je peux imaginer que quelqu'un construise une bibliothèque de type turbolinks sur des portails afin qu'ils soient «faciles à utiliser» et rendent un site plus proche du SPA.

Pourtant, animer un rectangle en position n'est pas souvent ce que l'on souhaite pour les transitions de page animées. Consultez l’article de Sarah intitulé «Animations natives pour les transitions de page sur le Web». C’est ce que veulent les gens (du moins la possibilité). C’est pourquoi Jeremy a dit pas des portails l'autre jour quand il a dit effrontément que "(m) La plupart des applications à page unique ne sont que des carrousels géants.«Il évoque également la proposition de Jake sur les transitions de navigation il y a quelques années.

J'adore cette proposition. Il se concentre sur les besoins des utilisateurs. Il demande également Pourquoi les gens utilisent les frameworks JavaScript au lieu d'utiliser ce que les navigateurs fournissent. Les gens recherchent les frameworks JavaScript parce que les navigateurs ne fournissent pas encore certaines fonctionnalités: des composants comme des onglets ou des accordéons; DOM différent; contrôle des éléments de forme complexes de style; transitions de navigation. Les problèmes que les frameworks JavaScript résolvent aujourd'hui doivent être considérés comme les départements R&D pour les standards web de demain. (Et inversement, je crois fermement que le but de tout bon framework JavaScript devrait être de se rendre redondant.)

Alors, quelle est la meilleure méthode de rendu? Ce qui fonctionne le mieux pour vous, mais peut-être qu'une hiérarchie comme celle-ci a un sens général:

  1. HTML statique autant que vous le pouvez
  2. Fonctions Edge sur HTML statique pour que vous puissiez faire toutes les choses dynamiques
  3. Le serveur a généré HTML ce que vous devez faire après cela
  4. Le rendu côté client uniquement ce que vous devez absolument

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *