Discussion :

[sekaijin]

Bonjour.

Lorsque je développe en C++ pour mes applications, je crée des fenêtres, des boutons des grilles et tout un tas d'autres objets à l'écran.
Je crée des contrôleurs des modèles des façades, etc.

Et je fais confiance à mon framework pour utiliser la méthode optimale pour dessiner la fenêtre le bouton ou je ne sais quoi d'autre.

Lorsque je fais une application web, je crée des panels, des boutons des grilles et tout un tas d'autres objets à l'écran.
Je crée des contrôleurs des modèles des façades, etc.

Et je (ne) fais (pas trop) confiance à mon framework pour utiliser la méthode optimale pour dessiner le panel, le bouton ou je ne sais quoi d'autre.
En fait le framework que j'utilise aujourd'hui le fait plutôt pas mal. Le rendu est plutôt bon en tout cas il correspond au STD de ma boite. Par contre si on met ne nez dans le cambouis on constate vite que le HTML généré n'est pas des meilleurs. Du point de vue Dev ça n'a aucune importance vu qu'on manipule des panels de boutons de grilles, etc. et pas de table de div ou tout autre objet du DOM.
Bref on se retrouve exactement comme en C++, on créé une fenêtre et on la manipule sans savoir s'il a utilisé un objet rectangle ou 4 droites. Dans mon cas je créer un panel et je manipule le panel. Si le framework décide de créer des tables dans des tables parce qu'il s’exécute sur un vieux navigateur et qu'il crée des div dans les navigateurs modernes, je ne le vois pas.

Mais arrive un moment où la taille de l'application impose de se poser la question de la charge (réseau, mémoire, cpu) et là effectivement le framework que j'utilise n'est pas très optimal. Bien au contraire.

Du coup j’évalue d'autres frameworks.

Je viens de passer beaucoup de temps dessus Angular et j'ai l'impression de revenir en arrière. Question structuration rien à redire, mais question wdget c'est le désert. Pour le moindre affichage, il faut replonger dans le cambouis. Ça me rappelle les débuts de la programmation graphique ou il fallait tout dessiner.
Il y a bien les directives, mais quel intérêt.

Aujourd'hui j'écris un json qui décrit mon widget (liste d’attributs, taille, resisable, présence de menu contextuel, etc.) et le framework produit une HTML le représentant.
Tout comme avec Angular mon contrôleur le prend en charge et s'occupe de toute question communication entre la vue et le contrôleur.

Avec Angular j'ai l'impression que je dois soit écrire moi même le HTML. Dans une production industrielle, on ne fignole pas chaque grille. On instancie une grille générique qu'on paramètre. Du coup pour les quelques centaines de grilles de mes applications je devais écrire le HTML cela reviendrait à faire du copier-coller.Soi j'utilise des directives. Dans ce cas j'écris du HTML qui va être remplacé par un autre.

J'avoue ne pas comprendre l'utilité d'un tel procédé. Pourquoi ne pas créer directement ce dont on a besoin ?

Si je regarde la taille de mes applications et la richesse actuelle de mes interfaces, la méthode de travail d'Angular me semble désastreuse. Il me faudrait des centaines de jours juste pour l'affichage. Avec tous les risques d'erreurs que cela implique.

Il y a un autre point qui m'a surpris.
Dans mes développements l'application cliente (js) s'occupe de l'affichage de fonction simple et de traitements locaux. Le serveur lui se charge des traitements lourds et de la persistance. Du coup lorsque je développe la partie cliente je ne présume en rien de ce que va faire des données le serveur et j'invoque une API de service. Ce qui me semble être une bonne chose et que je retrouve un peu partout dans les boites que je connais.
Du coup lorsque j'ai lu à mainte reprise la préconisation que lorsqu'on utilise Angular il ne faut déléguer au serveur que Select Insert Update et Delete et que tout le reste était pris en charge par Angular. J’ai fait un bon. J'imagine mal réécrire une application qui fait appel au service "Consolider les comptes de l'ensemble du groupe au niveau planétaire pour la période écoulée" en effet je vois mal dans cette invocation de Select Insert Update ou Delete. Où alors on charge les téraoctets de données financières dans le navigateur. Soyons sérieux. Il est évident que Angular n'impose pas une telle contrainte. Mais du coup j'ai cherché à en savoir plus. Pourquoi une telle préconisation est présente dans tant de tutoriels sur Angular ? La réponse m'est assez vite apparue. La très grosse majorité des exemples ou des tutoriels tourne autour d'un CRUD qu'il faut persister. Or cela représente une infime partie des activités de mes applications.

