Modèles côté client vs côté serveur (lequel?)

Question

J'ai lu récemment des articles très intéressants sur l'ensemble du rendu client vs serveur.

http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html

http://www.quirksmode.org/blog/archives/2015/01/angular_and_tem.html

http://tomdale.net/2015/02/youre-missing-the-point-of-server-side-rendered-javascript-apps/

Maintenant, je suis un peu fan du côté client, mais après avoir lu ces articles, certains points ont commencé à apparaître en faveur du rendu côté serveur, à ma grande surprise ... Les principaux points étaient:

1) Vous pouvez mettre à jour votre serveur, mais pas votre appareil utilisateur - Cela signifie, eh bien, oui ... vous contrôlent le serveur, donc s'il est sous-performant, vous pouvez opter pour une mise à niveau/évolutivité. Vous ne pouvez pas forcer les utilisateurs à mettre à niveau leurs appareils.
2) Première peinture vs dernière peinture - Maintenant sur le experimentally verified... le lien au-dessus montre quand les utilisateurs voient la page pour la première fois (première peinture) et quand les utilisateurs peuvent utiliser la page à 100% (dernière peinture). Maintenant, d'après ce que je peux penser lorsque l'utilisateur voit la page, il faut du temps à son cerveau pour traiter les signaux du cortex visuel vers le cortex frontal, puis vers le cortex prémoteur où l'utilisateur commence réellement à cliquer avec son doigt, que est bien sûr si le html est rendu en premier afin que le cerveau ait quelque chose à traiter pendant le chargement en arrière-plan (fichiers js, liaison, etc.).

Ce qui m'a vraiment attiré, c'est que Twitter a rapporté que les gens avaient jusqu'à 10 secondes de temps de chargement pour le rendu côté client, personne ne devrait jamais en faire l'expérience ! C'est un peu dire: " Eh bien, si vous n'avez pas un appareil assez bon, désolé, vous devrez juste attendre.".

J'ai pensé qu'il n'y avait pas un bon moyen d'utiliser les deux moteurs de modèles côté client et côté serveur et que client et serveur utilisent le même moteur de modèle et code. Dans ce cas, il s'agit uniquement de déterminer s'il est bienfaiteur de fournir au client la page rendue ou de laisser le client la restituer lui-même.

En tout cas, partagez vos réflexions sur mes propos et les articles si vous le souhaitez. Je suis tout ouïe!

Alexander Mikhalchenko · Accepted Answer

Fondamentalement, vous recherchez une application web isomorphe qui partage le même code pour le frontend et le backend.

JavaScript isomorphe

Applications JavaScript qui s'exécutent à la fois côté client et côté serveur. Les frameworks JavaScript isomorphes sont la prochaine étape dans l'évolution des frameworks JavaScript. Ces nouvelles bibliothèques et frameworks résolvent les problèmes associés aux frameworks JavaScript traditionnels.

Je parie ce mec explique ça beaucoup mieux que moi.

Ainsi, lorsqu'un utilisateur arrive sur la page, le serveur affiche la page complète avec son contenu. Il se charge donc plus rapidement et ne nécessite aucune demande ajax supplémentaire pour charger les données, etc. Ensuite, lorsqu'un utilisateur navigue vers une autre page, les techniques habituelles pour les applications d'une seule page sont utilisées.

Alors, pourquoi devrais-je m'en soucier?

Anciens navigateurs/appareils faibles/Javascript désactivé
SEO
Quelques améliorations de chargement de page

Anciens navigateurs/appareils faibles/Javascript désactivé

Par exemple, IE9 ne prend pas en charge l'API d'historique. Ainsi, pour les anciens navigateurs (et si l'utilisateur désactive également le javascript), il parcourrait simplement les pages comme il l'avait fait au bon vieux temps.

SEO

Google dit il prend en charge les SPA mais les SPA ne sont pas susceptibles d'apparaître dans les meilleurs résultats de la recherche Google, n'est-ce pas?

Vitesse de page

Comme il a été dit, la première page se charge avec une seule requête HTTP, et c'est tout.

D'accord alors

Il y a beaucoup d'articles à ce sujet:

Mais devrais-je m'en soucier?

Cela dépend de vous, bien sûr.

Oui, c'est cool, mais il faut beaucoup de travail pour réécrire/adapter l'application existante. Et si votre backend est en PHP/Ruby/Python/Java/peu importe, j'ai de mauvaises nouvelles pour vous (ce n'est pas nécessairement impossible, mais proche de cela).

Cela dépend du site Web, vous pouvez essayer de collecter des statistiques et si le pourcentage d'utilisateurs avec d'anciens appareils est petit, cela ne vaut pas la peine, alors pourquoi pas ...

LAISSEZ-LES SOUFFRIR

Si vous ne vous souciez que des utilisateurs d'anciens appareils, alors allez-y, c'est 2015, et c'est le problème de votre utilisateur s'il utilise IE8 pour naviguer sur des sites Web avec un iPod Touch 2. Par exemple, Angular abandonné Prise en charge d'IE8 dans la version 1.3 il y a environ un an, alors pourquoi ne pas simplement alerter les utilisateurs qu'ils doivent effectuer une mise à niveau;)

À votre santé!