Discussion :

[yann2]

[/COLOR]Le rendu côté serveur, c'est aussi vieux que le Web lui-même. En revanche, combiner les bénéfices du rendu côté serveur et côté client, avec la même codebase et une transition invisible, c'est assez inédit.

Et s'il y en a qui doutent encore des bénéfices du rendu côté client, c'est qu'ils sont restés bloqués en 2005

Certains regretteront quand même que le codebase (ça fait un peu destroy tous ces mots anglais ) en question soit en javascript. (oui, bon je sais, angular 2 préconise l'utilisation de Typescript, d'ailleurs moi aussi je préconise l'utilisation de Typescript )

On peut quand même rigoler de voir que les gars qui ont dit qu'il faut stopper le rendu côté serveur parce que ce n'est pas user-friendly s'amusent à intégrer du rendu côté serveur pour régler des problèmes de performance. Laisse moi profiter de l'ironie de la situation surtout qu'ils nous le vendent comme une feature révolutionnaire !!

Sinon, personnellement, qu'il y ait du rendu côté client ne me gêne pas, hein Surtout que la radicalisation de cette approche a eu le gros avantage de populariser REST. Rien n'empêche d'avoir une architecture RESTful avec une couche de rendu côté serveur, soit dit en passant.

De plus, je ne crois pas que toutes les applications web nécessitent l'utilisation d'un angular ou équivalent. Tout dépend du besoin. Si c'est juste pour mettre des messages de validation, je ne vois pas vraiment l'intérêt, à part peut être pour faire so 2016 ? (j'espère que ce n'est pas ce que sous entendait ton message) ... il faut rester pragmatique. D'ailleurs, il y a d'autres techniques pour faire du single page application avec rendu côté client : un client lourd. Firefox, par exemple, est un client lourd (et il arrive à se mettre à jour automatiquement en plus, dingue !) ! Et qu'on ne me dise pas qu'une appli web va être accessible directement via mobile/tablette/PC/grille-pain. Un téléphone mobile ne s'utilise pas comme un PC donc, dans les faits, on est soit obligé de développer deux clients, soit essayer de faire un mixte au sein d'un seul client en réorganisant le DOM en fonction de la taille de l'écran (je trouve que la deuxième solution peut vite donner du code horrible à maintenir d'ailleurs...).

Enfin, sur ces derniers mots, il y a aussi des gens qui aiment le web ce pour quoi il est fait à la base. Le web qui est accessible à tous (notamment aux malvoyants) pour un coût dérisoire. Ce web responsive pour 0 €. Ce web ou les boutons précédent et suivant du navigateur font ce qu'on attend d'eux ! Ce web où tu ne télécharges pas plusieurs méga-octets de données pour lire un article ! C'est ce web là : http://motherfuckingwebsite.com/. (tu vois, perso, je suis même resté bloqué en 1995, les gifs en moins )

Peace

[SylvainPV]

Développer deux clients pour un même site web, ou un client lourd pour consommer un service qui a sa place sur le web, c'est précisément ce que je cherche à éviter à tout prix. J'ai écrit ce bouquin pour essayer de convaincre les gens d'adopter l'approche One Web. Deux interfaces pour un même service, c'est fragmenter les usages et faire un cloisonnement d'idées. Qui s'étonne encore de voir un utilisateur de smartphone préférer la version desktop d'un site plutôt que la version dédiée mobile ? Qui pense encore à une nette séparation entre mobile et desktop à l'heure des tablettes hybrides ? Quant au client lourd, il n'est logiquement pas accessible à tous, que la restriction vienne de l'OS lui-même ou des droits de l'utilisateur. Je t'invite à lire l'intro de mon livre qui détaille davantage mon point de vue sur le sujet.

On peut parfaitement faire une SPA légère, responsive et accessible. Le coup des boutons de navigation qui ne fonctionnent pas, c'est un vieux cliché des SPA bâclées. Justement, mon projet pro actuel est la refonte complètement d'une RIA anciennement en Nuxéo vers du Angular 2 et une architecture micro-service. Et bien les boutons de navigation précédent/suivant ne fonctionnaient pas avec l'appli Nuxeo à cause de divers problèmes avec la gestion de session, et ce malgré que tout le rendu soit côté serveur. La refonte va permettre de régler ça, sans qu'il y ait un rapport direct avec le passage à un routeur JavaScript. Peu importe les choix techniques, s'il y a de mauvais développeurs ou du travail bâclé, l'utilisateur en paiera les conséquences.

