Discussion :

[Logan Mauzaize]

Une question simple : quelle solution prendre ou dans quel cas choisir une solution plutôt qu'une autre ? (la réponse est plus complexe )

Les deux mon capitaine ! Angular est d'abord un framework MVVM et Polymer une implémentation des Web Components. Justement l'un des objectifs d'Angular 2 est l'intégration des Web Components.

Donc le couplage Angular 2 et Polymer est logique.



Tout le débat sur l'utilisation de NPM est franchement ... navrant. Quand tu fais du dev Java et que tu te paluches Maven/Gradle ou VS pour C# (sans compter les Development Kit) on trouve cela tout ce qu'il y a de plus banale. Mais installer un petit outil comme NPM (le reste reposant entièrement sur NPM) on trouve cela trop complexe ...

Franchement comparer la récupération d'une librairie en deux actions (téléchargement + unzip) et la récupération des sources à l'exécution en 6, c'est limite pathétique ...

Aujourd'hui il ne faut pas plus de temps qu'hier mais on va beaucoup plus loin avec une meilleure productivité en développement et de meilleur qualité que ce soit en termes de code, déploiement, de gestion de conf, etc. Et quand bien même les installations seraient un poil complexe, est-ce qu'il vaut mieux perdre du temps une fois à l'arrivée sur le projet ou chaque minute que tu développes, tests, déploies, etc ?

Après on oblige à rien mais d'un côté on se plaint de ne pas pouvoir faire les choses rapidement mais de l'autre on se plaint de l'utilisation d'outils qui permettent d'aller plus vite ... Faudra savoir !

[Invité]

J'ai été voir sur les sites anglais.

Pour moi, c'est un gars à la grosse tête qui a décidé de casser tout le travail de structuration de la version 1 qui a du choper un poste important chez google.

Il n'y avait pas besoin de casser le système des controleurs, c'était super bien.

Mais bon j'ai vu un post en anglais ou on comprends à peu près les nouveautés :
http://angular-tips.com/blog/2015/06...ngular-2-rock/

Franchement si on voulait faire des classes, on ferait du java, et justement l'intérêt d'Angular 1.3 est de ne pas faire cette vieille usine à gaz qui date de 1994 (25 ans ? Ah oui, ça tourne avec les processeurs 386, je connais... ça n'avance pas.. C'est ça, hein ? Normal en ce temps là on était en 24 kbs/seconde mouah ah ) .

Et l'idée de détruire le principal intérêt de Angular 1.x qui était le two way binding, c'est complétemant naze.

Pour moi, j'en suis presque sur, un mec a du prendre la place de l'ancien team, pour tout foutre en bordel, pour faire genre " vous voyez j'ai travaillé, je vous ait pondu un nouveau truc refondu de a à z" pour justifier son salaire chez Google, alors qu'en fait c'est un truc obscur d'un mec aimant se la péter, un mode de pensée que je déteste dans l'informatique .

Oui seulement, c'est sur la pérénité qu'on juge un produit, pauvre jojo. je me sens un peu dégoutée.

L'angular 1.0 est très clair et le système du 2 way binding est son principal intérêt, alors pourquoi casser ça si ce n'est pour casser le projet. Sans compter les fantastiques Bases de données Firebase qui proposent le 3 ways binding avec AngularFire, du jamais vu en informatique!

Bon je ferais quand même du 2.0 , j'aime bien les classes, mais ce que je lit pour l'instant ne me plait PAS DU TOUT.

Je m'en fout je resterais sur 1.x encore 5 ans.

Angular 1.x est vraiment trop bien, je suis dégoutée, je veux que ce nouveau team se fasse virer et qu'ils annulent la version 2.0 Si j'étais responsable chez google, ce team se ferait virer de suite.

[Marco46]

@MoumouteMasters

Je ne sais pas où tu as vu que Angular2 n'a pas de databinding. Dans lien que tu proposes toi-même il y a un exemple de databinding.

Pour ce qui est des controllers c'est lié avec le scope. Le scope est une source majeure de problème dans Angular 1. Il induit de très mauvaises pratiques. C'est le 1er point (le controllers en angular 1 étant le constructeur du scope).

Le 2ème point c'est un choix axé sur le développement en composants, dans la droite ligne de l'évolution du web pour les années à venir (les webcomponents).

