Pour faire simple, aujourd'hui pour avoir une "expérience utilisateur" correcte on fait des applications client-side. On navigue en ajax/fetch, on modifie que des morceaux de l'UI pour aller plus vite, avoir de la perf et que l'utilisateur ait une navigation confortable.
Mais en vrai dans ce cas les pages n'existent pas en statique. Donc pas de référencement par exemple (même s'il existe des gruges de ce côté ci).
Mais surtout, si on veut arriver directement sur une page précise, le serveur va rendre la base puis le client vas modifier ce qu'il faut pour afficher le contenu (car l'app n'est pas gérée côté serveur, en général côté serveur ce sont plutôt des api). Donc c'est lent.
Si on ne fait pas client-side, le serveur calcul tout à chaque fois, c'est sympa car en général la page demandée arrive très vite, mais la navigation est plus lente, le serveur re-rend chaque page et le client aussi.
Des technos comme turbolinks dont il est question dans Rails font un mix, les pages sont crées côté serveur et on fusionne body/header des pages côté client, avec une gestion de cache. C'est un intermédiaire assez sympa.
La "vrai" solution est donc que l'app tourne aussi bien côté serveur que côté client.
Côté serveur car cela permet d'arriver rapidement n'importe où (et même de faire du sans js).
Côté client car cela permet de naviguer agréable et rapidement dans l'app.
[^] # 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é à 4.
Pour faire simple, aujourd'hui pour avoir une "expérience utilisateur" correcte on fait des applications client-side. On navigue en ajax/fetch, on modifie que des morceaux de l'UI pour aller plus vite, avoir de la perf et que l'utilisateur ait une navigation confortable.
Mais en vrai dans ce cas les pages n'existent pas en statique. Donc pas de référencement par exemple (même s'il existe des gruges de ce côté ci).
Mais surtout, si on veut arriver directement sur une page précise, le serveur va rendre la base puis le client vas modifier ce qu'il faut pour afficher le contenu (car l'app n'est pas gérée côté serveur, en général côté serveur ce sont plutôt des api). Donc c'est lent.
Si on ne fait pas client-side, le serveur calcul tout à chaque fois, c'est sympa car en général la page demandée arrive très vite, mais la navigation est plus lente, le serveur re-rend chaque page et le client aussi.
Des technos comme turbolinks dont il est question dans Rails font un mix, les pages sont crées côté serveur et on fusionne body/header des pages côté client, avec une gestion de cache. C'est un intermédiaire assez sympa.
La "vrai" solution est donc que l'app tourne aussi bien côté serveur que côté client.
Côté serveur car cela permet d'arriver rapidement n'importe où (et même de faire du sans js).
Côté client car cela permet de naviguer agréable et rapidement dans l'app.