Discussion :

[Logan Mauzaize]

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

Parce que tu étais sur smartphone ou en tout cas possiblement. Au boulot aussi on a une application avec un Gantt très riche limite en dessous de 27" tu n'y penses pas. Mais jamais j'aurais l'idée de comparer le portage de cette application sous smartphone.

En tout cas pas as-is et donc dans le contexte mobile, il n'y aurait pas des milliers d'éléments à afficher ou alors éventuellement je génère une image, etc. C'est bien là ou je voulais en venir avec la maîtrise de la conception et de l'architecture. Il faut mettre en relation et adéquation les contraintes techniques et fonctionnelles.

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.

Cela ne prouve toujours qu'une chose : ton cas d'utilisation ne correspond pas à un développement mobile.

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

J'ai essayé de reprendre tous les "sujets" (je ne parle même pas d'arguments ici). Mais je vais détailler, tu me diras (si tu n'es pas trop fatigué) ce que j'ai mal compris et omis :

• Ca me fatigue tous ces tutos de frameworks qui commencent par 20 pages sur l'installation et l'utilisation de gestionnaires de dépendances, d'installeurs externes, de contrôle de version, etc.
  Quand je m'intéresse à une nouvelle techno, je veux un bref aperçu de comment le langage fonctionne afin de savoir s'il peut m'intéresser, pas connaître de manière exhaustive comment gérer un projet de manière optimale.

  L'aperçu le plus bref c'est d'utiliser les outils qui te permettent d'aller rapidement à l'essentiel. Quand tu fais un tuto Java, tu te plains pas d'avoir à installer Eclipse, la JRE, Maven et tout le tralala. Surtout que si ce n'est pas trop mal foutu (surtout avec NPM & co.), tu récupère les sources, une commande pour préparer l'environnement et une dernière pour l'exécution.
  

• J'aurai bien un certain Node.js a pointer du doigt, qui pour moi n'a fait que complexifier la prise en main de certain framework (avec notamment l'utilisation de CLI, de gestionnaire de package, etc...) mais je risque de me faire huer pour sa ^^
  
  Elle était belle l'époque ou il y avait juste un zip a dl et une fois décompressé tout était prés a l'emploi! (bon encore heureux sa se faire encore)

  Au choix tu récupères NPM et tu joues trois commandes (et c'est même prêt pour les différents staging en cerise sur le gâteau), soit tu dl XXXX fichiers, que tu dois référencer, etc. Ou encore tu te paluches 3-4k lignes de code buggées pour arriver à la moitié du résultat. Tu choisiras la complexité que tu veux, mais le plus simple je pense c'est tout de même la première solution. Je me trompe ?
  

• Ca fait bien partie des choses que je pointe du doigts.
  Quand l'apprentissage d'une technologie comme par 20 minutes à taper des commandes, installer les modules et remplir des fichiers de configs auxquels l'on ne comprend encore rien, il y a un soucis.
  Après une entrée en la matière rapide et l'exécution de quelques exemples simples, je vais peut-être me poser la question de l'utilisation des meilleurs modules, serveurs etc, pas avant.

  Au choix : écrire un tuto de 40 minutes pour chaque partie ou bien aller à l'essentiel et laisser le lecteur se documenter sur ce qu'il pourrait l'intéresser. Quand tu consultes un dictionnaire, tu t'attends pas à avoir l’encyclopédie pour chaque définition, non ?
  Sinon je vous laisse avec joie aller configurer PHP, JavaEE, IIS, Apache, etc. Et je parle même pas des Make ou autres. Les besoins en installation et de configuration, n'ont rien de neuf et beaucoup de choses ont été faites pour les faciliter.
  

• C'est vrais que c'est 100% plus rapide que :
  -Clique-droit => extraire-ici

  Sauf que ce n'est pas suffisant et ne correspond pas à toutes les étapes nécessaires. Donc oui, ouvrir mon frigo c'est plus rapide que d'aller faire les courses. Mais cela n'a pas grand chose à voir non plus.
  

• Je fais pas mal de site SPA sans Node.js* (d'ailleurs angular n'a pas besoin de Node.js pour fonctionner), coté serveur j'ai des WS REST, la techno on sans fous (généralement de l'ASP.NET Web API, mais sa peut tout autant être du PHP ou du JEE).
  Se qui ne me plais pas c'est qu'on nous impose tous se bazar...

  Non ce n'est pas imposer mais recommander pour certains usages et aller plus vite. Ce n'était pas d'ailleurs ce point de détail que tu pointais deux phrases plus tôt ? Et d'ailleurs, il t'a fallu combien de temps pour initier ton projet jusqu'au déploiement pour ton WS ? Et "Convention over configuration", ca te parle ? Oui si tu suis certaines conventions (ce n'est pas qu'une question d'organisation et de nommage des "unités de compilation"), tu te taperas moins de configuration.
  

• pour tous dire Node.js j'en est fais un peux, je n'y est vue aucun intérêt vis a vis de la concurrence coté serveur (dans le cadre de mon utilisation bien sur), donc j'ai laissé tombé, en se qui me concerne l'ASP.net MVC est bien plus pratique et productif, sans compter le partage de ressource avec d'autre projet pas forcement web et l'interop.

  La praticité et la productivité ne se mesure qu'avec l'expérience sur un long moyen/terme. Même si je suis pas d'accord avec l'expression exacte mais ce n'est pas pour rien qu'on parle de "10x developper".
  Le partage de ressources meilleur sous une autre techno que JS ? Je crois que c'est un comble. Par nature même, tous les scripts sont meilleurs de ce point de vue. Et l'intérop se base uniquement sur des protocoles et historiquement et par nature, l'écosystème JS repose sur des échanges textuels avec des formats "légers" et ouverts.
  

• J'ai de plus en plus l'impression qu'aujourd'hui faire du JS signifie faire du Node.js se qui est archie faux... persso je distingue encore la partie cliente de la partie serveur et je trouve sa très importent que dans un site SPA le couplage sois le plus faible possible.

  Deux choses : NPM repose sur Node.js mais l'utiliser ne veut pas dire faire qu'on fait du développement côté serveur. L'idée c'est tout au plus de réutiliser les compétences pour améliorer ton propre environnement de travail. Si je pouvais me passer de scripts Batch/Shell et tout faire en Java, je m'en priverai pas !
  Deuxièmement, la séparation client/serveur n'est pas sans poser quelques soucis de duplication de code, de logique et de divergence. Certains projets n'en souffrent pas (pour différentes raisons qui passent par la gestion de projet à la nature même du projet) mais pour d'autres le non-couplage est moins évident.
  

• Eh bien je ne sais pas pour les autres mais personnellement, je demande à comprendre ce que je fais, et ce n'est pas le fait d'exécuter une série de commandes qui vont faire 200 trucs automatiquement qui vont m'y aider.
  Encore une fois, je n'ai rien contre le fait d'améliorer son workflow autant que possible une fois qu'on est plongé dans le bain, mais pour commencer, donnez-moi une archive à extraire avec un Hello World pour que j'ai une vague idée de ce que fait la techno et comment.

  Dans ce cas faut pas regarder les tutos mais les exemples. Ou changer de tutos si le niveau requis ne te semble pas en adéquation. Néanmoins de mon expérience (et je lis pas mal de tuto en diagonale), les commandes sont relativement simples et leurs intentions très claires. Et si je comprends pas quelque chose ou que j'ai un doute, je consulte la ressource qui m'apportera au mieux le type de réponse que j'attends : le manuel de référence, le "man", un tuto, etc.
  

• Pour une entreprise (ou un simple dev) qui est habituer a utiliser différent framework ou libs, oui c'est très bien, perso si je n'utilise pas npm dans node.js, mais j'utilise souvent nuget dans VS.
  Mais là on parle de la mise a disposition de framework seul, donc soit y a qu'un seul fichier, soit une archive avec tous se qu'il faut de fournie.

  Sauf qu'un framework peut en dépendre d'autres.
  

• Angular 2, tu doit telecharger et installer Node.js, puis tu installer npm, puis pianoteer quelque commande, etc... avant même de toucher a du code on se retrouve a configurer toute un tas de chose pas forcement utile sur l'instant.

  Non tu peux comme Angular 1 si ca te chantes mais tu n'en tiras pas tous les bénéfices. Quand tu suis un tuto C#, tu te plains pas d'avoir installer VS et son lot de composants ? Alors pourquoi chouiner sur deux applications de 10 Mo ? Dont l'une ne tient qu'en un seul fichier exécutable et le tout s'installe en deux clics !
  Je fais même pas la comparaison avec Java, c'est imbattable
  

• Et malheureusement angular n'est pas le seul, j'avais voulu tester la lib web de google (Web Starter Kit), je ne sait pas si sa a changer depuis, mais j'avais été obligé d'installé Node.js ainsi que gulp pour pouvoir tester alors que c'est juste une lib material design sans aucune logique.
  Bientôt juste pour récupérer un bout de code sur stackoverflow ou codepen il faudra passer par npm

  Non tu ne seras pas obligé mais l'avantage c'est que tu peux déjà presque le faire
  

• Bref se que je dit c'est que l'utilisation de toute cette machinerie devrait être un choix du dev et non de l’éditeur du framework, pas que les outils ne servent a rien.

  Le choix tu l'as. Ces outils ne font que de la manipulation de texte, te prépares et exécutes des choses pour toi. De sortes qu'en une seule commande de l'outil, tu t'économises des centaines de manipulations manuelles.
  

• Et les solution alternative sa te parle?

  Si tu as les moyens de les développer, pourquoi pas. D'ailleurs c'est un peu le principe de l'Open-Source, libre à chacun de contribuer à sa manière. Et certains se "spécialisent" dans l'intégration avec d'autres outils. Mais il faut pas toujours s'attendre à un haut niveau de maturité, d'investissement, etc. même si certaines alternatives deviennent meilleures que les solutions/intégrations originales.
  

• Et l'envie d'utiliser le framework juste pour ou apprendre ou tester des chose sans faire de test ni de gestion de source c'est interdit en 2015? (sa veut dire quoi sa "un framework professionnel"?, théoriquement n'importe qu'elle framework l'est).

  Et l'intérêt du choix il est ou dans ce cas ? Sinon un framework "professionel", c'est un framework industrialisable.(ou industrialisé ?), il correspond aux critères de sélection d'une entreprise pour une mise à disposition à grande échelle.
  

• On est censé maîtriser un framework des notre premier utilisation?

  Je pense pas que quelqu'un est dit cela ... Mais il y a tout de même toujours un minimum à connaître.
  

• Se que j’accuse c'est justement cette façon de nous imposer notre façon de faire, le choix des outils, etc... c'est quand même pas difficile a comprendre?

  Ce qui est difficile à comprendre c'est déjà se besoin d'avoir le choix ... et de critiquer son absence quand il existe mais aussi de ne pas assumer ce choix : "on nous reommande des outils mais c'est trop long sans" ... Si tu tiens les deux côtés de la corde, faut pas s'étonner qu'elle ne bouge pas ! Si on te sort un argument dans un sens, tu sors un argument dans l'autre camp.
  

• Et y a une différence entre un framework et les bonne pratique d'utilisation ainsi que les outils recommandé...

  Il y a une différence entre un framework, les bonnes pratiques et les outils recommandés ? Soit tu as mal exprimé ton idée, soit c'est toi qui est à côté de la plaque. La force d'un framework c'est autant ses fonctionnalités et que son utilisabilité.
  Sinon tout au plus c'est une lib comme une autre.
  

• Npm, Node.js etc... ne font pas partie du framework angular, sa n'est juste que des outils qui peuvent être remplacer par d'autre, en l'occurrence visual studio permet aussi de créé un projet angular sans npm, node.js & cie.

  Preuve en est que des alternatives existent mais tu dois bien avouer que VS ne doit pas être l'outil le plus répandu chez les utilisateurs d'Angular 1/2 ? Là, l'éditeur du framework te propose un outillage facile à intégrer même dans une ligne de commande. Et il ne faut pas confondre l'abscence d'alternative avec l'impossibilité d'en avoir.
  

• C'est justement là qu'on est pas d'accord: ces tâches PEUVENT être exécutées par des tasks runners écrits en JS mais ne DOIVENT pas l'être.

  Soit c'est mal dit, soit c'est idiot (désolé mais voir juste ci-dessous).
  

• Par exemple si dans mon process le minify se fait dans un Bundle en visual studio, pourquoi faudrait-il changer cela pour le remplacer par grontgulglopglip pour utiliser angular.

  Simplement parce que la solution visual studio n'est pas industrialisable et intégrable dans une chaîne de livraison.
  

• Node.js + grontgulglopglip est UNE façon de développer mais ce n'est pas la seule (heureusement), et le fait de "l'imposer" (parce que toutes les aides et tutoriaux sont basés dessus) me semble malsain (ainsi qu'à quelques autres intervenants semble-t-il)

  Parce que personne n'a mis les moyens (ou envie de les mettre) pour mettre en place une solution alternative sans valeur ajoutée. Si tu parles des papiers officiels, ils peuvent pas prévoir tous les cas d'usages mais t'offrent une façon de travailler qui s'intègre à tous les environnements (ligne de commande, IDEs favoris, serveur d'intégration continue, etc.).
  Ce qui me semble malsain, c'est de ne pas s'en rendre compte.
  
  Si cela concerne les autres sources (outre les mêmes raisons qui s'appliquent), sachez que Developpez.com accueillera très favorablement et avec beaucoup de plaisir vos tutoriaux. Mais sachez aussi que vous toucherez surement un public moins grand qu'en étant plus "ouvert" (par opposition à "imposer" ).
  

• Hum, bien qu'il y est un menu déroulant permettant de choisir JavaScript plutôt que TypeScript, je trouve que se choix par défaut va aussi à l'encontre de se que tu dit sur les mauvaise pratique.
  Après tous TypeScript n'est rien d'autre qu'une surcouche dégueulasse et contre-nature du JavaScript au yeux d'un puriste apprécient le JavaScript pour se qu'il est! On pourrait même sentir une sorte d'insulte au JavaScript en proposant un langage plus proche de la POO par class que de la POO par prototype. (bien évidement sa n'est qu'une façon de penser, chacun l'entend comme il le veut)

  L'idée c'est d'apporter des structures plus déclaratives (et donc statiques) contrairement à la nature dynamique de JavaScript. Et donc plus lisible et plus sûr (ajout de contrôles statiques) et par conséquent plus maintenable.
  Bien évidemment cela n'est qu'une façon de penser mais c'est presqu'un critère de choix plus qu'une simple fonctionnalité.
  

• Sa m'en vient a formuler une autre remarque, je veut bien que sa soit une mauvaise pratique pour qui veut partager ses source (sur Git par exemple) de ne pas utilisé les outils recommandé, mais pour n'importe qu'elle éditeur de logiciel et/ou SSII, les bonne pratique sont imposé par l'entreprise et non par des bien pensant sur le web qui proposent/impose leurs façon de penser et je rappelle que la majorité des entreprise ne fait pas d'open-source (pas besoin d'être un génie pour comprendre pourquoi), donc bien formater sont projet pour pourvoir plus facilement le partager, on sans fous royalement, se qui importe c'est que les convention de l'entreprise soit respecter (se qui peut inclure d'utiliser un IDE plutôt que les outils de base). Et j'en profite pour rappeler que dans bon nombre d'entreprise on ne nous laisse ni choisir l'OS, ni l'IDE et/ou outils de dev, dans se cas là, a quoi bon apprendre avec npm ou encore TypeScript si au final on aura même pas la possibilité de l'utiliser.

  A ton avis d'où sortent toutes les conventions et choix d'outils proposés/imposés dans les entreprises ? Sur quels critères ces choix sont-ils fait ?
  Et si stratégiquement les entreprises décident d'utiliser Angular 2, stratégiquement elles adopteront les outils qui vont avec. Comme les entreprises qui utilisent Java ce sont mis à Ant, puis Maven et aux Servlets. Ce sont des technologies qui s'imposent par stratégie et non par contraintes. Excepté si tu considères la facilité comme une contrainte, mais c'est l'histoire du verre à moitié vide ou à moitié plein.
  

• Et par malsain, bien que sa n'est pas moi qui est utilisé se terme, se que j'entend, c'est que pour quiconque qui débarque, on ne leurs dit pas "vous avez tel ou tel choix" (comme c'était le cas pour angular 1), mais juste "installe npm", comme si c'était la seul chose logique a faire. Et sa, surtout pour une plateforme qui a une grosse communauté de linuxien, je trouve que sa va profondément a l'encontre de la philosophie du libre choix (vue que même si au final on a le choix, on nous le masque au première abord).

  Ce qui est ironique c'est que le choix, c'est ce qui a causé du tord Angular. Et que les évolutions de la technologie et sa présentation (guide, tutorial, référence) ont été conduit par justement être plus directif parce que sinon les gens optaient pour de mauvaises pratiques et donnaient une mauvaise image du framework (ex - presque au hasard - : saturé l'IHM de 1500 éléments).
  
  Commencer par maîtriser les choses basiques me semblent une approche pas trop idiote avant de continuer avec des choses plus freestyle mais dont il faut maîtriser l'usage. Il faut pouvoir être capable d'assumer ses choix. Et quand on débute, on le peut pas.
  

• C'est juste qu’après de nombreuses année a dev en JS (je fais su SPA depuis ~2011) a utiliser différente lib et framework ou sa se résumé simplement a dl un fichier sur un site et c'est tous, depuis que l'arrivé de npm, on nous redirige systématiquement vers cette plateforme (sans compter les autre outils qui vont derrière tel que grunt par exemple) avec se sentiment que quelqu'un cherche forcer notre changement d'habitude.

  Il serait idiot de se passer d'un facilitateur. Surtout si dans le cadre d'un article, ca te permet d'initialiser le projet en un rien de temps. Et il y a fort à parier qu'une bonne partie des lecteurs connaissent ou soient amenés à connaître.
  

• A croire qu'un dev JS se doit obligatoirement de passé a tous sa et que le temps ou un simple Notepad couplé a n'importe quel navigateur suffisait pour coder en js et terminé...

  Je pense que c'est quasiment le cas. Notepad ca dépanne parce que c'est installé partout mais aujourd'hui il faut un minimum d'outillage pour travailler convenablement que ce soit la mise en forme (ex : coloration syntaxique), le formattage, l'autocomplétion, l'analyse statique, etc.
  

• Sa me fait ressentir la même chose de se qui est arrivé il y a quelque année avec jQuery avant le retour en force de Vanilla, ou a chaque fois qu'on cherchais un tuto ou un bout de code sur le net c'était forcement du jQuery..., comme si sa n'était plus possible de dev sans...

  Il y a des techniques ou technologies qui s'imposent. Quand 90% des projets reposent dessus, ca me paraît pertinent que 90% des questions, tutoriaux, etc. reposent également dessus. Surtout quand tu peux exprimer en 3-4 lignes ce qu'il faudrait faire en 10-20 lignes de code purement natif.
  

• Et sinon, désolé mais non, tous les éditeur n'on pas un repo sur git d'accessible, donc que les source soit disponible n'est pas une évidence (faut arrêté de penser que tout est open-source!) et pour beaucoup de logiciel dispo sous Linux, on nous propose généralement de DL les source sans passer par un repo, je vois pas pourquoi en JS sa ne serais pas/plus le cas.

  un FTP, CDN, un serveur HTTP x/y, Git ou autre, ca reste des dépôts. L'avantage de GitHub c'est juste sa facilité de déploiement et d'accès ainsi que sa popularité. Faut pas de leurrer la plupart des projets sont hébergés sous GitHub.
  

• je pense que ce qui est mis en avant c'est qu'il n’existe que des tuto a base de npm & co ce n'est pas une négation envers cette mouvance mais l'impression qui en ressort impose de faire de cette façon et pas une autre.

  Si je te dis que "Pour aller de Toulouse à Paris, passes à l'autoroute A20". T'as l'impression que je te l'impose ou simplement que c'est le choix le plus logique. Peut-être que tu préfères que je t'énumères tous les trajets possibles ? Si c'est le cas compte pas sur moi, et je pense que c'est pareil pour toi.
  S'il suffit qu'on vous présente une façon de faire, pour croire que c'est la seule. Le problème n'est pas du côté de la source.
  

• Un premier problème que je vois avec cet approche, c'est que les ressources sur AngularJS deviennent dépendantes d'autres technologies amenées à changer, disparaître ou être remplacées. Il m'est déjà arrivé de perdre plusieurs heures sur un tuto parce qu'il introduisait le sujet avec des informations obsolètes. Pour moi, la manière de générer un projet avec un programme tiers, aussi populaire soit-il devrait être ajoutée à titre informatif et facultativement.

  Bienvenue dans le monde de l'informatique ou dans le monde des sciences/technologies de manière générale. Tu trouveras encore également beaucoup de livres qui parlent de la machine à écrire Je suis gentillement moqueur mais c'est bien ainsi qu'est fait notre société. Internet est très facile d'accès et les choses(techniques et technologies) évoluent.
  Pour être productif/clair à une époque, on utilise les outils et méthodes disponibles à ce moment là. Par exemple, le design pattern Singleton a fait son temps mais tu devrais plus le trouver dans un écrit récent. L'obsolescence est inévitable, tout va très vite alors on s'appuie sur des choses qui permettent d'aller vite.
  

• 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

  Cela résumait mon premier message et résume aussi celui-ci.
  

Pour compléter, j'ai juste l'impression d'enfants qui découvrent le monde de l'entreprise et l'industrialisation de notre métier. Je prone depuis mon arrivée sur le monde du travail pour l'outillage et si possible existant publiquement.
Les outils ne sont pas indispensables mais essentiels. Et dans un contexte économique, oui essentiel est l'égal d'indispensable.

[Invité]

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.

Je suis d'accord qu'il faut paginer, mais en ce cas, les filtres AngularJs 1.0 du ng-repeat ne s'appliquent que sur les 50 résultats visibles, et pas sur l'intégralité du modèle de données, je trouve ça embétant.
Parce que j'aime quand le filtrage s'applique sur l'intégralité du modèle de données.
Je me suis toujours demandé quel était le maximum d'objets affichable pour que le filtre continue à opérer correctement.

Du coup j'essaye de ne pas paginer mais j'ai fait que 200 objets bindés maximum...

Quelqu'un sait-il comment modifier son pseudo ?

[goldbergg]

Moué, bin je reste sur ma position, tu (vous) ne cherche vraiment pas à comprendre et pense détenir la vérité absolue sur quelque chose ou il n'y en a pas (et après c'est nous les gamin... bin voyons).
Pour le coups des 1500 object (qui je rappelle était "bindé", donc le coup de l'image...) je n'est volontairement ni donnée le contexte qui ma poussé a faire sa, ni a quoi devait ressembler le rendu (juste que j'utilisai une table) et vous êtes la a dire qu'il y a un problème d'architecture et/ou de choix sur quelque chose d'ont vous ignorez presque tous...
Et juste comme sa, la webapp à était faite POUR mobile, c'était sa principale raison d’exister afficher la matrice éditable sur n'importe qu'elle smartphone.

Pour le reste de la discutions lié a NPM & cie, bin c'est pareil... Je (on) ne suis pas vous, j'ai probablement des besoin différent donc respecté les et ne venez pas dire que l'on est dans l'erreur (ou que l'on est pas pro) parce qu'on ne suit pas la doctrine de certain...
Et puis bon, pour un peux synthétiser le "problème", entre angular 1 ou l'on a le choix entre un lien d'un CDN, les commandes Bower/Npm et du DDL et a coté angular 2 ou le seul choix que l'on a c'est npm (pas de lien CDN ni de DDL alors qu'on est sur le site officiel, a nous de nous démerdé a trouver) tu va pas me dire que angular 2 a une approche plus sexy pour le mec qui débarque et/ou qui bosse dans l'un des très nombreux enivrement autre que node.js/npm ?

[SylvainPV]

Il n'y a pas de CDN parce que c'est une beta 0 et que personne ne devrait mettre quelque-chose en production avec une beta 0. De plus, il n'y a pas qu'un bundle mais des dizaines d'options différentes selon le langage, l'outillage choisi et les modules utilisés.

[Marco46]

Je suis d'accord qu'il faut paginer, mais en ce cas, les filtres AngularJs 1.0 du ng-repeat ne s'appliquent que sur les 50 résultats visibles, et pas sur l'intégralité du modèle de données, je trouve ça embétant.

Il faut distinguer le filtrage / pagination côté client de celui côté côté serveur. Effectivement les filtres du ng-repeat s'appliquent sur le modèle que tu as côté client.

Parce que j'aime quand le filtrage s'applique sur l'intégralité du modèle de données.

Si tu veux pouvoir appliquer le filtre de ton ng-repeat sur l'intégralité du modèle de données ça signifie que tu veux remonter l'intégralité de ta base de données dans ton navigateur. Ca n'a pas de sens.

Imagine un peu une telle conception appliquée à un moteur de recherche, Google par exemple. Ca n'a pas de sens.

Applique le même raisonnement à un client lourd. Ca voudrait dire qu'au lancement de ton appli tu charges toute ta db en mémoire ? Ca n'a vraiment aucun sens !

Du coup j'essaye de ne pas paginer mais j'ai fait que 200 objets bindés maximum...

C'est déjà beaucoup trop ! 200 objets bindés sur un tableau de 4 colonnes par exemple ça fait 800 watchers et ce uniquement pour ton tableau.

Les 2000 watchers donnés par Misko Hevery à titre d'exemple c'est pour du desktop, et encore c'est une limite qui n'a pas de sens en terme d'ergo, c'est juste une limite en terme de perf. 2000 informations sur une IHM aucun être humain n'est capable de traiter ça.

[Marco46]

Moué, bin je reste sur ma position, tu (vous) ne cherche vraiment pas à comprendre et pense détenir la vérité absolue sur quelque chose ou il n'y en a pas (et après c'est nous les gamin... bin voyons).
Pour le coups des 1500 object (qui je rappelle était "bindé", donc le coup de l'image...) je n'est volontairement ni donnée le contexte qui ma poussé a faire sa, ni a quoi devait ressembler le rendu (juste que j'utilisai une table) et vous êtes la a dire qu'il y a un problème d'architecture et/ou de choix sur quelque chose d'ont vous ignorez presque tous...
Et juste comme sa, la webapp à était faite POUR mobile, c'était sa principale raison d’exister afficher la matrice éditable sur n'importe qu'elle smartphone.

C'est pas une histoire de vérité absolue c'est une histoire de bonnes pratiques et de savoir en terme d'ergonomie et de technique. On affiche pas 1500 éléments sur un écran qui fait 320x480, point final. Tu pourrais tout aussi bien prétendre qu'on prétend définir la vérité absolue à insister sur le fait que la terre tourne autour du soleil alors que tu affirmes l'inverse. On est sur ce niveau de discussion là ... Et visiblement tu t'en rends pas compte.

[Logan Mauzaize]

Je suis d'accord qu'il faut paginer, mais en ce cas, les filtres AngularJs 1.0 du ng-repeat ne s'appliquent que sur les 50 résultats visibles, et pas sur l'intégralité du modèle de données, je trouve ça embétant.

Je n'ai pas connaissance d'une telle limitation en tout cas sur mon application en Angular 1.3.15, j'affiche 200 éléments sans problème. T'aurais pas un "limitTo" ?

Parce que j'aime quand le filtrage s'applique sur l'intégralité du modèle de données.
Je me suis toujours demandé quel était le maximum d'objets affichable pour que le filtre continue à opérer correctement.

Tu peux faire un filtre qui requête un service.

Quelqu'un sait-il comment modifier son pseudo ?

Vous désirez changer de pseudo (identifiant) ?

Moué, bin je reste sur ma position, tu (vous) ne cherche vraiment pas à comprendre et pense détenir la vérité absolue sur quelque chose ou il n'y en a pas

La vérité (me semble-t-il) est que vous ne cherchez vraiment pas à comprendre que des papiers mainstream traitent de cas mainstream. Et que trouver des ressources avec des cas d'usages alternatifs (voir spéciaux) sur une technologie en beta puisse être difficile.
Je pense que mon précédent et large message prouvent bien que je fais l'effort de chercher à comprendre mais j'avoue tourner un rond. Tu fais des remarques ou éprouves des ressentiments et je fais l'effort de te démontrer pourquoi les choses fonctionnent ainsi ...

et après c'est nous les gamin...

J'ai simplement dit que ce comportement me faisait penser à celui d'un enfant qui découvre le monde du travail et de son "business".

Pour le coups des 1500 object (qui je rappelle était "bindé", donc le coup de l'image...) je n'est volontairement ni donnée le contexte qui ma poussé a faire sa, ni a quoi devait ressembler le rendu (juste que j'utilisai une table) et vous êtes la a dire qu'il y a un problème d'architecture et/ou de choix sur quelque chose d'ont vous ignorez presque tous...
Et juste comme sa, la webapp à était faite POUR mobile, c'était sa principale raison d’exister afficher la matrice éditable sur n'importe qu'elle smartphone.

Effectivement on ne s'étendra pas plus sur le sujet tant on sait tous l'étendue de l'information nécessaire à la mise en place d'une solution technique face à toutes les exigences (fonctionnelles et non-fonctionnelles). Mais dans l'absolu, imaginer une interface d'environ 11cm x 6cm (grand max) est un exercice difficile.

Pour le reste de la discutions lié a NPM & cie, bin c'est pareil... Je (on) ne suis pas vous, j'ai probablement des besoin différent donc respecté les et ne venez pas dire que l'on est dans l'erreur (ou que l'on est pas pro) parce qu'on ne suit pas la doctrine de certain...

Le problème c'est pas ton besoin mais juste tes critiques infondées. Tu cris au scandale parce que tu trouves pas des ressources qui te conviennent et qui te conseillent un outil très répandu et qui est un socle tout à fait commun. Et ceux par opposition à d'autres technos où il y a beaucoup plus de pré-requis.

Et puis bon, pour un peux synthétiser le "problème", entre angular 1 ou l'on a le choix entre un lien d'un CDN, les commandes Bower/Npm et du DDL et a coté angular 2 ou le seul choix que l'on a c'est npm (pas de lien CDN ni de DDL alors qu'on est sur le site officiel, a nous de nous démerdé a trouver) tu va pas me dire que angular 2 a une approche plus sexy pour le mec qui débarque et/ou qui bosse dans l'un des très nombreux enivrement autre que node.js/npm ?

J'avoue pleinenement, je n'avais pas encore fait l'effort d'ouvrir le "5 MIN QUICKSTART (Angular2 for TypeScript)" mais voici ce qu'on trouve tout au début :

DON'T WANT TYPESCRIPT?
Although we're getting started in TypeScript, you can also write Angular 2 apps in JavaScript and Dart by selecting either of those languages from the combo-box in the banner.

Puis le "5 MIN QUICKSTART (Angular2 for JavaScript)" :

See It Run!
Running the live example is the quickest way to see an Angular 2 app come to life.

[Invité]

Il faut distinguer le filtrage / pagination côté client de celui côté côté serveur. Effectivement les filtres du ng-repeat s'appliquent sur le modèle que tu as côté client.



Si tu veux pouvoir appliquer le filtre de ton ng-repeat sur l'intégralité du modèle de données ça signifie que tu veux remonter l'intégralité de ta base de données dans ton navigateur. Ca n'a pas de sens.

Imagine un peu une telle conception appliquée à un moteur de recherche, Google par exemple. Ca n'a pas de sens.

Applique le même raisonnement à un client lourd. Ca voudrait dire qu'au lancement de ton appli tu charges toute ta db en mémoire ? Ca n'a vraiment aucun sens !



C'est déjà beaucoup trop ! 200 objets bindés sur un tableau de 4 colonnes par exemple ça fait 800 watchers et ce uniquement pour ton tableau.

Les 2000 watchers donnés par Misko Hevery à titre d'exemple c'est pour du desktop, et encore c'est une limite qui n'a pas de sens en terme d'ergo, c'est juste une limite en terme de perf. 2000 informations sur une IHM aucun être humain n'est capable de traiter ça.

Lorsque l'on ouvre un classeur EXCEL, on ouvre parfois un fichier aussi gros qu'une Base de Données NO SQL.
(De plus j'ai déjà vu Excel charger une BDD avec Odbc)

Pour moi, charger l'intégralité d'une base de données pour un site petit ou moyen peut faire sens, en tous les cas, mes recherches tablent sur cela. Tout est question de quantité de données previsionnelles. Un fichier JSON au format tableau [] contenant des milliers de ligne d'objets JSON {} est censé pouvoir être chargé en mémoire et modifié à la volée, pourquoi pas, avec les capacités des ordinateurs actuels, enfin cela ne me parait pas absurde sur du desktop.

Une base de données Sqlite est aussi souvent intégralement chargée, sauf erreur, en mémoire.

Mais je suis d'accord que ce n'est pas la pratique, je suis loin d'être un cador en la matière puisque quelques mois d'xp, je ne fais qu'exprimer une opinion, mais je suis attiré par cela, d'ailleurs, les concepteurs d'Angular l'étaient probablement aussi, en concevant le ng-repeat . Leur idée de transférer toutes les données dans le navigateur est séduisante.

Avec des desktops ayant souvent 8Go de mémoire vive en série de nos jours, les choses impossibles par le passé le deviennent.

J'ai envie d'injecter 3000 objets dans mon exercice angularJs 1.3 http://nicolash.org/truc37/ ou alors http://nicolash.org/truc38/ pour voir comment il réagit sans pagination, mais il faudrait que je crée un genre de boucle qui crée 3000 objets vu que je ne sais pas faire de jasmine encore(Qui, il me semble peut faire, ou tester ce genre de trucs...), et ça me soule de créer 3000 objets à la main... Même en copié-collé LOL

[SylvainPV]

La première chose dont il faut se soucier en matière de performances sur un projet web, c'est le réseau. La RAM ou le CPU du client sont des données complètement négligeables, le temps de traitement des données côté client ne représentant qu'une toute petite fraction du temps de requête. Même sur un smartphone bas de gamme, trier/filtrer 10.000 objets prend 100 millisecondes tout au plus, avec Angular ou autre chose. En revanche, télécharger les données de ces 10.000 objets prendra plusieurs secondes. C'est d'ailleurs un des arguments principaux du templating client: alléger les requêtes en faisant transiter des données sérialisées et non préformatées.

Généralement, je charge jusqu'à 500ko max de données par requête client. Au delà, je pagine côté serveur. Ce qui n'empêche pas de garder un cache des données côté client et de venir charger progressivement le reste à la demande de l'utilisateur.

Pour votre histoire de milliers de bindings à gérer, on a déjà trouvé une solution à ce problème, ça s'appelle la pagination virtuelle : http://www.ag-grid.com/angular-grid-virtual-paging/ ; c'est le meilleur des mondes, plein de données sur une seule page mais un DOM et des bindings réduit à la portion de la page que voit l'utilisateur sur son écran.

[Marco46]

Lorsque l'on ouvre un classeur EXCEL, on ouvre parfois un fichier aussi gros qu'une Base de Données NO SQL.
(De plus j'ai déjà vu Excel charger une BDD avec Odbc)

Oublie surtout pas de m'envoyer un mp le jour où tu arriveras à charger plusieurs tera octets de data dans un excel ou dans n'importe quel logiciel sur ta machine.

[frfancha]

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é.

Home page d'angular 2:

Angular 2 solves the core challenges in mobile web performance.

[Marco46]

Home page d'angular 2:

Angular 2 solves the core challenges in mobile web performance.

Il pourrait bien être en Angular 42 que ça changerait que dalle, vouloir afficher un tableau de 1500 items sur un smartphone c'est débile.

[Logan Mauzaize]

Angular 2 solves the core challenges in mobile web performance.

Premièrement, il manque un peu la proposition qui vient avant :

With Angular Universal for server-side rendering and Web Workers for smooth scrolling and transitions,

. Cela change un peu la donne car cela signifie qu'ils ont ajoutés des fonctionnalités facultatives pour améliorer les performances (en l’occurrence du pré-rendering et du multithreading) ; et non qu'il est impossible d'écrire une app mobile et performante avec Angular.

Deuxièmement, cela indique simplement que les performances sur mobile est un problème d'ordre générale et non spécifique à Angular.

Troisièmement, c'est un discours marketing pour dire avec Angular2 vous n'aurez pas de problèmes de performance, sous-entendu vous en aurez avec la concurrence.

Quatrièmement, beaucoup (la plupart ?) des fonctionnalités décrites ne sont pas spécifiques à la branche 2.X d'Angular mais s'applique également à la version 1.X

Bon on pourrait surement continuer longtemps dans l'analyse pour comprendre cette phrase mais je pense que cela suffira ?

[frfancha]

https://medium.com/@ericclemmons/jav...fc4#.f5dtzvwuj

[Stéphane le calme]

Google voudrait des versions d'Angular 2 qui fonctionnent avec plusieurs technologies côté serveur,
de Java à Python

En décembre dernier, la version 2.0 d'Angular, le framework JavaScript libre et open source développé par Google, a atteint sa phase bêta. Grâce à une réécriture et une réarchitecture, le framework a alors gagné en vitesse (multiplié par huit comparé à la version 1 d'après Google), embarqué de meilleures capacités de développement mobile.

Via un tweet, Brad Green, un directeur de l'ingénierie chez Google responsable d'AngularJS, a annoncé que Google est sur le point de proposer une version beaucoup plus légère et un peu plus rapide d'Angular 2. « Le "un peu plus rapide" sera disponible dans deux semaines environ et le "beaucoup plus léger" dans un mois et demi à peu près », a-t-il assuré. Il a rajouté que « nous avons cette grosse conférence en mai et nous voudrons sans doute que les choses soient faites avant », faisant probablement allusion à l'édition 2016 de la conférence dédiée aux développeurs Google I/O (qui aura lieu du 18 au 20 mai) ou alors de la conférence NG qui aura lieu un peu plus tôt (du 4 au 6 mai).

Au départ, la version finale était attendue pour la fin de l'année dernière, par la suite elle a été repoussée au début de cette année. Aussi, pour aider la communauté à suivre les différentes avancées faites sur le framework, Google va publier un dispositif de suivi de fin de bêta qui sera constitué d'un « ensemble de jalons, afin que les utilisateurs puissent voir où nous en sommes ».

En clair, pendant le reste de la période où le framework est en bêta, Google compte bien apporter des améliorations à Angular. Au programme une interface de ligne de commande, des animations, mais également une amélioration des API.

« Angular 1 était un framework, quelque chose que vous pouviez juste mettre sur une page web et la faire fonctionner », explique-t-il. « Avec Angular 2, nous nous sommes attaqués au point de vue « plateforme de capacités ». Nous faisons toujours le framework, mais nous améliorons notre capacité à gérer plusieurs langages. Nous avons l'intention d'avoir des versions qui fonctionnent avec plusieurs technologies serveur, de Java à Python ».

Si Angular 2 est de plus en plus populaire comme le confie Kenny Yates, un des architectes du projet, qui assure qu'il voit une légère hausse dans le nombre d'entreprises qui communiquent avec lui au sujet d'Angular 2, que va-t-il arriver à la version précédente ? Cette version sera supportée encore pour au moins un an comme l'explique le responsable du projet : « ce que nous avons dit sur le sujet est que nous allons supporter Angular 1 jusqu'à ce que la majorité des utilisateurs viennent à utiliser Angular 2 ».

Green a expliqué que cette année, les efforts pour aider les utilisateurs à migrer leurs applications (si cela s'avère logique) ou en créer de nouvelles sur Angular 2 seront multipliés : « nous avons un canal Slack spécial : ils lancent beaucoup de débats eux-mêmes, mais ils peuvent nous alerter afin que nous puissions leur donner toutes les informations dont ils ont besoin pour la communauté, et nous travaillons de concert avec eux à la résolution de problèmes ».

Source : New Stack

[Marco46]

J'ai pas encore check la version 2 mais quelqu'un pourrait m'expliquer le coup du serveur ?

Normalement le cas usuel c'est un serveur qui expose des endpoints fournissant du json. En quelle techno ce serveur est écrit, qu'on soit en 1 ou en 2, on ne le sait pas forcément et ça n'a pas d'importance.

Du coup je comprends pas trop ...

[p5yk0]

Avec Angular Universal tu peux effectuer le rendu de ta page côté serveur.
Ça permet entre autres un chargement des pages plus rapide sur les terminaux les moins puissants (mobiles), une meilleure visibilité du point de vue des moteurs de recherche, une génération automatique de screenshot de ton appli, etc...

[yann2]

Avec Angular Universal tu peux effectuer le rendu de ta page côté serveur.
Ça permet entre autres un chargement des pages plus rapide sur les terminaux les moins puissants (mobiles), une meilleure visibilité du point de vue des moteurs de recherche, une génération automatique de screenshot de ton appli, etc...

En gros, ce qu'on fait depuis des années avec PHP, JSP, ASP ou, soyons fous, CGI

[SylvainPV]

Ça permet entre autres un chargement des pages plus rapide sur les terminaux les moins puissants (mobiles), une meilleure visibilité du point de vue des moteurs de recherche, une génération automatique de screenshot de ton appli, etc...

Il faut nuancer la question du chargement des pages plus rapide: c'est uniquement vrai pour la première page, première visite. Et le gain de temps est perçu sur l'affichage initial de contenu, et non sur le temps de chargement total de l'application. Une fois le bundle JS chargé, Angular reprend les rênes et on retrouve les avantages du templating client en termes de réactivité et de temps de chargement.

ce qu'on fait depuis des années avec PHP, JSP, ASP ou, soyons fous, CGI

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

[Invité]

J'ai vu une vidéo des gens de firebase ou ils montrent qu'ils ont conservé le génial 3 way binding, avec angular 2.0. evidemment, la syntaxe est un peu désagréable... Par rapport à Angular 1.x.

Etant totalement fan de cette solution incroyable (Couplage AngularJs 1.5 + Firebase AngularFire en 3 way binding, ou tout est automatique, il n'y a plus rien à faire hormis créer des champs dans l'app, il n'y a plus de back end...C'est fantastique ! Si on supprime un truc dans l'app, c'est automatiquement supprimé sur Firebase hi hi hi ! sans rien coder du tout !)
Gain de temps de production = 75%

il se pourrait qu'un jour je m'intéresse à Angular Js 2.0, mais bon, ça a l'air compliqué aux premiers abords par rapport au 1.x qui est incroyablement logique et sympa.



Sans parler qu'on peut customiser le 1.x avec du caching de modèle lors d'un ng-repeat : https://github.com/kamilkp/angular-vs-repeat , et qu'on peut désactiver le 2 way binding avec {{::maVariable}}.

Pour les select HTML, angularJs est trop génial, il mets tout à jour tout seul, dans une application, c'est tellement utile !

Je suis sur que ma piste de garder le 2 way binding seulement pour les select html est une super piste, en effet, un ng-repeat en soi même était trop puissant, c'est à dire qu'il implique la notion d'infini, à la notion de capacité, ce qui est intrinséquement sujet à problèmes . Seulement moi , je n'en voit que pleins d'avantages !

Si google faisait attention,Firebase pourrait devenir le nouvel Oracle, en noSql. Moi j'ai envie de miser sur cette techno, mais ils ont pas intérêt à merder ou faire n'importe quoi. ce qui me rendrait malade, ce serait qu'ils virent la librairie AngularFire ou le désactive à cause d'angular 2.0!

Une montée de version n'est pas forcément synonyme de gain de productivité ou de réelles avancées, ça peut aussi être une rétrogradation alors qu'on pensait faire le contraire.

Bon ce qui et un peu génant c'est que les modèles Json sont conservés chez eux quoi... Grrr... Mais eux ont les moyens de veiller à la sécurisation de leurs système.
Mais bah, y'a pas mal d'équivalents à Firebase, de plus j'ai découvert hier une api d'authentification en ligne qui a l'air pas mal.

MA COMPARAISON ANGULAR JS 1.5 VS 2.0:

Angular Js 1.5 c'est :

. Le modèle : Ben...Mes données quoi...,
. La vue : Ben le code Html c'est tout... Ben ça fait que afficher mes données quoi...,
. Le controleur : Les opérations mathématiques sur mes données quoi....

Un Concept logique, facile à comprendre pour tout le monde, super structuré, qui fait qu'on peut collab sur des apps, et comprendre le code des autres devs du monde entier.

Angular Js 2.0 c'est :
."Les components", un truc super obscur qu'on comprends pas, que pas grand monde ne semble pouvoir expliquer.
.Des classes qu'on sait pas trop pourquoi qu'faut en mettre... Alors qu'avant le bousin marchait très bien.
. et du typing de variables en JS ... alors que les champs conditionnent déjà le type des variables en JS dans une petite app. Le typing de vars c'est pour les progs en C++ pour les robots, ou les apps de fou qui pilotent les avions, pour le web, non merci, surtout en noSql.

Mais bah c'est que mon avis si ça se trouve il est bête