Je ne dis pas d'utiliser Angular à tout bout de champ, d'ailleurs je trouve beaucoup de défauts à ce framework. Mais étant spécialisé front-end, quand je vois un projet partir sur du PHP/JSP/ASP, je ne peux pas m'empêcher de lister dans ma tête tous les avantages du rendu côté client qui seront perdus ou difficilement rattrapables.
...Usage offline, on oublie.
...Compensation de latence, niet.
...Résistance aux downtime serveur, aux pertes momentanées de connexion, nada.
...Optimiser la taille des requêtes, only data on wire, nope.
...Changer la langue du site sans rafraîchir la page, haha tu rêves !
...et je pourrais continuer encore longtemps...

[Invité]

Certains regretteront quand même que le codebase (ça fait un peu destroy tous ces mots anglais ) en question soit en javascript. (oui, bon je sais, angular 2 De plus, je ne crois pas que toutes les applications web nécessitent l'utilisation d'un angular ou équivalent. Tout dépend du besoin. Si c'est juste pour mettre des messages de validation, je ne vois pas vraiment l'intérêt, à part peut être pour faire so 2016 ? (j'espère que ce n'est pas ce que sous entendait ton message) ... il faut rester pragmatique. D'ailleurs, il y a d'autres techniques pour faire du single page application avec rendu côté client : un client lourd. Firefox, par exemple, est un client lourd (et il arrive à se mettre à jour automatiquement en plus, dingue !) ! Et qu'on ne me dise pas qu'une appli web va être accessible directement via mobile/tablette/PC/grille-pain. Un téléphone mobile ne s'utilise pas comme un PC donc, dans les faits, on est soit obligé de développer deux clients, soit essayer de faire un mixte au sein d'un seul client en réorganisant le DOM en fonction de la taille de l'écran (je trouve que la deuxième solution peut vite donner du code horrible à maintenir d'ailleurs...).

Les frameworks css comme foundation 6.0 permettent de créer des sites responsives sur téléphone Mobile 5 pouces et qui rendent très bien sur ordinateur de bureau, tout s'adapte automatiquement.
Il n'y a pas 2 versions de l'appli ou du site web. C'est le framework css qui fait tout le travail.
Sinon, bah,comparer Php-Sql-base relationnelles, pour moi quand tu vois AngularJs 1.x-AngularFire-noSql à côté, ben , la différence c'est la facilité, la puissance, la flexibilité extrême, l'ingéniosité est du côté du couple Angular-AngularFire noSql, bref le resultat des dernières recherches anglo saxonnes en matière de web, une technologie qui te permet de faire ce que tu veux, un peu similaire à node.js+ expressjs mais bien plus facile , pourvu qu'ils continuent.

[youtpout978]

...Changer la langue du site sans rafraîchir la page, haha tu rêves !
...et je pourrais continuer encore longtemps...

Il y a aussi des problèmes, le SEO pas encore vraiment bien géré, le rewriting suivant la langue assez complexe à gérer, la pauvreté du JS (pour le moment) nous obligeant à intégrer toujours plus de librairie.

J'ai développer 2 sites depuis 0 dernièrement en AngularJS et j'ai rencontré ces problèmes, après il existe des outils pour ça tel que prerender pour le SEO par exemple ... mais disons qu'avec une technologie serveur on aurait pas à s'en soucier (on peut toujours coupler les 2).

Et aussi arrivé à un moment le navigateur commence à avoir un peu de mal, quand il ne crache pas tout simplement sur la page, si la personne a un PC peu performant ou un mobile ça peut commencer à se voir les ralentissements.

Ce que je veux dire par la c'est que le Full Js n'a pas que des avantages, sur un projet précédent on avait un site Asp MVC avec les templates en Angular JS, et je trouve que c'est une bonne alternative, on peut profiter des avantages de ASP pour le code-behind le routage, et d'Angular pour le rendu côté client.

[SylvainPV]

@youtpout978: oui, les crawling bots ne sont pas encore au point pour indexer correctement les SPA. C'est le principal intérêt des solutions dites "isomorphic js" ou "universal js" selon moi, ça et le 1% d'utilisateurs avec JS désactivé. Je n'ai jamais concrètement mis en place une solution de ce genre, je me contente de détecter les crawlers avec une liste d'User Agent connus et de les rediriger vers un fichier HTML statique bourré de mots-clés. Jusqu'ici ça fait l'affaire, mais j'espère que les crawlers sauront mieux gérer AJAX dans les années à venir.