Je ne suis donc pas très convaincu. De ce que j'ai vu ce que fait Angular il le fait bien. Très bien même.
Mais je ne pense pas qu'il soit adapté à mon besoin.
Production industrialisée d'application standardisée toute la même ergonomie toutes les mêmes widgets, proposant des IHM permettant d'invoquer des API de service sur le SI.

A+JYT

[Marco46]

Je viens de passer beaucoup de temps dessus Angular et j'ai l'impression de revenir en arrière. Question structuration rien à redire, mais question wdget c'est le désert. Pour le moindre affichage, il faut replonger dans le cambouis. Ça me rappelle les débuts de la programmation graphique ou il fallait tout dessiner.

C'est normal, puisque Angular est un framework javascript. Ce n'est pas son rôle de gérer le design de tes pages. Pour ça utilise un framework CSS (bootstrap, foundation, ...)
Angular va structurer tes pages en manipulant le DOM pour toi via les directives natives du framework (ng-if, ng-switch, ng-repeat, etc ...) mais pas le CSS. Il donne des directives permettant de faciliter l'usage des CSS (ng-class, ng-show / ng-hide) mais ne contient rien en natif pour le design, et c'est normal c'est le job d'un framework CSS.

Il y a bien les directives, mais quel intérêt.

Aujourd'hui j'écris un json qui décrit mon widget (liste d’attributs, taille, resisable, présence de menu contextuel, etc.) et le framework produit une HTML le représentant.
Tout comme avec Angular mon contrôleur le prend en charge et s'occupe de toute question communication entre la vue et le contrôleur.

Avec Angular j'ai l'impression que je dois soit écrire moi même le HTML. Dans une production industrielle, on ne fignole pas chaque grille. On instancie une grille générique qu'on paramètre. Du coup pour les quelques centaines de grilles de mes applications je devais écrire le HTML cela reviendrait à faire du copier-coller.Soi j'utilise des directives. Dans ce cas j'écris du HTML qui va être remplacé par un autre.

J'avoue ne pas comprendre l'utilité d'un tel procédé. Pourquoi ne pas créer directement ce dont on a besoin ?

Quel intérêt ? C'est un peu comme si tu venais de découvrir la programmation et que tu te demandais quel est l'intérêt des méthodes.

Une directive c'est un moyen d'enrichir le HTML. Tu crées des balises HTML qui sont un assemblage d'autres balises HTML. C'est un prequel des webcomponents si tu préfères.

Cela permet de créer des widgets réutilisables et donc de gagner un temps fou. Et c'est là où Angular combiné à un framework CSS (par exemple Bootstrap) via une librairie qui va angulariser le framework (angular-ui pour bootstrap) déploie toute sa puissance : Tu obtiens exactement ce que tu expliques ne pas trouver dans Angular.

Si je regarde la taille de mes applications et la richesse actuelle de mes interfaces, la méthode de travail d'Angular me semble désastreuse. Il me faudrait des centaines de jours juste pour l'affichage. Avec tous les risques d'erreurs que cela implique.

Oui c'est comme si tu écrivais un client lourd en J2SE sans utiliser de librairie graphique et que tu te plaignais que c'est désastreux d'écrire des IHM avec Java.

