Le problème du rendu côté client vient du fait qu'on balance des montagnes de données au client car les dévs front :
- pensent que coder avec un framework c'est plus simple (si on fait tout le temps le même type de projets qui se ressemblent énormément oui, si c'est pour un projet unique non) ;
- ont des contraintes techniques que leur manager (ou le client) leur impose ("On a pris React parce que tout le monde utilise ça, donc c'est forcément bien, c'est l'état de l'art" ou "Parce que ça a été développé par Meta donc c'est robuste") ;
- parce qu'ils s'en foutent que ton navigateur doive digérer 500 Ko ou 50 Mo de données ; passer de 50 Mo à 30 Mo pourquoi pas si ça leur prend pas trop de temps, mais faudrait pas non plus passer trop de temps à faire les choses bien (par flemme ou à cause de la pression du projet).
Si maintenant on fait du rendu côté serveur, on va se retrouver avec des dizaines de milliers de paquets npm lourdingues sur le serveur (spoiler : c'est déjà le cas), ce qui implique de mettre plus de serveurs pour absorber la charge avec tous les problèmes que ça comporte (ce qui fait pas mal de boulot en plus pour la maintenance), mais surtout ça ne va strictement rien changer à ce qu'on envoie au client. J'ai passé assez de temps dans l'écosystème webdev pour savoir qu'on continuera à balancer des dizaines de Mo au client parce que "on se prend moins la tête" et que ça n'a rien à voir avec le fait de faire du rendu côté client ou serveur.
Remarque en passant : j'ai l'impression que tous les 10 ans on revient à ce qui était fait 20 ans plus tôt en nous présentant ça comme la solution à tous nos problèmes pour ne pas travailler sur le problème de fond qui est que si on veut faire un truc performant et bien fait, ça demande du temps et du travail et qu'aucun framework ne viendra faire ça à notre place.
[^] # Re: \o/
Posté par cluxter . En réponse à la dépêche Cent mille dollars pour un navigateur. Évalué à 8.
Le problème du rendu côté client vient du fait qu'on balance des montagnes de données au client car les dévs front :
- pensent que coder avec un framework c'est plus simple (si on fait tout le temps le même type de projets qui se ressemblent énormément oui, si c'est pour un projet unique non) ;
- ont des contraintes techniques que leur manager (ou le client) leur impose ("On a pris React parce que tout le monde utilise ça, donc c'est forcément bien, c'est l'état de l'art" ou "Parce que ça a été développé par Meta donc c'est robuste") ;
- parce qu'ils s'en foutent que ton navigateur doive digérer 500 Ko ou 50 Mo de données ; passer de 50 Mo à 30 Mo pourquoi pas si ça leur prend pas trop de temps, mais faudrait pas non plus passer trop de temps à faire les choses bien (par flemme ou à cause de la pression du projet).
Si maintenant on fait du rendu côté serveur, on va se retrouver avec des dizaines de milliers de paquets npm lourdingues sur le serveur (spoiler : c'est déjà le cas), ce qui implique de mettre plus de serveurs pour absorber la charge avec tous les problèmes que ça comporte (ce qui fait pas mal de boulot en plus pour la maintenance), mais surtout ça ne va strictement rien changer à ce qu'on envoie au client. J'ai passé assez de temps dans l'écosystème webdev pour savoir qu'on continuera à balancer des dizaines de Mo au client parce que "on se prend moins la tête" et que ça n'a rien à voir avec le fait de faire du rendu côté client ou serveur.
Remarque en passant : j'ai l'impression que tous les 10 ans on revient à ce qui était fait 20 ans plus tôt en nous présentant ça comme la solution à tous nos problèmes pour ne pas travailler sur le problème de fond qui est que si on veut faire un truc performant et bien fait, ça demande du temps et du travail et qu'aucun framework ne viendra faire ça à notre place.