Pour les ralentissements, le data-binding d'Angular 1 est assez gourmand, je suis en train d'écrire un article à ce sujet. Il y a eu de nets progrès avec Angular 2. Mais si ça en vient à crasher le navigateur, c'est qu'il y a un problème dans le code, je ne vois pas d'autre explications.

[youtpout978]

@youtpout978: oui, les crawling bots ne sont pas encore au point pour indexer correctement les SPA. C'est le principal intérêt des solutions dites "isomorphic js" ou "universal js" selon moi, ça et le 1% d'utilisateurs avec JS désactivé. Je n'ai jamais concrètement mis en place une solution de ce genre, je me contente de détecter les crawlers avec une liste d'User Agent connus et de les rediriger vers un fichier HTML statique bourré de mots-clés. Jusqu'ici ça fait l'affaire, mais j'espère que les crawlers sauront mieux gérer AJAX dans les années à venir.

Pour les ralentissements, le data-binding d'Angular 1 est assez gourmand, je suis en train d'écrire un article à ce sujet. Il y a eu de nets progrès avec Angular 2. Mais si ça en vient à crasher le navigateur, c'est qu'il y a un problème dans le code, je ne vois pas d'autre explications.

J'ai été confronté à ces problèmes de SEO une vrai horreur le plus chiant est surement la gestions des métas pour les réseaux sociaux...

Ces erreurs sont assez aléatoires mais tu peux souvent les renconter en mode debug ou quand tu fais un certain nombre d'action sur une page contenant énormément de JS, avec Chrome j'ai eu quelque fois des plantages de page mais c'est assez rare quand même.

Après j'attends de voir les performances d'Angular 2, c'est surtout sur mobile que c'est intéressant parce que c'est les plateformes les moins performantes souvent.

Voilà un des sites que j'ai réalisé (c'est pas une ref niveau code et architecture) et Angular n'a pas forcément de plus value pour le coup mais ça m'a permis de me remettre dans le bain vu le peu d'expérience que j'avais dessus et qui remontait à quelque mois : http://damdy.com/fr

[Marco46]

Et aussi arrivé à un moment le navigateur commence à avoir un peu de mal, quand il ne crache pas tout simplement sur la page, si la personne a un PC peu performant ou un mobile ça peut commencer à se voir les ralentissements.

+1 avec Sylvain, c'est un problème de code ou de conception, pas du framework en lui-même. J'ai constaté personnellement que les webapp mobiles faites avec du angular 1.x ont des perf imbattables par du templating côté serveur à besoin égal. Les latences des réseaux mobiles sont d'ailleurs les premiers responsables et non les éventuelles mauvaises perf des serveurs.


Je comprends toujorus pas l'histoire du serveur. J'étais au courant de la génération de la 1ère page côté serveur, cela signifie simplement que le serveur envoie au client une page déjà interprétée par Angular, le chargement est donc plus rapide. Mais je ne vois toujours pas le rapport avec le support python/java/etc ... puisque l'interprétation de cette page ne peut être effectuée que par un moteur javascript.

[Marco46]

On peut quand même rigoler de voir que les gars qui ont dit qu'il faut stopper le rendu côté serveur parce que ce n'est pas user-friendly s'amusent à intégrer du rendu côté serveur pour régler des problèmes de performance. Laisse moi profiter de l'ironie de la situation surtout qu'ils nous le vendent comme une feature révolutionnaire !!

Belle dialectique mais sans aucun fondement technique. Il ne s'agit d'un problème de perf de l'interprétation côté client par rapport au côté serveur, il s'agit d'optimiser le bootstrap de la webapp en pré-interprétant la 1ère page afin de la charger directement. Cela n'a rien à voir avec du templating côté serveur dans le sens classique.

[yann2]

Développer deux clients pour un même site web, ou un client lourd pour consommer un service qui a sa place sur le web, c'est précisément ce que je cherche à éviter à tout prix. J'ai écrit ce bouquin pour essayer de convaincre les gens d'adopter l'approche One Web. Deux interfaces pour un même service, c'est fragmenter les usages et faire un cloisonnement d'idées. Qui s'étonne encore de voir un utilisateur de smartphone préférer la version desktop d'un site plutôt que la version dédiée mobile ? Qui pense encore à une nette séparation entre mobile et desktop à l'heure des tablettes hybrides ? Quant au client lourd, il n'est logiquement pas accessible à tous, que la restriction vienne de l'OS lui-même ou des droits de l'utilisateur. Je t'invite à lire l'intro de mon livre qui détaille davantage mon point de vue sur le sujet.

