j’ai du mal à voir l’intérêt de faire un rendu serveur.
L'intérêt est dans la performance permettant à arriver au premier rendu utilisable côté utilisateur.
En général avec des app client side ça se passe en deux temps : chargement de l'app côté client avec tout le js qui va bien puis appel au serveur pour des datas qui ensuite sont rendues.
Mais c'est quand même un peu con car les datas étaient déjà connues lors de l'appel à la page côté serveur, pour l'utilisateur ça aurait été plus rapide d'avoir la page contenant déjà les bonnes infos.
la charge sur le serveur est celle qui coûte
Oui, c'est certains que ça coûte.
celle sur le client est gratuite (sauf exceptions)
Ha ben non, c'est pas gratuit du tout. Si par exemple tu fais un site de vente en ligne, tu verra que chaque seconde (ou dixième de) fait en réalité perdre des ventes. Un site qui rame est un site qui ne vent pas, mais aussi un site qui donne envie d'aller voir le concurrent plus rapide par exemple. Donc avoir une expérience utilisateur qui n'est pas bonne risque même de coûter plus cher que ton serveur.
la solution est peut-être plus à chercher dans un moteur de rendu html tournant au sein d’un reverse proxy que directement dans le code du site.
Pourquoi ? Ça me parait justement tordu voir super consommateur de ressources. Certains faisaient par exemple ça avec des phantomjs tournant côté serveur, je suis pas certains que ça ait laissé un super souvenir à beaucoup.
Pour ceux que ça intéresse il y a cette conférence de François Zaninotto sur "l'expérience utilisateur ultime" qui est vraiment sympa : https://www.youtube.com/watch?v=tIlQCIz9XF8
[^] # Re: Ruby <3
Posté par CrEv (site web personnel) . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 6.
L'intérêt est dans la performance permettant à arriver au premier rendu utilisable côté utilisateur.
En général avec des app client side ça se passe en deux temps : chargement de l'app côté client avec tout le js qui va bien puis appel au serveur pour des datas qui ensuite sont rendues.
Mais c'est quand même un peu con car les datas étaient déjà connues lors de l'appel à la page côté serveur, pour l'utilisateur ça aurait été plus rapide d'avoir la page contenant déjà les bonnes infos.
Oui, c'est certains que ça coûte.
Ha ben non, c'est pas gratuit du tout. Si par exemple tu fais un site de vente en ligne, tu verra que chaque seconde (ou dixième de) fait en réalité perdre des ventes. Un site qui rame est un site qui ne vent pas, mais aussi un site qui donne envie d'aller voir le concurrent plus rapide par exemple. Donc avoir une expérience utilisateur qui n'est pas bonne risque même de coûter plus cher que ton serveur.
Pourquoi ? Ça me parait justement tordu voir super consommateur de ressources. Certains faisaient par exemple ça avec des phantomjs tournant côté serveur, je suis pas certains que ça ait laissé un super souvenir à beaucoup.
Pour ceux que ça intéresse il y a cette conférence de François Zaninotto sur "l'expérience utilisateur ultime" qui est vraiment sympa : https://www.youtube.com/watch?v=tIlQCIz9XF8