Il y a un autre point qui m'a surpris.
Dans mes développements l'application cliente (js) s'occupe de l'affichage de fonction simple et de traitements locaux. Le serveur lui se charge des traitements lourds et de la persistance. Du coup lorsque je développe la partie cliente je ne présume en rien de ce que va faire des données le serveur et j'invoque une API de service. Ce qui me semble être une bonne chose et que je retrouve un peu partout dans les boites que je connais.
Du coup lorsque j'ai lu à mainte reprise la préconisation que lorsqu'on utilise Angular il ne faut déléguer au serveur que Select Insert Update et Delete et que tout le reste était pris en charge par Angular. J’ai fait un bon. J'imagine mal réécrire une application qui fait appel au service "Consolider les comptes de l'ensemble du groupe au niveau planétaire pour la période écoulée" en effet je vois mal dans cette invocation de Select Insert Update ou Delete. Où alors on charge les téraoctets de données financières dans le navigateur. Soyons sérieux. Il est évident que Angular n'impose pas une telle contrainte. Mais du coup j'ai cherché à en savoir plus. Pourquoi une telle préconisation est présente dans tant de tutoriels sur Angular ? La réponse m'est assez vite apparue. La très grosse majorité des exemples ou des tutoriels tourne autour d'un CRUD qu'il faut persister. Or cela représente une infime partie des activités de mes applications.

Cette question dépasse Angular. Il s'agit simplement de savoir quelles responsabilités donner à son client léger dans un contexte SPA (Single Page Application) javascript couplé à des webservices.

Je ne me souviens pas avoir lu dans un quelconque tutoriel Angular qu'il était interdit d'avoir des webservices qui ont un rôle métiers qui sort du contexte du CRUD. Ca serait complètement aberrant et ce n'est même pas dans le scope d'Angular, il s'agit d'un problème d'architecture beaucoup plus général, tenant compte de toute la stack technique.

Dans toute application métier on a besoin d'avoir des traitements algorithmiques plus ou moins complexes.
Si ces traitements ne sont pas critiques et n'ont pas besoin de plus d'information qu'il est possible d'avoir dans son client léger alors il est intéressant de déléguer cette responsabilité au client parce que ça fait ça de moins à traiter sur le serveur.

Par exemple dans une gestion commerciale, il est hors de question de gérer la transformation d'un bon de commande en facture dans la couche front. On va gérer ça dans un webservice sur la partie serveur de la stack.
En revanche la création d'une proformat pourquoi pas ?

J'ai même envie de dire que le problème est identique si tu dois proposer les mêmes fonctionnalités sur une application client lourd sur mobile. Une webapp, faites avec Angular ou un autre framework js, aura les mêmes problématiques sur ce point que n'importe quelle application client / serveur. La question étant qu'est ce que j'exécute côté client, qu'est ce que j'exécute côté serveur.

La nouveauté avec les framework js spécialisés sur les SPA c'est qu'ils ouvrent la possibilité de développer des frontend aussi riche que des clients lourds classiques mais sur le web. Et donc avec le responsive design on peut avoir un frontal unique sur tous les périphériques.
Parallèlement à ça, la conception en SPA au lieu d'un templating côté serveur permet une amélioration très significative des performances aussi bien côté client que côté serveur.

Je ne suis donc pas très convaincu. De ce que j'ai vu ce que fait Angular il le fait bien. Très bien même.

Je ne sais pas combien de temps tu as passé sur Angular mais il faut vraiment du temps avant de maitriser la bête, un POC ne suffit pas.

Mais je ne pense pas qu'il soit adapté à mon besoin.
Production industrialisée d'application standardisée toute la même ergonomie toutes les mêmes widgets, proposant des IHM permettant d'invoquer des API de service sur le SI.

Au contraire, Angular est le choix parfait pour toute webapp de type pro qui va attaquer les webservices de n'importe quel SI. C'est à l'heure actuelle l'un des meilleurs choix si ce n'est le meilleur.

Ton problème à ce que je comprends c'est que tu n'as pas exploité tous les outils à ta disposition. Angular seul ne suffit pas, il y a une foule de modules à utiliser (ui-router en est un exemple parfait).

EDIT : Pour bénéficier pleinement des techniques modernes de dev de webapp, il est vraiment nécessaire d'utiliser des outils comme npm, bower, grunt/gulp et un EDI de bonne qualité comme Webstorm. Ca fait beaucoup de choses à apprendre mais on passe clairement dans une autre dimension.

