Discussion :

[Community Management]

Chers membres du club,

J'ai le plaisir de vous présenter ce tutoriel de Olivier Boisse pour vous apprendre l'isomorphisme avec React et Node.js.

L'utilisation de frameworks JavaScript est une pratique de plus en plus répandue à l'heure actuelle. Ces derniers nous permettent de mieux organiser nos projets et d'augmenter notre productivité. On peut toutefois se retrouver coincé lorsque l'on se penche sur la question du référencement. La plupart des moteurs de recherche ne liront pas le JavaScript et, par conséquent, ne pourront pas indexer correctement les pages de votre site.

On entend parler aujourd'hui d'application isomorphe (ou universelle) dont la particularité est de pouvoir générer le rendu HTML à la fois côté client et côté serveur. Cette technique est accessible avec l'utilisation de Node.js qui nous permet de tirer profit du JavaScript côté serveur.

Dans ce tutoriel, j'illustrerai mes propos à travers un exemple en utilisant React et Node.js. React est une bibliothèque JavaScript, développée par Facebook, permettant de créer des composants qui constitueront l'interface du site. Sa particularité est de manipuler le DOM de façon intelligente en ne modifiant que le strict minimum lors du rafraîchissement des données.

Bonne lecture.

Retrouvez tous les tutoriels et cours de la sociéte Soat
Retrouvez les meilleurs cours et tutoriels pour apprendre le JavaScript.

[Marco46]

Pourquoi avoir recours à l'isomorphisme ?

Je trouve l'argument de la performance fallacieux.

Ce qui compte c'est d'afficher quelque chose à l'utilisateur le plus vite possible. Peu importe que les premières données soient présentes ou pas, il faut montrer à l'utilisateur que la webapp est chargée, c'est pas grave si les premières données ne sont pas présentes. En corrélant la récupération de la webapp à la résolution de la première requête on ne fait qu'allonger cette durée, donc on dégrade les performances au lieu de les augmenter ! Le seul cas où ça pourrait avoir du sens c'est si ces données sont les mêmes pour tout le monde et peuvent bénéficier d'un mécanisme de cache. Dans ce cas seulement, peut-être que de construire la vue d'abord côté serveur (et voire même de cacher directement la vue) aurait du sens.

Il faut également noter que tout ceci n'a de sens qu'au bootstrap de la webapp, une fois que l'utilisateur a mis en cache la SPA, le templating côté serveur n'a aucune chance de battre le cache client en terme de perfs.

Ceci n'enlève rien à la qualité de l'article, même si je n'aime pas React (à cause de sa gestion du html) et aurait préféré avoir le même article avec Angular

[phildepantin]

Bonjour,

Je trouve l'argument de la performance fallacieux.

Heu… Où est-il question de performance*? L'isomorphisme concerne le référencement, rien à voir avec la performance (en tout cas comme le terme est entendu ici).

[Marco46]

Ben dans le tutoriel ...

L'auteur avance 2 arguments, le référencement (ok) et les performances (là je suis pas ok du tout) :

I. Pourquoi avoir recours à l'isomorphisme ?

Comme je l'ai dit précédemment, un des motifs majeurs concerne le référencement. On peut également trouver un autre avantage concernant la rapidité d'affichage des pages.

[...]

La partie sur le référencement est évacuée en une demi-phrase et ensuite tout le reste concerne la justification des performances.

Je te cite également la réponse de l'auteur de l'article à un commentaire sur l'article origine du site de SO@T :

@Fred : Comme précisé dans l’article, l’avantage ne concerne pas uniquement le référencement. L’isomorphisme permet également d’améliorer le temps de chargement du site (ici le rendu est généré côté serveur, si on génère le contenu uniquement côté client il faut attendre que la librairie javascript ‘React’ soit chargée dans le navigateur). Pour un petit projet comme celui-ci la différence n’est pas flagrante mais sur un projet de plus grande envergure cet aspect sera plus visible. Concernant le référencement, Google est déjà capable d’exécuter du javascript, cependant le référencement risque d’être moins performant qu’un site traditionnel dont le rendu html est généré par le serveur.

Pour avoir bossé sur une appli AngularJS où le temps de bootstrap de la webapp était déterminant je peux t'assurer que l'approche isomorphique pour résoudre ce problème est idiote. L'important étant de donner à manger à l'utilisateur le plus vite possible pour qu'il ne zappe pas (t'as en gros 2 secondes). Le plus efficace est donc le lazy downloading de ressource et afficher au plus tôt des informations à l'utilisateur. On avait fait ça avec requireJs à l'époque.

Si tu attends que le serveur récupère les infos de la DB puis génère la page puis l'envoie à la webapp t'es pas sorti du sable. T'envoie direct le html et les css dont t'as besoin pour afficher un bout d'appli et c'est tout, t'attend rien tu réponds immédiatement.