Bref, l'évolution de angular 2 est parfaitement logique est cohérente, rien à voir avec un changement de direction. Pour info Misko Hevery (le fondateur) est toujours à la tête du projet.

[Logan Mauzaize]

Pour moi, c'est un gars à la grosse tête qui a décidé de casser tout le travail de structuration de la version 1 qui a du choper un poste important chez google.

Ou alors quelqu'un qui s'est dit, on a eu une bonne idée mais on a fait des erreurs. Maintenant, il faut assumer et faire mieux.

Il n'y avait pas besoin de casser le système des controleurs, c'était super bien.

Les "contrôleurs" ne sont que des objets parmis tant d'autres d'Angular JS. Les vraies notions importantes je pense sont le scope, l'injection de dépendance et les "EL".
Tous ces principes restent mais ils tendent vers les bonnes pratiques (qui ont fait cruellement défaut aux débuts d'Angular 1) et l'architecture en composant (standard à venir du Web). Qui par ailleurs existent depuis longtemps côté backend (qui est une des grandes sources d'inspiration du framework).

Franchement si on voulait faire des classes, on ferait du java

La programmation par classe n'est pas un apport d'Angular mais des langages : ES6 et TypeScript. Et il s'agit essentiellement de sucre syntaxique pour avoir une approche plus déclartive des types contrairement au système fonction/prototype/scope/this natif.

et justement l'intérêt d'Angular 1.3 est de ne pas faire cette vieille usine à gaz qui date de 1994 (25 ans ? Ah oui, ça tourne avec les processeurs 386, je connais... ça n'avance pas.. C'est ça, hein ? Normal en ce temps là on était en 24 kbs/seconde mouah ah ) .

Désolé mais Angular est par essence une usine à gaz. Il a été concu comme une usine à gaz Java puisque que ce sont des dev backend Java qui l'ont conçu.

Sinon le concept de classe date des années 60-70, celui de prototype des années 90, JavaScript de 1995 et TypeScript de 2012. Je te laisse conclure De plus je ne vois pas en quoi les classes sont une usine à gaz ......

Et l'idée de détruire le principal intérêt de Angular 1.x qui était le two way binding, c'est complétemant naze.

Rien n'a été détruit ... sauf la syntaxe HTML Le binding est toujours là mais avec de nouveaux concepts comme le support des events.

Concernant la syntaxe, c'est clairement une mouvance en vogue.
Ceux qui font du backend entendent de plus en plus parler de DSL et côté frontend on voit fleurir pléthore d'alternatives à HTML/JavaScript/CSS. Cependant comme ces trois seules technologies forment le standard du Web alors il faut tout transpiler. Tu peux voir qu'également du côté de React le partie pris de dénaturer le HTML.

Oui seulement, c'est sur la pérénité qu'on juge un produit, pauvre jojo. je me sens un peu dégoutée.

Oui c'est vrai que rester avec des choses mal conçues est une grande preuve de qualité d'un produit.

Je pense que le vrai problème n'est pas dans Angular 2 mais de comment gérer et intégrer les évolutions d'un point de vue économique. Ceux qui ne veulent pas migrer ne seront pas obligés mais devront payer le coût de maintenance d'une technologie "passée". C'est surtout un choix stratégique de financer soit l'évolution, soit le maintien. Dans tous les cas, il faudra assumer.

Si j'étais responsable chez google, ce team se ferait virer de suite.

Et peut-être que Google aurait déjà coulé aussi. Qui sait ?

[frfancha]

Le scope est une source majeure de problème dans Angular 1. Il induit de très mauvaises pratiques.

Pourquoi? Et en quoi est-ce résolu en Angular2?

[Marco46]

Pourquoi?

Pour plein de raisons, à commencer par l'héritage par prototype qui a une influence majeure sur l'héritage entre scope. C'est résolu par l'usage de la syntaxe controllerAs en angular 1.x.

D'autre part les fonctionnalités associées au scope comme les watchers et la gestion des events conduisent à écrire de la logique dans les controllers ce qui est considéré par beaucoup comme une très mauvaise pratique. D'expérience je dirais qu'il faut tout simplement éviter autant que possible l'injection de $scope et $rootScope.

Et en quoi est-ce résolu en Angular2?

Le service $scope n'existe plus.

[frfancha]

Pour plein de raisons, à commencer par l'héritage par prototype qui a une influence majeure sur l'héritage entre scope. C'est résolu par l'usage de la syntaxe controllerAs en angular 1.x.

Nous utilisons des directives avec scope isolé en 1.x, donc sans héritage par prototype, cela fonctionne parfaitement, je ne vois donc pas la valeur ajoutée du 2.0

D'autre part les fonctionnalités associées au scope comme les watchers

Une widget où l'utilisateur peut entrer P, P/S, et S au choix, et ce à 100% ou pour un pourcentage. Il y a donc 6 champs en entrée et 2, au libre choix de l'utilisateur, sont nécessaires, "l'écran" recalcule en permanence les quatre autres en fonction des 2 premiers. Avec watchers c'est d'une simplicité extrême.

Le service $scope n'existe plus.

On lie le HTML à "this", où est la différence?

[Logan Mauzaize]

Nous utilisons des directives avec scope isolé en 1.x, donc sans héritage par prototype, cela fonctionne parfaitement, je ne vois donc pas la valeur ajoutée du 2.0

Comme dit précédemment cela vient en standard. Si tu as adopté les bonnes pratiques c'est tant mieux mais (1) ce n'est pas le cas de tout le monde et (2) ce n'était pas la philosophie de base.
Avec la 2.0 c'est la façon de faire en standard. De plus, la syntaxe et le cœur sont prêts les web components.

L'intégration avec TypeScript (je n'ai pas vu celle avec Dart) permet de simplifier et de rendre le code beaucoup plus "parlant" en utilisant une API plus déclarative.

Ensuite, même s'il y a fort à parier qu'Angular 1.x continuera à vivre. Il n'évoluera pas aussi vite qu'Angular 2.x. Et donc je le répète la migration (ou non) sera un choix avant tout stratégique. Néanmoins, il y a fort à parier que les évolutions à venir d'Angular 1.x tendront vers l'intégration de fonctionnalités Angular 2.x et donc que le gap sera peut-être moins grand dans 12-24 mois.

Une widget où l'utilisateur peut entrer P, P/S, et S au choix, et ce à 100% ou pour un pourcentage. Il y a donc 6 champs en entrée et 2, au libre choix de l'utilisateur, sont nécessaires, "l'écran" recalcule en permanence les quatre autres en fonction des 2 premiers. Avec watchers c'est d'une simplicité extrême.
On lie le HTML à "this", où est la différence?

L'idée ce n'est pas de se focaliser sur un truc que tu peux faire facilement maintenant mais ce que tu peux faire en général maintenant mais aussi dans l'avenir.

[Invité]

Merci pour vos réponses, je m'étais un peu emportée, je l'avoue, mais c'est parfois bien de mettre l'animation, quitte à dire des semi-bétises...

Du coup, en effet, j'ai repensé au 2 ways binding, et j'ai remarqué que certains avaient expérimenté des ralentissements sur internet.
Seulement, est-ce que cela ne tiendrait pas à leur programmation?


D'après moi il est logique que lorsqu'il y a des tas de binding de variables, à un moment ou à un autre ça pête.

Mais moi , je suis montée que jusqu'à 200 objets maxi dans un ng-repeat, et je n'ai pour l'instant jamais expérimenté de lenteur. Il parait que c'est au bout de 2000 objets bindés que les problèmes commencent.

A ce moment là, peut être fallait il mieux que Google étudie ce type de problème, puis propose des solutions pour conserver le 2 ways binding dans Angular 2.0, plutôt que de revenir au one way binding par défaut.

Donc, le truc avec un ng-repeat, c'est qu'il est censé être par essence illimité, seulement, forcément, il faut trouver un moyen de charger ces données partiellement, mais si on fait cela, alors les supers filtres
du ng-repeat ne fonctionnent plus, d'après ce que j'ai compris, c'est le problème qu'on rencontré certains dev Americains.



Mais il existe d'autres moyens de peupler le NG-repeat, en l'occurence avec Firebase, qui autorise des instructions du style "limit 25 " pour n'afficher que 25 resultats.

Pour ma part comme je le dis, avec 210 objets affichés en temps réels, je n'ai pas constaté de lenteur. reste à tester avec 5000 Objets en temps réel.

D'après moi, la piste du 2 way binding est très bonne, il fallait seulement creuser un peu plus , bref. ( Sans parler de l'EXCELLENT et INNOVANT 3 ways binding de la base de données ANGULARFIRE FIREBASE.)