[sekaijin]

Ta conclusion est exactement ce qui me fait penser qu'Angular ne correspond pas à mon besoin.

Aujourd'hui je dis à mon framework que je veux une grille triable localement, paginée et qui occupe tout l'espace de mon panel. Je définis un contrôler en lui donnant comme référence la vue en question, le modèle et j'api qu'accès aux données. Je n'ai pas de manipulation de DOM à faire ou faire faire, je n'ai pas de CSS à bricoler, je n'ai pas de binding à définir je n'ai pas d'injection de donnée à faire. J’exécute et le framework me produit seul l'IHM va invoquer le service et placer les donner dans la grille.

donc si je veux une grille de donnée je demande au framework une grille de donnée
Je ne crée pas un HTML que je tag pour qu'un truc vienne le modifier, je ne fais pas de cs pour le mettre en forme, etc. et tu résumes bien ce que j'ai senti. Là où un outil dans un seul langage prenait en charge la totalité de la mise en oeuvre de mon besoin, je dois si je choisit Angular prendre une multitude d'outils que je dois faire travailler de concert dans plusieurs langages et faisant moi même plus de choses pour arriver à un résultat similaire.

Quant à la question de l'intérêt ce n'est pas l'intérêt des frameworks dont je parle. J'ai commencé à faire du génie logiciel à une époque où on inventait à peine le mot. J’ai moi-même écrit un framework MVC pour un langage qui n'en avait pas.
Si je veux une roue, je fabrique une roue ou je demande à une fabrique de roues de m'en faire une.
Mais je ne vois aucun intérêt à fabriquer un cube et demander à une "directive" de transformer mon cube en roue.

pourtant c'est ce que propose JQuery ou Angular au travers des directives, etc.
Je dois écrire un HTML qui ne sera pas celui qui sera utilisé par l'application, mais qui sera transformé en autre chose.

Aujourd'hui avec mon framework j'ai une fabrique d'IHM qui produit les IHM que je veux à partir de composants aux capacités complexes et intégrés (prêt à l'emploi)

Si je choisis Angular, je n'ai plus de Fabrique d'IHM (ma fabrique de roues)
J'ai donc le choix entre, faire les choses avec d'autres outils (pour faire moi-même ma roue)
Et/Ou produire du HTML (un cube) et utiliser des directives (qui transforme les cubes en roues)


C'est donc, même si comme tu le dis d'autres outils sont là pour y aider, du boulot que je ne fais pas et que je devrais faire.

Je ne sais pas trop si on peut parler de modernisme. J’ai au contraire l'impression de revenir avec Angular à ma façon de travailler d'il y a 10 ans.

Je parle bien d'un Framework JavaScript. Aujourd'hui l'activité principale pour développer dans mon framework JavaScript consiste à définir des modèles de donner spécifier les services qui leur sont attachés et décrire dans quel type de widget il s'affiche. Et c'est tout. Tout cela s'écrit en JavaScript essentiellement sous forme de JSON. Et tout cela se fait en implémentant des designs patterns modernes.

Je trouve que passer d'un framework tout intégré qui réponds à mes besoins à très peut de coût, mais qui produit un HTML pas très propre à un ensemble d'outils qu'il faut maintenir cohérents, qui implique plus de travail, sans la garantie que je retrouverais la richesse de mes IHM, mais dont je suis à peut prêt sur que le HTML est plus propre n'est pas à proprement parler de nature à me convaincre de faire le pas.

J'ai beaucoup de mal à comprendre pourquoi, faire un truc qu'on ne veut pas obtenir pour le transformer en ce que l'on veut est mieux plus moderne, et plus efficace que de faire directement ce dont on a besoin.

Pourtant cette méthode est des plus populaire.

A+JYT

[Marco46]

Donc en fait si j'ai bien compris, tu as déjà écrit un framework javascript qui est focus sur ton besoin spécifique ?

Ta conclusion est exactement ce qui me fait penser qu'Angular ne correspond pas à mon besoin.