On peut parfaitement faire une SPA légère, responsive et accessible. Le coup des boutons de navigation qui ne fonctionnent pas, c'est un vieux cliché des SPA bâclées. Justement, mon projet pro actuel est la refonte complètement d'une RIA anciennement en Nuxéo vers du Angular 2 et une architecture micro-service. Et bien les boutons de navigation précédent/suivant ne fonctionnaient pas avec l'appli Nuxeo à cause de divers problèmes avec la gestion de session, et ce malgré que tout le rendu soit côté serveur. La refonte va permettre de régler ça, sans qu'il y ait un rapport direct avec le passage à un routeur JavaScript. Peu importe les choix techniques, s'il y a de mauvais développeurs ou du travail bâclé, l'utilisateur en paiera les conséquences.

Je ne dis pas d'utiliser Angular à tout bout de champ, d'ailleurs je trouve beaucoup de défauts à ce framework. Mais étant spécialisé front-end, quand je vois un projet partir sur du PHP/JSP/ASP, je ne peux pas m'empêcher de lister dans ma tête tous les avantages du rendu côté client qui seront perdus ou difficilement rattrapables.
...Usage offline, on oublie.
...Compensation de latence, niet.
...Résistance aux downtime serveur, aux pertes momentanées de connexion, nada.
...Optimiser la taille des requêtes, only data on wire, nope.
...Changer la langue du site sans rafraîchir la page, haha tu rêves !
...et je pourrais continuer encore longtemps...

J'espère que c'est une blague... rendu côté serveur ça ne veut pas dire que les mecs ne savent pas faire une XmlHttpRequest ou utiliser JQuery. Ca ne veut pas dire "Eviter JavaScript à tout prix". Rendu côté serveur, ça veut dire générer du DOM côté serveur.

"...Usage offline, on oublie" --> OK, très certainement
"...Compensation de latence, niet." ---> Pourquoi ? Comme je fais du rendu côté serveur je n'ai pas le droit de développer du javascript pour afficher "Votre message a été envoyé" ou ce que tu veux d'autres ?
"...Résistance aux downtime serveur, aux pertes momentanées de connexion, nada." --> OK, très certainement
"...Optimiser la taille des requêtes, only data on wire, nope." ---> Du DOM zippé, ça ne pèse pas lourd, hein... j'aimerai bien connaitre la différence entre du JSON zippé et du DOM zippé, tiens
"...Changer la langue du site sans rafraîchir la page, haha tu rêves !" ---> Pourquoi ? Tu crois qu'on est obligé de recharger la page parce qu'on fait du rendu côté serveur ? (mais honnêtement, dans l'exemple, ça ne me choque pas qu'une page se recharge sur changement de langue).
"...et je pourrais continuer encore longtemps..." ---> Ah ?

Pour que ce soit clair, rendu côté serveur ça ne veut pas dire une requête ==> une page. Tu peux très bien faire une requête qui te retourne un bout de page et qui est injecté dans ton DOM côté client (avec du code javascript, oui). Et, là, le gros avantage, c'est que ton client il fait rien. Côté serveur, tu peux faire du cache sur du HTML plutôt que sur du JSON, donc tu ne fais pas le rendu à chaque fois que 1000 clients demandent la même chose. Tu le fais une fois. Avec du rendu côté client, tu le fais 1000 fois côté client...


Et désolé, mais les sites que je consulte sur PC qui sont prévus pour tablette/mobile m’horripilent... voyez le genre d'abus où ça mène : http://www.developpez.net/forums/d15...e-trouver-job/. En gros, des sites qui perdent des fonctionnalités car optimisés pour une utilisation tablette (ou alors ils pensent que les gens sont trop bêtes ). Alors, oui, on est d'accord, c'est plus une question de choix de conception que de technologies

[Marco46]

Pour que ce soit clair, rendu côté serveur ça ne veut pas dire une requête ==> une page. Tu peux très bien faire une requête qui te retourne un bout de page et qui est injecté dans ton DOM côté client (avec du code javascript, oui). Et, là, le gros avantage, c'est que ton client il fait rien. Côté serveur, tu peux faire du cache sur du HTML plutôt que sur du JSON, donc tu ne fais pas le rendu à chaque fois que 1000 clients demandent la même chose. Tu le fais une fois.

Oui certes tu peux aller chercher un morceau de page mais tu vas subir la latence du réseau + calcul du serveur si pas de cache possible sur cette requête (et sur les webapp ça va être systématique). La balance entre cette solution et simplement envoyer les data en json puis les traiter dans un SPA est laaaaargement à l'avantage de la webapp SPA. Si la plupart des grands groupes migrent mondialement sur des solutions comme AngularJS c'est pas qu'un effet de mode, c'est que la solution est plus adaptée, point final.