FInalement, j'aime bien le "Class" de Angular 2.0 et en effet, par moments, le concept a l'air plus simple que Angular 1, je reviens donc sur mes dires, et je testerais Angular 2.0 mlais pour l'instant je reste sur mon nouveau projet datant d'hier en Angular 1.0 + Firebase+ Framework css foundation.

De plus ayant entendu parler de Binding de variables avec Java, mais ne l'ayant jamais expérimenté, je me demande si le 2 way binding existerait pas en Java Web aussi ?

Pour conclure, j'adorais les ng-quelquechose, c'était comme une norme sur laquelle on pouvait s'appuyer. $scope était clair, c'était "un controleur, une vue, un scope, un modèle de données", ce que je trouvais particulièrement puissant simple et clair.
Ajouter un service ? Une fois qu'on a pigé le truc c'est siiimple !

Et puis, on se demande un peu ce que Typescript vient faire là dedans, on a déjà Js... Bon enfin admettons... Faut bien que Microsoft gagne quelques piécettes...

[goldbergg]

La solidité du binding dépend non seulement du navigateur mais aussi du device.

Il y a 2 ans sous angular 1, j’avais un projet avec un liste de ~1500 objets à binder et a afficher dans un tableau (un truc tous con), avec un code minimal sur mon PC sa passais nickel (1 ou 2 sec max de chargement).
Sur smartphone ~1min pour afficher le tableau et je ne parle pas de la suite... (c'est se jour là que j'ai compris que angular n'était pas du tous adapté au développement de webapp pour smartphone...)

[Logan Mauzaize]

Mais moi , je suis montée que jusqu'à 200 objets maxi dans un ng-repeat, et je n'ai pour l'instant jamais expérimenté de lenteur. Il parait que c'est au bout de 2000 objets bindés que les problèmes commencent.

Ca dépend combien de RAM tu as. T'as déjà regardé la conso RAM de ta page quand tu as autant de binding ? Un peu au pif au mètre je dirais 300-400Mo.

A ce moment là, peut être fallait il mieux que Google étudie ce type de problème, puis propose des solutions pour conserver le 2 ways binding dans Angular 2.0, plutôt que de revenir au one way binding par défaut.

Beaucoup de ressources logiques demandera toujours beaucoup de ressources physiques. Il n'y a pas trop de miracles. Si ton appli est gourmande à toi de trouver des solutions : locale storage, filtrage, one way, etc.

Est-ce vraiment nécessaire d'avoir un binding bi-directionnel pour chaque élément ?

Donc, le truc avec un ng-repeat, c'est qu'il est censé être par essence illimité, seulement, forcément, il faut trouver un moyen de charger ces données partiellement, mais si on fait cela, alors les supers filtres
du ng-repeat ne fonctionnent plus, d'après ce que j'ai compris, c'est le problème qu'on rencontré certains dev Americains.

Rien ne t'empêches de charger tes données dynamiquement avec un filtre.

De plus ayant entendu parler de Binding de variables avec Java, mais ne l'ayant jamais expérimenté, je me demande si le 2 way binding existerait pas en Java Web aussi ?

Le "Java Web" étant du backend, je suis pas sûr que cela fasse exactement ce que tu penses.

Et puis, on se demande un peu ce que Typescript vient faire là dedans, on a déjà Js... Bon enfin admettons... Faut bien que Microsoft gagne quelques piécettes...

Typescript apporte beaucoup de choses : la simplicité des déclarations mais aussi le typage statique. Ce dernier point n'étant pas négligeable pour un projet "industrialisé".

Il y a 2 ans sous angular 1, j’avais un projet avec un liste de ~1500 objets à binder et a afficher dans un tableau (un truc tous con), avec un code minimal sur mon PC sa passais nickel (1 ou 2 sec max de chargement).
Sur smartphone ~1min pour afficher le tableau et je ne parle pas de la suite... (c'est se jour là que j'ai compris que angular n'était pas du tous adapté au développement de webapp pour smartphone...)

A se demander comment ils ont pu inventer Ionic Framework et connaître le succès qu'ils ont ...

[goldbergg]

A se demander comment ils ont pu inventer Ionic Framework et connaître le succès qu'ils ont ...

Quand je lit à droite à gauche que les framework de style angular consomme beaucoup trop et que dans la V2 il y a eu des optimisation pour de meilleur perf sur mobile, sa prouve bien que sa n'était pas le top et que le problème est connue...

Et tu te contredit toi même en parlant de la ram, c'est pas un secret que les smartphone sont limité en mémoire et que par conséquent les framework trop gourmand ne sont pas top sur smartphone.

[Logan Mauzaize]

Quand je lit à droite à gauche que les framework de style angular consomme beaucoup trop et que dans la V2 il y a eu des optimisation pour de meilleur perf sur mobile, sa prouve bien que sa n'était pas le top et que le problème est connue...

Et tu te contredit toi même en parlant de la ram, c'est pas un secret que les smartphone sont limité en mémoire et que par conséquent les framework trop gourmand ne sont pas top sur smartphone.

Lol tu comprend bien ce que tu veux. Tu dis que t'as un cas d'utilisation inadapté et tu penses que c'est le framework dans sa globalité qui n'est pas adapté.

oui ces frameworks consomment puisqu'on leur en demande beaucoup. Il faut juste savoir ce qu'on veut faire. Prends un truc comme React, il maintient un équivalent du DOM en mémoire. Ca permet d'aller plus vite mais ca consomme. Ensuite, il y a toujours le principe de plus j'en ai à ma disposition plus j'en profites et moins je fais attention.

Sinon la principale source d'amélioration du binding vient d'ES6 et l'abandon du dirty checking. Après je ne sais pas trop ce qu'ils ont amélioré.

[goldbergg]

Lol tu comprend bien ce que tu veux.

Oué... bin sur le coup je te retourne le compliment

[Logan Mauzaize]

Oué... bin sur le coup je te retourne le compliment

Bon ok, j'avoue la pique était gratuite ... mais argumentée !

Après :

c'est se jour là que j'ai compris que angular n'était pas du tous adapté au développement de webapp pour smartphone...

Je veux bien faire un effort de compréhension mais il faut avouer que d'un côté tu dis rien d'autre que sur mobile, Angular c'est passe ton chemin. Et de l'autre il y a un framework très populaire qui apporte Angular pour le développement mobile.

Je veux bien comprendre que tu n'aies pas la maîtrise du framework et de conception/architecture pour la production d'applications optimisées (pour mobile ou non). Mais dans ce cas il faudrait dire : "j'ai compris qu'Angular n'était pas adapté pour que je développe des webapps pour smartphone [ou petit PC]".

Ce n'est que ce je comprends mais si je me trompe, je suis prêt à te lire

[Marco46]

Il y a 2 ans sous angular 1, j’avais un projet avec un liste de ~1500 objets à binder et a afficher dans un tableau (un truc tous con), avec un code minimal sur mon PC sa passais nickel (1 ou 2 sec max de chargement).
Sur smartphone ~1min pour afficher le tableau et je ne parle pas de la suite... (c'est se jour là que j'ai compris que angular n'était pas du tous adapté au développement de webapp pour smartphone...)

[...]

Et tu te contredit toi même en parlant de la ram, c'est pas un secret que les smartphone sont limité en mémoire et que par conséquent les framework trop gourmand ne sont pas top sur smartphone.

C'est pas le framework le problème là, c'est le développeur qui fait n'importe quoi.

Binder 1500 éléments dans la même page

Au mieux tu affiches allez grand max 50 éléments dans la même page de tableau (oui parce que dans une SPA quand tu fais des tableaux tu les pagines c'est le minimum). Au delà tu es juste entrain de faire du dev de stagiaire.

Et je parle sur desktop. Mais alors sur smartphone comment te dire ...

Allez j'arrête je sors c'est entrain de m'énerver.

[goldbergg]

Le mec me sort sa sans même savoir le type de projet sur lequel je bossais xD

Qui te dit que je pouvais me permettre de n'afficher qu'une seul partie de ma matrice a l’écran?
C'est marrant ces mec qui pense tous savoir de se que font les autres

Si j'était a la recherche d'un framework robuste, c'est que j'avais un projet qui le nécessitai... (on choisi pas toujours se que l'on doit coder)

@Logan Mauzaize
Après le résultat de merde obtenue (je rappelle que c'était il y a deux ans, depuis tout a évolué), je me suis bien évidement documenté sur ma technique a savoir si je m'y prenait bien ou pas (sachant qu'en vanilla j'avais en rendu 100x plus rapide), je suis même allé jusqu’à étudier les source de angular, analysé différent benchmark (et je passe encore très régulièrement sur jsperf pour suivre les évolution) et la conclusion que les framework du type angular consomme énormément et par conséquent ne sont pas adapter au appareil qui ont de faible ressource, elle ne vient pas que de mois, j'ai lue des article complet sur le sujet (et en même temps si on y réfléchie bien sa parait logique)

Mais bon, si on s'attarde a faire que des petit projet CRUD, oui je suis bien d'accord que sa passera probablement bien même sur un smarphone qui a 5ans.

et pour ma remarque, je faisait aussi référence a sa:

Tout le débat sur l'utilisation de NPM est franchement ... navrant. [...]

Tu débarques en sortant se genre de phrase alors que visiblement tu n'a même pas chercher a comprendre on l'on voulais en venir
(en se qui me concerne ton message était bien à coté de la plaque) et la tu me sort " tu comprend bien ce que tu veux.", j'ai trouvé sa plutôt ironique.
(Bon je précise que si je ne t'avais pas répondu ma façon de penssé, c'est que cette discution m'avais fatigué, inutil donc de relancer le débat, chacun a sa propre vision de choses)

[Marco46]

Le mec me sort sa sans même savoir le type de projet sur lequel je bossais xD

Qui te dit que je pouvais me permettre de n'afficher qu'une seul partie de ma matrice a l’écran?
C'est marrant ces mec qui pense tous savoir de se que font les autres

Si j'était a la recherche d'un framework robuste, c'est que j'avais un projet qui le nécessitai... (on choisi pas toujours se que l'on doit coder)

Afficher 1500 éléments d'un coup sur un écran qui fait 320x480 ça n'a aucun sens en terme d'ergo. C'est le 1er point.

Ca peut se faire avec un scroll de 15 bornes de long, mais le faire en ayant un affichage rapide ça n'a pas de sens non plus parce que c'est impossible à faire quelle que soit la solution technique. Le rôle du technicien c'est aussi d'expliquer les impossibilités ergonomiques et techniques au donneur d'ordre qui est souvent aux fraises sur le champ des possibles (c'est pour ça aussi qu'il paye des techniciens).

Une fois qu'on a dit ça, on se rend mieux compte que mettre ces problèmes sur le dos de la solution technique utilisée pour faire un truc impossible c'est complètement hallucinant.

Voilà pour préciser ma pensée.

[Marco46]

la conclusion que les framework du type angular consomme énormément et par conséquent ne sont pas adapter au appareil qui ont de faible ressource, elle ne vient pas que de mois, j'ai lue des article complet sur le sujet (et en même temps si on y réfléchie bien sa parait logique)

Mais bon, si on s'attarde a faire que des petit projet CRUD, oui je suis bien d'accord que sa passera probablement bien même sur un smarphone qui a 5ans.

C'est faux et archi faux. Angular est justement conçu pour fonctionner sur du mobile, ça fait parti de la cible. Simplement il ne faut pas faire n'importe quoi et concevoir les choses correctement.

Pour avoir participé au dev d'une webapp grand public complexe (recherche avancée, geoloc, video, etc ...) ayant des centaines de milliers d'utilisateurs quotidiens je peux te dire qu'on testait tout type de mobiles y compris des grosses bouses obsolètes et les performances étaient au rendez-vous, sauf quand on merdait sur la conception technique. Et parfois on a du faire modifier les demandes du market parce qu'elles posaient trop de problèmes techniques ou qu'elles étaient impossible à réaliser en l'état.

[goldbergg]

Je RE-précise le contexte de mes dire "il y a deux ans"... (et en ressortant les source en faite c'était début 2013, donc plutôt 3 ans), sa a évolué depuis (que sa soit angular ou les smarphone)..
bref, pour se qui est du choix d'afficher ou non la collection complète l’écran, il faut aussi que sa est du sens, dans mon cas sa n'en avais aucun de n'afficher qu'une partie de celle ci.
C'est bien de dire au client, "non c'est pas possible faut faire plutôt comme sa", mais si c'est pour avoir un résultat qui ne correspond plus au métier, c'est pas la peine.

Quant à l'architecture choisi, a la fin j'en était arrivé a faire des test avec un code similaire a sa : http://jsfiddle.net/mrajcok/7MhLd/ (en gros j’injecte directement ma collection structuré comme il le faut pour ma vue dans le scope, puis je boucle dessus avec un ng-repeat, le truc qu'ont m'avais le plus recommandé à l'époque) et sa me prenais toujours 1min sur smartphone contre quelque seconde en vanilla.