Merci pour l’explication, c’est plus clair. Hormis la problématique du référencement (je t’avoue que je n’ai pas encore regardé comment on faisait le référencement pour une appli angularjs, pour parler de technos que je connais), j’ai du mal à voir l’intérêt de faire un rendu serveur.
Les arguments contre que je vois sont :
- la charge sur le serveur est celle qui coûte, celle sur le client est gratuite (sauf exceptions)
- les dimensions du client sont connues par... le client, qui saura donc le mieux faire le layouting qui va bien (adaptation mobile / tablette, par exemple)
J’ai presque envie de dire que si la problématique est une problématique de cache / rapidité, 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.
Après, il faut dire que j’ai tendance à structurer mes applications webs en tant que un front angular, et un back en json (soit jsonrpc, soit api http), ce qui fait que côté « serveur » la notion même de html n’existe plus. De mon point de vue, le templating côté serveur n’est pas l’avenir, mais plutôt restreint à des niches (clients avec très peu de puissance de calcul). Je ne connais pas du tout turbolinks dont tu parles, il faudra que j’y jette un œil à l’occasion (mais l’écosystème rails m’est complètement étranger).
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.
Merci pour l’explication, c’est plus clair. Hormis la problématique du référencement (je t’avoue que je n’ai pas encore regardé comment on faisait le référencement pour une appli angularjs, pour parler de technos que je connais), j’ai du mal à voir l’intérêt de faire un rendu serveur.
Les arguments contre que je vois sont :
- la charge sur le serveur est celle qui coûte, celle sur le client est gratuite (sauf exceptions)
- les dimensions du client sont connues par... le client, qui saura donc le mieux faire le layouting qui va bien (adaptation mobile / tablette, par exemple)
J’ai presque envie de dire que si la problématique est une problématique de cache / rapidité, 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.
Après, il faut dire que j’ai tendance à structurer mes applications webs en tant que un front angular, et un back en json (soit jsonrpc, soit api http), ce qui fait que côté « serveur » la notion même de html n’existe plus. De mon point de vue, le templating côté serveur n’est pas l’avenir, mais plutôt restreint à des niches (clients avec très peu de puissance de calcul). Je ne connais pas du tout turbolinks dont tu parles, il faudra que j’y jette un œil à l’occasion (mais l’écosystème rails m’est complètement étranger).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0