Si ton besoin est spécifique à un domaine métier précis, Angular ne peut pas correspondre à ton besoin puisqu'il est généraliste. Mais tu ne trouveras jamais aucun framework qui remplira mieux ton besoin que celui que tu as développé.

J'ai beaucoup de mal à te suivre, c'est quoi ton besoin au juste ? Si c'est d'écrire des webapp SPA en frontend d'une archi SOA avec les widgets standards (formulaires, grid, etc ...) tu ne trouveras rien de mieux qu'Angular.

Si ton framework est plus efficace pourquoi ne pas le publier ?

[danielhagnoul]

https://www.sencha.com/products/extjs/#overview c'est beau, mais pour un "petit" c'est cher

[sekaijin]

... Si c'est d'écrire des webapp SPA en frontend d'une archi SOA avec les widgets standards (formulaires, grid, etc ...)

C'est exactement mon besoin. écrire rapidement beaucoup de SPA ayant toute la même ergonomie et apparence en frontend d'une archi SOA.

j'utilise un framework du marché qui rempli le job. mais il a un défaut celui de produire des SPA un peut trop lourdes.
Je regarde donc ailleurs. et parmi cet ailleurs il y a Angular.
Des gens comme toi disent

... tu ne trouveras rien de mieux qu'Angular.

Cela attise donc ma Curiosité. et je constate qu'Angular ne fait qu'une partie du job, qu toute une autre partie qui est assurée par le framework que j'utilise doit être faite avec d'autres outil.

j'en conclus que choisir Angular
c'est passer d'une solution Intégrée (qui prend tout en charge)
demandant peut de développements
à une solution désintégrée (Angular ne fait qu'une partie et il faut lui adjoindre d'autres outils)
et qui demande plus de développements.

ça fait cher pour gagner quelques Ko sur le navigateur des clients.

Pour te donner une idée afficher une grilles avec menu contextuel, tri à distance, filtre, pagination, choix des colonnes visibles, etc (bref tous ce que tu rêve d'avoir en terme d'ergonomie dans une grille de donnée) dans les règles de l'art SPA multicouche pattern observateur observable pattern MVC etc. C'est 1279 octets de javascript à produire 0 HTML 0 CSS 0 image à produire. seul outil à maîtriser Avec une approche descriptive en JSON pour chaque couche.
cela représente très peux de travail à développer.

J'ai bien retrouvé les partie Model Contrôleur dans Angular mais pas la vue.
et effectivement il faut aller chercher ça ailleurs.

là ou en terme de développement pour une vue j'écris en json que je veux une grille en listant les options et je ne me préoccupe de rien
Je dois avec Angular écrire un HTML savoir comment il sera transformé par les divers outils mis en oeuvre Car Angular le lier au DOM produit et non à la Grille que je veux manipuler.

Soit je n'ai pas trouvé dans l'écosystème l'outils qui me permets de m'abstenir de redescendre dans le cambouis. qui me permet de juste dire que je veux une grille et qui se débrouille. Au quel cas ça pourrait me convaincre.
Soit comme je le pense ce n'est pas la philosophie de la chose et le coût est pour moi trop défavorable.

Je précise tout de même que de tout ce que j'ai testé Angular dans ce qu'il sais faire est celui qui m'a le plus convaincu. Reste ce qu'il ne sais pas faire ou que je ne sais pas comment il le fait.
A+JYT

[Marco46]

C'est exactement mon besoin. écrire rapidement beaucoup de SPA ayant toute la même ergonomie et apparence en frontend d'une archi SOA.

j'utilise un framework du marché qui rempli le job. mais il a un défaut celui de produire des SPA un peut trop lourdes.
Je regarde donc ailleurs. et parmi cet ailleurs il y a Angular.
Des gens comme toi disent Cela attise donc ma Curiosité. et je constate qu'Angular ne fait qu'une partie du job, qu toute une autre partie qui est assurée par le framework que j'utilise doit être faite avec d'autres outil.