Avec du rendu côté client, tu le fais 1000 fois côté client...

Et donc ? Ya 1000 clients qui font chacun l'opération. Et donc où est le problème ? Ya un petit soucis de compréhension là je pense ...

[yann2]

Oui certes tu peux aller chercher un morceau de page mais tu vas subir la latence du réseau + calcul du serveur si pas de cache possible sur cette requête (et sur les webapp ça va être systématique). La balance entre cette solution et simplement envoyer les data en json puis les traiter dans un SPA est laaaaargement à l'avantage de la webapp SPA. Si la plupart des grands groupes migrent mondialement sur des solutions comme AngularJS c'est pas qu'un effet de mode, c'est que la solution est plus adaptée, point final.

C'est pareil quand tu vas chercher des donnés sur un serveur pour les rendre côté client... à moins que tu aies toutes tes données du côté du client ? Si c'est le cas, je crois qu'on ne parle pas du même type d'application. J'imagine bien twitter télécharger tous les tweets avant de commencer à afficher des choses A ce propos, twitter en est revenu (du rendu côté client)... plusieurs articles dispo sur le net et il suffit d'analyser les requêtes pour voir que le chargement d'une page retourne un objet JS qui contient le ... dom à afficher.

Et donc ? Ya 1000 clients qui font chacun l'opération. Et donc où est le problème ? Ya un petit soucis de compréhension là je pense ...

De la part de qui ?

Je précise quand même que perso, j'ai rien contre le rendu côté client, je vous signifie juste que ce n'est pas une silver bullet, hein

[goldbergg]

Je ne dis pas d'utiliser Angular à tout bout de champ, d'ailleurs je trouve beaucoup de défauts à ce framework. Mais étant spécialisé front-end, quand je vois un projet partir sur du PHP/JSP/ASP, je ne peux pas m'empêcher de lister dans ma tête tous les avantages du rendu côté client qui seront perdus ou difficilement rattrapables.
...Usage offline, on oublie.
...Compensation de latence, niet.
...Résistance aux downtime serveur, aux pertes momentanées de connexion, nada.
...Optimiser la taille des requêtes, only data on wire, nope.
...Changer la langue du site sans rafraîchir la page, haha tu rêves !
...et je pourrais continuer encore longtemps...

Je ne comprend pas très bien la remarque, on peut très bien partir sur du PHP/JSP/ASP et faire du rendu coté client (les WS REST sont très simple à mètre en place peut importe la techno).

-On peut très bien faire du Offline avec n'importe qu'elle techno coté serveur et sans utiliser aucun framework JS d'ailleurs.

-Bien avant le JS coté serveur on parlait déjà d'AJAX avec la possibilité de rafraîchir partiellement une page (genre changer la langue du site).
Des cette époque certain faisait déjà du SPA, on appelait sa des "sites en Ajax" et on arrivait déjà a faire les chose correctement avec du PHP ou de l'ASP coté serveur.
(et je ne parle pas de requête pour choper du html, mais bien de requête pour récupérer du json/xml puis de faire du bon vieux dhml comme on l'appelais à l'époque)

Bref, on peut très bien faire du js coté client en SPA et utiliser n'importe qu'elle autre techno coté serveur.
On peut même avoir une mini génération d'html coté serveur (genre les balise d’entête) puis le reste coté client.
Et SPA full JS ou pas les appel sur le réseau sont inévitable (a moins que la WebApp sois uniquement offline).

[Marco46]

C'est pareil quand tu vas chercher des donnés sur un serveur pour les rendre côté client... à moins que tu aies toutes tes données du côté du client ?

Non parce que tu as tes templates donc tu peux commencer à afficher la page. Tu peux également avoir une partie des données à afficher de disponible et donc démarrer le rendu de la page. Enfin tu peux avoir besoin de call plusieurs webservice, tu peux avoir un cache côté client sur certains webservice. Tout cela cumulé fait que tu vas rendre la page beaucoup plus vite et pour l'utilisateur cela donne au final une fluidité de navigation qui est bien meilleure.

De la part de qui ?

Je précise quand même que perso, j'ai rien contre le rendu côté client, je vous signifie juste que ce n'est pas une silver bullet, hein

Je te requote :

Avec du rendu côté client, tu le fais 1000 fois côté client...

Où est le problème ?

