Début Décembre, j’ai pu assiter à la conférence dotJS, prétendument la plus grande conférence JavaScript d’Europe, le but étant non seulement de se tenir à jour mais aussi et surtout de prendre du recul sur notre métier de développeur.
Parmi les speakers se trouvaient Igor Minar, l’un des créateurs d’Angular, Fedor Indutny, contributeur à Node.js ou encore Evan You, créateur du framework front qui monte, vue.js. C’est une conférence qui se déroulait sur une journée et où les speakers se succèdent dans un seul amphi. Du coup, même programme pour tout le monde ! On y a parlé de Service Workers, de Babel, de Electron, mais aussi beaucoup de sujets plus profonds, qui nous forcent à remettre en cause nos méthodes de tous les jours.
Parce-que dans le monde du Web, on aime faire bouger les choses. Innover, inventer, créer… Mais on aime aussi beaucoup revenir en arrière. Pour mieux avancer.
- Par exemple, on jugeait bon à l’époque qu’un élément HTML porte son style. Puis avec CSS on a séparé la structure et le style. Mais avec les Web Components, on fait un petit pas en arrière pour mieux aller de l’avant, en regroupant structure, style et scripts au même endroit.
- On mettait aussi en avant les bases NoSQL, plus rapides pour des grandes quantités de données. Puis on s’est rendu compte qu’il fallait gérer des relations… Finalement, c’est pas si mal, une base relationnelle.
- Jadis, on aimait JavaScript pour sa légèreté et son absence de typage… Vous voyez où je veux en venir ? Flow, TypeScript… On y revient !
Aujourd’hui je vais vous parler de ce que l’on fait sur le web depuis plusieurs décennies maintenant. Le server-side rendering. C’est un des sujets en vogue ces temps-ci. Pourquoi ?
On n’était pas bien avec notre client-side rendering ?
L’avantage du client-side rendering, utilisé par Angular, Ember, React et autres, c’est qu’une fois l’application récupérée côté client (dans le navigateur), tout est piloté depuis le poste du client. Le navigateur fait les appels à l’API, récupère les données dont il a besoin lors d’une action utilisateur et modifie le DOM en conséquence. C’est à priori plus réactif que le server-side rendering puisqu’il est possible de mettre à jour le DOM directement après une action de l’utilisateur, sans attendre de réponse du serveur.
Mais cette technique a ses limites : temps de chargement initial élevé, difficultés de référencement…
Le server-side rendering à la rescousse
Dans une forme un peu revisitée, le server-side rendering “nouvelle génération” permet d’allier les avantages des deux techniques.
Le chargement initial de la page, au lieu de charger une coquille vide qui devra requêter l’API, chargera tout le DOM, prêt à s’afficher dans le navigateur. Là où on ne reproduit pas les erreurs d’antan, c’est qu’après une action de l’utilisateur, au lieu de recharger toute la page, on va juste venir insérer le DOM modifié et renvoyé par le serveur au bon endroit.
Le serveur est donc en charge de fournir à la fois une page initiale complète, mais aussi des petits morceaux de DOM dynamiquement lors d’une requête. Par exemple, sur Twitter, on a ce comportement :
$('#loadTweets').on('click', function (event) {
$.get('/tweets/person', {last_id: 999}, function (moreTweets) {
$('#tweets').prepend(moreTweets);
});
event.preventDefault();
});Lors d’un clic sur le bouton de chargement des tweets supplémentaires, le serveur ne renvoie pas un format JSON mais plutôt un morceau de page HTML que l’on va insérer dans le DOM.
Quels avantages ?
Le temps de chargement initial
Avec le client-side rendering, on télécharge d’abord la coquille, et seulement une fois toute la coquille téléchargée, il faut la parser et l’exécuter… pour télécharger les données et enfin mettre à jour le DOM. le serveur-side rendering renvoie déjà une page prête à l’emploi.
Le référencement
Google n’extrait pas les informations d’une application qui utilise le client-side rendering. Il ne voit que la coquille vide… Il est donc plus difficile de référencer ce genre de pages. Avec le server-side rendering en revanche, toutes les informations sont disponibles pour l’indexation.
Le contrôle de l’expérience utilisateur
Lorsque l’on développe une application web, on le fait souvent sur une bonne machine. Avec la majorité des traitements qui s’effectuent côté client, il est alors possible de rencontrer des problèmes de fluidité sur certaines machines moins puissantes. En utilisant du server-side rendering, on contrôle cet aspect car c’est le serveur qui fait le travail.
Avec quoi faire du server-side rendering ?
La société ZEIT a présenté pendant cette conférence un framework nommé Next.js, basé sur React.js qui permet de faire du server-side rendering.
Si vous utilisez vue.js (je recommande de l’essayer, je l’ai utilisé avec succès sur plusieurs projets), Nuxt permet d’intégrer cette fonctionnalité au framework.