j'en conclus que choisir Angular
c'est passer d'une solution Intégrée (qui prend tout en charge)
demandant peut de développements
à une solution désintégrée (Angular ne fait qu'une partie et il faut lui adjoindre d'autres outils)
et qui demande plus de développements.

ça fait cher pour gagner quelques Ko sur le navigateur des clients.

Si on parle de Sencha alors il ne s'agit pas que de gagner quelques ko. Si j'en crois ce test Sencha ne sait pas :
- gérer l'IoC nativement
- gérer les TU
- gérer le responsive design avec le même code

Ca fait des défauts assez lourds quand même.

Mais est plus riche qu'Angular (même en incluant angular-ui) en terme d'IHM.

Mais Sencha coute 1000 euros par version là où Angular est gratuit.

Pour te donner une idée afficher une grilles avec menu contextuel, tri à distance, filtre, pagination, choix des colonnes visibles, etc (bref tous ce que tu rêve d'avoir en terme d'ergonomie dans une grille de donnée) dans les règles de l'art SPA multicouche pattern observateur observable pattern MVC etc. C'est 1279 octets de javascript à produire 0 HTML 0 CSS 0 image à produire. seul outil à maîtriser Avec une approche descriptive en JSON pour chaque couche.
cela représente très peux de travail à développer.

J'ai bien retrouvé les partie Model Contrôleur dans Angular mais pas la vue.
et effectivement il faut aller chercher ça ailleurs.

là ou en terme de développement pour une vue j'écris en json que je veux une grille en listant les options et je ne me préoccupe de rien
Je dois avec Angular écrire un HTML savoir comment il sera transformé par les divers outils mis en oeuvre Car Angular le lier au DOM produit et non à la Grille que je veux manipuler.

Disons que pour faire court, il y a un travail perso à faire "on the top" de angular-ui pour avoir ta lib de composants similaire à Sencha. Mais tu ne le feras qu'une seule fois.

Soit je n'ai pas trouvé dans l'écosystème l'outils qui me permets de m'abstenir de redescendre dans le cambouis. qui me permet de juste dire que je veux une grille et qui se débrouille. Au quel cas ça pourrait me convaincre.
Soit comme je le pense ce n'est pas la philosophie de la chose et le coût est pour moi trop défavorable.

Ben c'est de l'opensource. Personne n'est descendu aussi bas dans le besoin parce que c'est à chacun de gérer ses composants graphiques à ce niveau de détail là.

Après si ta cible est uniquement en desktop peut être que Sencha est un meilleur choix si t'as les moyens mais c'est toujours dangereux d'avoir une adhérence forte avec du propriétaire, surtout dans le web. Ca aussi c'est un gros défaut de Sencha.

[sekaijin]

Effectivement que du desktop
et entièrement d'accord avec toi pour les Test Unitaire c'est fastidieux avec Sencha
Par contre Sencha gère bienl'IoC

Tu as bien résumé le pourquoi je regarde ce qu'il se fait ailleurs

[SylvainPV]

Si je résume, tu as testé AngularJS comme une alternative à ExtJS (que tu chéris énormément, on commence à le savoir ). Seulement voilà, les deux n'ont rien à voir ! A la rigueur, on pourrait imaginer qu'une version de ExtJS utilise AngularJS en interne, un peu comme le projet angular-kendo mixe Angular et Kendo UI. Mais s'attendre à un framework UI clé en main en testant AngularJS, c'est se gourer de rayon au supermarché.

[sekaijin]

Non je ne chéri pas ExtJS je lui trouve plein de défauts. bien plus que beaucoup de gens. peut être parce que je le connais bien.

Du coup effectivement je cherche une alternative.
Et Angular.js ne ma pas convaincu pour servir de base à cette alternative.

Je suis très pragmatique et si Angular.js m'est apparu comme un très bon outil sur une partie de ma problématique l’approche proposé pour pour la partie UI elle m'est apparue contre productive, coûteuse, et pas adapté à mon besoin. c'est en ce sens que je ne suis pas convaincu.

A+JYT

[danielhagnoul]

@sekaijin : tu as déjà testé cet UI ? http://www.telerik.com/kendo-ui/open-source-core