[Marco46]

Je ne comprend pas très bien la remarque, on peut très bien partir sur du PHP/JSP/ASP et faire du rendu coté client (les WS REST sont très simple à mètre en place peut importe la techno).

-On peut très bien faire du Offline avec n'importe qu'elle techno coté serveur et sans utiliser aucun framework JS d'ailleurs.

En effet tu peux enfoncer des clous avec un tournevis ya pas de soucis, c'est juste pas le bon outil.

-Bien avant le JS coté serveur on parlait déjà d'AJAX avec la possibilité de rafraîchir partiellement une page (genre changer la langue du site).
Des cette époque certain faisait déjà du SPA, on appelait sa des "sites en Ajax" et on arrivait déjà a faire les chose correctement avec du PHP ou de l'ASP coté serveur.
(et je ne parle pas de requête pour choper du html, mais bien de requête pour récupérer du json/xml puis de faire du bon vieux dhml comme on l'appelais à l'époque)

Bref, on peut très bien faire du js coté client en SPA et utiliser n'importe qu'elle autre techno coté serveur.
On peut même avoir une mini génération d'html coté serveur (genre les balise d’entête) puis le reste coté client.

Tu peux mais tu le feras moins bien.

Et SPA full JS ou pas les appel sur le réseau sont inévitable (a moins que la WebApp sois uniquement offline).

Oui mais tu en auras moins, ça sera beaucoup plus effiace.

[goldbergg]

Tu peux mais tu le feras moins bien.

Sa pu le troll de fanboy se genre de remarque (et paye ton argumentation qui t'évite de te décrédibiliser...), je ne vois pas en quoi sa serait forcement moins bien fait?

Dans les deux cas (full JS et Js uniquement coté client) il y a des (gros) avantage et des (gros) inconvénient.

En effet tu peux enfoncer des clous avec un tournevis ya pas de soucis, c'est juste pas le bon outil.

Au dernière news les SPA existait et fonctionnait très bien avant Node.JS et les framework MV* qui sont apparu après, donc les bon outils existait avant le JS coté serveur, ta comparaison ne tien pas la route.

[yann2]

Non parce que tu as tes templates donc tu peux commencer à afficher la page. Tu peux également avoir une partie des données à afficher de disponible et donc démarrer le rendu de la page. Enfin tu peux avoir besoin de call plusieurs webservice, tu peux avoir un cache côté client sur certains webservice. Tout cela cumulé fait que tu vas rendre la page beaucoup plus vite et pour l'utilisateur cela donne au final une fluidité de navigation qui est bien meilleure.

Il faut faire la différence entre logique et rendu. Avoir les templates côté client est une chose mais, il faut avoir les données. Donc tu me dis que si tu as une partie des données, tu peux commencer à afficher. Pas de problème, je suis d'accord. Si tu n'as pas les données, tu fais comme tout le monde, tu vas les chercher sur le serveur et tu fais le rendu côté client. Avec un rendu côté serveur, tu peux aussi faire du cache côté client. Sauf que tu caches le DOM, et un peu de données.

D'ailleurs, si tu caches uniquement les données et que tu les affiche deux dois, tu vas faire deux fois le rendu ou tu vas cacher le résultat du premier rendu (ce qui parait plus efficace, non ?) ?

Quand, il y a de la logique, si tu fais du rendu côté client, tu peux certes "simuler la logique" (pour peu que tu aies suffisamment de données sous la main) côté client et commencer à afficher en appliquant ton template mais, tu auras quand même intérêt à envoyer l'action au serveur assez vite (enfin tout dépend du problème en question) et on est bien d'accord que le rendu final peut être différent de ce que le client "à simuler". Donc dans ce cas bien précis, le rendu côté client peut être intéressant !

Je te requote :

Avec du rendu côté client, tu le fais 1000 fois côté client...

Où est le problème ?

D'un côté tu exécutes le rendu une fois sur un serveur. De l'autre tu exécutes le rendu 1000 fois sur 1000 clients. D'un côté, pour 999 clients, le rendu sera déjà prêt. De l'autre côté, pour 0 client le rendu sera prêt. Sans compter que même si les dispositifs permettant d'exécuter une webapp sont de plus en plus puissants, ce n'est pas forcément la panacée (d'ailleurs c'est une des raisons pour lesquelles twitter est revenu au server side rendering). Bref, les mobiles ont des processeurs puissants mais il faut de l'énergie pour les faire tourner (bien sûr, c'est pas un template par jour qui va les tuer )

Sources : https://blog.twitter.com/2012/improv...-on-twittercom

