Discussion :

[ManUtopiK]

Bonjour à tous,

de plus en plus de framework front-end (angular2, react, mithrill, ember...) tendent à devenir isomorphic. C'est à dire que le code peut-être interprété à la fois côté client et serveur. Ceci pour répondre aux contraintes SEO et pour afficher la première page plus rapidement.
Je me pose la question de l'intérêt réel de cette approche.

Pour faire bref, un framework MVVC à cette approche :
1- le serveur envoie du html quasi vide + le framework js
2- une fois le framework chargé côté client, il appel les données et les vues
3- une fois qu'il a tout ça, il compile par contrôleur et rend la vue html

Avantage : les données se retrouvent côté client, donc possibilité de faire du two-way data binding, le serveur n'envoie pas les vues html c'est juste un serveur API CRUD.
Inconvénient : le contrôle des appels CRUD doit quand même se faire côté serveur. La page initiale html est vide donc c'est mauvais pour le SEO. La gestion du routing doit se faire côté client et serveur.


Pour ma part, j'ai fait plusieurs sites/app utilisant l'API HTML5*History avec pushstate.
En gros, côté client, je regarde si le lien appelé est interne, ou si l'utilisateur parcours son historique de navigation. Si c'est le cas, j'intercepte l'appel du lien et je fais une requête ajax à la place pour obtenir les données. A la reception, je compile par un contrôleur et je rend la vue correspondante.
Côté serveur, je regarde si l'appel est du type xhr. Si c'est le cas, j'envoie seulement les données. Si ce n'est pas le cas, j'affiche l'html correspondant à la route appelée.

Avantage : Si c'est un appel d'un bot pour du SEO, je renvoie bien la vue intégrale, pas les données. Je ne fais pas du routing côté client. Je peux aussi faire du two-way data binding. C'est compatible no-javascript et old-school-browser.
Inconvénient : Je suis obligé de gérer mes templates côtés serveur et client. Au premier chargement, je n'ai que la vue, pas les données.

D'où ma question, si quelqu'un y comprend quelque chose à ce que j'explique, est de savoir si le javascript isomorphic ne cherche pas à réinventer la roue pour pas grand chose ? Et s'il y a un réel intérêt à suivre cette tendance ?

[mh-cbon]

Ce n'est pas que cela, une histoire de SEO, c'est aussi des librairies qui compilent pour le browser tout autant que le serveur.
Exemple : https://github.com/feross/webtorrent

Sinon j'aime bien avoir le choix de compiler mes tags riot.js sur le serveur ou le client en fonction de mes besoins, et sans avoir à tout re faire.

Si tu as du temps je t'invites à regarder comment substack utilise browserify durant ses démo pour coder
https://www.youtube.com/results?sear...james+halliday

D'un autre point de vue cela permet d'éviter de dupliquer les modules pour chaque environnement, donc par exemple je peux utiliser le module url de node dans mon browser si tant est que j'utilise browserfiy ou webpack.