Je ne le connais pas encore, mais...

EDIT : trop cher pour moi.

[sekaijin]

J'ai pas regardé plus car pour moi aussi

A+JYT

[adaptable_aniforme]

Personnellement , je ne vois pas pourquoi j'aurai besoin d'utiliser un framework client MVC comme AngularJS ou Backbone.

Dans mon travail, j'utilise déjà un framework MVC serveur(symfony2) et dans quasiment 90% des projets sur lesquels j'ai travaillé, il y a beaucoup plus de traitements en back qu'en front car ce sont souvent des applications de gestion:
1- Je crée le modèle avec Doctrine , le contrôleur avec PHP , et la vue avec TWIG
2- Ensuite dans ma vue , j'affiche juste les données , faire de calculs dans le DOM et envoyer les résultats à un autre contrôleur qui va utiliser des websockets pour ré-afficher en tant réel d'autres données dans ma vue TWIG
3- Et après j'utilise ensuite JQuery ou javascript pur pour placer les données issues du contrôleur symfony à gauche ou à droite de ma page TWIG. Et tous çà de façon sécurisée car le contrôle se fait sur le serveur(php) et non pas javascript(client).

Donc , je ne vois pas pourquoi devrais-je m'embêter à utiliser le model-vue-contrôleur d'AngularJS pour juste afficher les données dans ma vue TWIG qui sont déjà récupérées et bien contrôlées depuis le back de l'appli , parce qu'à force de croire à votre philosophie absurde , je dois m'efforcer de refaire le travail 2 fois:
- d'abord, un model-contrôleur-vue depuis mon symfony2 qui est déjà assez sécurisée et bien fait
- et ensuite un model-contrôleur-vue depuis angularJS qui n'est pas assez sécurisée(car côté client) et qui ne sert finalement pas à grand chose

Pour moi, ces frameworks soient disant en vogue(AngularJS, Backbone, etc) ne sont juste que de la pure publicité de leurs créateurs et qu'ils ont été créés juste pour voler vos données.

A moins de ne travailler exclusivement que sur du SPA, je ne vois pas pourquoi on devrait s'embêter avec AngularJS à refaire une deuxième fois dans le front un travail déjà fait et mieux fait depuis le back

[Marco46]

A moins de ne travailler exclusivement que sur du SPA, je ne vois pas pourquoi on devrait s'embêter avec AngularJS à refaire une deuxième fois dans le front un travail déjà fait et mieux fait depuis le back

Ben ouai ... Angular c'est pour faire exclusivement des SPA. Le principe c'est d'avoir une application front totalement séparée du back.

La question n'est donc pas de savoir si angular est adapté aux applications de gestion, mais si une archi REST avec une SPA web en front sont pertinentes pour un besoin d'appli de gestion.

Je pense personnellement que oui et que ton architecture est obsolète.

Une SPA web a pour premier objectif d'aller vers du mobile. L'objectif c'est d'avoir une seule application pour couvrir desktop, tablette et smartphone, parce que tu ne pourras jamais atteindre les performances d'une SPA (angular ou autre) avec du templating côté serveur.

C'est ça le coeur du sujet. Est-ce que ton client a besoin de mobilité. Il y a des myriades de cas où une appli de gestion mobile est pertinente.

Si tu fais du full desktop et que tu fais du web juste pour faciliter les déploiements (car si full desktop pourquoi ne pas faire du client lourd ?) alors oui tu peux continuer sur du templating côté serveur mais tu prends de la dette technique et tu n’acquiers pas les compétences de l'avenir.

[Marco46]

Pour moi, ces frameworks soient disant en vogue(AngularJS, Backbone, etc) ne sont juste que de la pure publicité de leurs créateurs et qu'ils ont été créés juste pour voler vos données.

On peut avoir une explication sur ce délire ? Ou bien c'est l'apéro qui a été un peu chaud ?

[dukoid]

chaque framework a son utilité, ses avantages, ses inconvénients.
la concurrence est bonne, cela permet d'avoir de la qualité, de la gratuité.