The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our users’ machines rather than our own.

Je me fais un peu avocat du diable, les avantages du rendu côte client sont évident, une simple recherche sur le web en donne la liste. Sauf que, comme souvent dans l'ingénierie informatique, ce n'est pas une silver bullet (et, non, il n'y a pas une migration mondiale sous angular )

[Marco46]

Sa pu le troll de fanboy se genre de remarque (et paye ton argumentation qui t'évite de te décrédibiliser...), je ne vois pas en quoi sa serait forcement moins bien fait?

Dans les deux cas (full JS et Js uniquement coté client) il y a des (gros) avantage et des (gros) inconvénient.

C'est pourtant extrêmement simple, Angular est conçu pour faire de la SPA. Il est pensé pour faire ça.

Au dernière news les SPA existait et fonctionnait très bien avant Node.JS et les framework MV* qui sont apparu après, donc les bon outils existait avant le JS coté serveur, ta comparaison ne tien pas la route.

Le rapport entre Angular et nodejs stp ? On peut savoir ?

Tu es entrain de soutenir que avant Angular il y avait des frameworks web spécialisés SPA ? Côté serveur ? C'est la blague du vendredi ?

[Marco46]

Il faut faire la différence entre logique et rendu. Avoir les templates côté client est une chose mais, il faut avoir les données. Donc tu me dis que si tu as une partie des données, tu peux commencer à afficher. Pas de problème, je suis d'accord. Si tu n'as pas les données, tu fais comme tout le monde, tu vas les chercher sur le serveur et tu fais le rendu côté client. Avec un rendu côté serveur, tu peux aussi faire du cache côté client. Sauf que tu caches le DOM, et un peu de données.

Côté client si tu n'as pas les données tu vas rendre ta vue et en parallèle tu vas requêter tes données. C'est toute la différence. D'où l'impression de fluidité pour l'utilisateur.

D'ailleurs, si tu caches uniquement les données et que tu les affiche deux dois, tu vas faire deux fois le rendu ou tu vas cacher le résultat du premier rendu (ce qui parait plus efficace, non ?) ?

Tu ne caches pas le rendu. Le rendu c'est le framework qui s'en occupe. Avec Angular par exemple tu ne dis jamais impérativement "rend moi la vue". Elle se rend toute seule.

D'un côté tu exécutes le rendu une fois sur un serveur. De l'autre tu exécutes le rendu 1000 fois sur 1000 clients.

Tu exécutes le rendu 1 fois sur 1000 clients (chaque client exécute 1 fois son rendu si tu préfères). Donc le rendu est exécuté 1000 fois au total (1 fois sur chaque client) c'est ce que tu veux dire avec 1000 fois sur 1000 clients, j'aurai pas formulé comme ça.

Et donc je réitère, où est le problème ?

D'un côté, pour 999 clients, le rendu sera déjà prêt. De l'autre côté, pour 0 client le rendu sera prêt.

J'ai beaucoup de mal à voir comment tu vas faire pour dev une webapp de gestion (cas standard) avec un cache serveur des vues ne serait-ce que d'un point de vue intégrité des données ça va être le vietnam rapidement.

Ton analyse se tient sur une webapp qui a un contenu statique qui ne change que très très peu. Alors là oui tu peux raisonnablement cacher certaines vues. Sur ce cas ok, reste la latence du réseau (importante en mobile). Mais la plupart du temps sur des webapps le contenu est dynamique et il est évolue trop rapidement pour se permettre de cacher des vues pré-interprétées. Et là le rendu côté client explose littéralement le rendu côté serveur.

[goldbergg]

C'est pourtant extrêmement simple, Angular est conçu pour faire de la SPA. Il est pensé pour faire ça.

Oui et ?
Parce que Angular est un bon framework SPA, tous le reste c'est forcement de la grosse merde???

Et sinon juste comme sa Angular coté client + ASP.Net coté serveur, c'est de la demi merde? (car c'est de se genre d'usage d'on je parle)

Le rapport entre Angular et nodejs stp ? On peut savoir ?

Tu es entrain de soutenir que avant Angular il y avait des frameworks web spécialisés SPA ? Côté serveur ? C'est la blague du vendredi ?

Je parle que les techno serveur autre que Node.JS (vue que l'on associe souvent Angular a node pour la partie serveur, parce que oui même les SPA on généralement une partie serveur) peuvent très bien être utilisé pour faire du SPA, POUR LA PARTIE WS, bien évidement que coté client on a du js qui tourne, sinon c'est pas du SPA.

Et je dit aussi que bien avant Node.Js, Angular & cie, on faisait déjà des site SPA (que l'on nommait autrement) et que sa fonctionnait très bien, et oui tu lit bien, sans utilisation de angular ou autre framework a la mode de nos jour.

persso je fait du SPA depuis des année, aux début avec PHP, puis par la suite via ASP.Net Web Api qui sert principalement à sa.
Alors oui il n'y avait pas de framework déjà tous fait pour nous mâcher le travaille, mais sa ne nous empêchais pas de coder des framework maison qui faisait très bien leurs taff, il n'y a pas que chez angular que l'on trouve des bon dev.
On peut faire des site SPA de bien des façon et sa n'est pas parce que la technique utilisé n'est pas celle d'angular que c'est mal foutu ou je ne sais trop quoi!

J'ai l'impression que tu confonds "faire un site SPA" (qui au final se résume à pas grand chose) et "faire un site MVVM SPA" se qui n'est pas la même chose...

[SylvainPV]

Je ne comprend pas très bien la remarque, on peut très bien partir sur du PHP/JSP/ASP et faire du rendu coté client (les WS REST sont très simple à mètre en place peut importe la techno).

-On peut très bien faire du Offline avec n'importe qu'elle techno coté serveur et sans utiliser aucun framework JS d'ailleurs.

-Bien avant le JS coté serveur on parlait déjà d'AJAX avec la possibilité de rafraîchir partiellement une page (genre changer la langue du site).
Des cette époque certain faisait déjà du SPA, on appelait sa des "sites en Ajax" et on arrivait déjà a faire les chose correctement avec du PHP ou de l'ASP coté serveur.
(et je ne parle pas de requête pour choper du html, mais bien de requête pour récupérer du json/xml puis de faire du bon vieux dhml comme on l'appelais à l'époque)

Bref, on peut très bien faire du js coté client en SPA et utiliser n'importe qu'elle autre techno coté serveur.
On peut même avoir une mini génération d'html coté serveur (genre les balise d’entête) puis le reste coté client.
Et SPA full JS ou pas les appel sur le réseau sont inévitable (a moins que la WebApp sois uniquement offline).

Du offline avec du rendu côté serveur ? Par offline, j'entends la possibilité de naviguer et d'interagir avec le site sans connexion Internet, et non simplement garder en cache une page statique. Sinon control+S fait tout aussi bien. Je ne vois pas comment ce genre de choses est possible si la gestion des vues est faite côté serveur.

Le principe de base de ces "SPA full JS" (il faut vraiment qu'on trouve une appellation pour ça), c'est de découpler complètement application et données et de faire gérer le tout côté client. On a d'un côté le bundle applicatif avec les vues et leur logique, stockées dans l'applicationCache (ou sur un service worker pour les protos plus récents), et de l'autre les données stockées en localStorage ou IndexedDB. C'est ça la clé qui permet de faire tout ce que j'ai décrit dans mon post précédent.

Pour donner un exemple concret: les blogs sont pour la plupart codés en PHP aujourd'hui. J'ai bossé sur un système de blog full client-side qui permettait les choses suivantes:
- prévisualiser l'affichage d'un billet sans requête serveur
- précharger en différé les différents billets pour les afficher plus vite ou hors connexion
- naviguer sur le blog et lire les articles sans connexion
- écrire des articles ou des commentaires sans connexion ; à la reprise de la connexion, dans la même session ou des jours après, le tout est synchronisé avec le serveur

Tout ceci implique que les vues soient gérées et composées à la volée en JavaScript. Alors, certes, on pourrait générer exactement les mêmes vues en PHP en laissant le fonctionnel JS à l'identique. Mais à quoi bon ? ça ne ferait que dupliquer la logique de gestion des vues et cela n'apporterait rien, à part plus de code à maintenir, et un risque de divergence entre le fonctionnement du code serveur et du code client.

D'un côté tu exécutes le rendu une fois sur un serveur. De l'autre tu exécutes le rendu 1000 fois sur 1000 clients. D'un côté, pour 999 clients, le rendu sera déjà prêt. De l'autre côté, pour 0 client le rendu sera prêt.

C'est une vulgarisation bien éloignée de la réalité. On parle ici de contenu dynamique, mais dynamique par rapport à quoi ? Dans la majorité des cas, il variera selon les utilisateurs. Donc tes 1000 clients auront 1000 rendus différents. Et la précompilation des templates serveur existe aussi pour les templates client, donc l'argument ne tient pas.