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.
Mais les deux ne sont pas même pas forcément sur le même serveur. Servir les templates statiques et le js est très peu coûteux en charge serveur. C’est clair qu’il y a un peu de latence supplémentaire, puisque tu ne peux pas charger le contenu côté serveur sans avoir chargé celui côté client.
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.
C’est vrai que j’ai tendance à oublier que certains réussissent à faire des horreurs comme rueducommerce qui rame horriblement côté client. Mais mon expérience (côté dev) est quand même souvent que quand ça rame, c’est parce que le serveur est lent à répondre, et au contraire, je trouve que le chargement asynchrone des données améliore l’« expérience utilisateur », car le site s’affiche, même partiellement, tandis que dans un templating côté serveur, le plus souvent tant que les données n’ont pas été récupérées rien ne s’affiche (pas pour rien qu’on recourt quasiment systématiquement à un cache du html dans ce cas).
Ça reste subjectif cela dit, je manque de données objectives de comparaison. Si tu en as je suis intéressé.
Pourquoi ? Ça me parait justement tordu voir super consommateur de ressources.
Je pense pas que ça soit significativement plus consommateur de ressources qu’un moteur de templating classique (en gros, c’est juste manipuler du dom avec du js). phantomjs, c’est beaucoup plus bourrin, ça fait le rendu image.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Ruby <3
Posté par whity . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 2.
Mais les deux ne sont pas même pas forcément sur le même serveur. Servir les templates statiques et le js est très peu coûteux en charge serveur. C’est clair qu’il y a un peu de latence supplémentaire, puisque tu ne peux pas charger le contenu côté serveur sans avoir chargé celui côté client.
C’est vrai que j’ai tendance à oublier que certains réussissent à faire des horreurs comme rueducommerce qui rame horriblement côté client. Mais mon expérience (côté dev) est quand même souvent que quand ça rame, c’est parce que le serveur est lent à répondre, et au contraire, je trouve que le chargement asynchrone des données améliore l’« expérience utilisateur », car le site s’affiche, même partiellement, tandis que dans un templating côté serveur, le plus souvent tant que les données n’ont pas été récupérées rien ne s’affiche (pas pour rien qu’on recourt quasiment systématiquement à un cache du html dans ce cas).
Ça reste subjectif cela dit, je manque de données objectives de comparaison. Si tu en as je suis intéressé.
Je pense pas que ça soit significativement plus consommateur de ressources qu’un moteur de templating classique (en gros, c’est juste manipuler du dom avec du js). phantomjs, c’est beaucoup plus bourrin, ça fait le rendu image.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0