Personnellement je trouve la logique d'Angular tout à fait pertinente : pourquoi le serveur devrait s'occuper d'autre chose que du traitement des données
? Tout le reste peut être fait coté client (sauf peut être besoin et applications spécifiques), décharger le serveur et donner un rendu fluide et sans
rechargements inutiles.
C'est une logique qui a tout son intérêt dans certains cas, et pas dans d'autres.
Je ne comprends pas pourquoi on veut absolument utiliser un truc comme Angular pour faire un blog ou un site à contenu, où l'unité d'organisation reste la page et où les éléments dynamiques sont plutôt rares.
C'est pas parce qu'on a un super framework très très bien conçu développé par une société comme Google qu'il est nécessairement pertinent à toutes les sauces.
L'erreur, comme dirait cet autre, c'est que quand on a un marteau doré, tout ressemble à un clou.
Angular tout comme les autres frameworks du genre comme Meteor, React, etc. ont été conçus pour les applications à page unique (single page application). AVant de l'utiliser pour un projet, je pense qu'il faudrait se poser les questions suivantes:
est-ce que mon projet ressemble plus à une SPA ou à un site web traditionel ?
Est-ce que mon application aurait toujours autant d'intérêt si, à la place d'une application web, c'était une application native desktop ou mobile ?
est-ce que la notion de hautement dynamique ou de temps réel a une importance capitale ?
Est-ce que, à défaut de temps réel ou de aute dynamicité à proprement parler, les notions traditionellement attachées aux apps natives, telles par exemple que les boîtes de dialogue et les interaction dans celles-ci font-elles véritablement sens dans mon cas (et ne sont pas uniquement une question esthétique) ?
Clairement pour un blog, un journal, une encyclopédie ou un shop en ligne, les réponses à ces questions pour moi sont non (n'en déplaise à ceux qui font des apps natives qui sont juste des copies de leur site web). Par contre pour un jeu, un chat, un client mail, un système pour éditer/produire du contenu collaborativement, pour regarder la télé en direct ou pour télécommander un drone, définitivement oui.
Pour ces dernières, il n'y a pas de problème à envoyer bouler le client qui n'est pas à jour, parce que de toute façon il n'y a pas vraiment d'alternative. Pour les premières par contre je trouve ça particulièrement dommage.
Décharger le serveur, c'est une fausse excuse. De toute façon le 99% du temps, on le passe à requêter la base de donnée ou des API externes, et faire des vérifications qu'on ne peut de toute façon pas contourner (p.ex. formulaires, droits d'accès). Générer la réponse ça ne coûte rien; qu'on sorte du JSON ou du HTML c'est à peu près pareil.
Du coup qu'on fasse une SPA ou un site classique en PHP, je suis à peu près sûr que la différence n'est pas flagrante.
Par exemple, une question symptômatique: quel est l'intérêt d'effacer la majeure partie du contenu pour en recharger un tout autre avec AJAX ?
Mème s'il y a un système de template en js qui est super bien foutu et qui essaie de minimiser les modifications du DOM, je ne pige pas trop. Sauf pour les très très gros poissons, c'est pas quelques Ko de plus qui vont tuer le serveur.
Je n'arrive pas à comprendre comment on peut en arriver à ce que, quand je vais sur certains sites de presse (que je ne citerai pas) par exemple, le CPU monte à pas loin de 100%. Juste pour, normalement, du texte et quelques illustrations immobiles.
Pour un jeu 3D qui tourne à 60 FPS c'est normal, mais pas pour un article !
Quant à la question de départ, je n'ai jamais vraiment travaillé avec Angular donc je ne sais pas; mais avec Meteor on a droit à une page blanche ou au mieux un message basique. Je suppose que c'est pareil avec Angular.
