Discussion :

[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?

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

[lechtitseb]

Pour ceux que ça intéresse, j'ai créé un générateur de projets qui supporte Angular 2 beta 0: https://www.npmjs.com/package/generator-modern-web-dev
Le build utilise un autre projet que j'ai créé: https://www.npmjs.com/package/modern-web-dev-build

Ca support TypeScript, ES2015 (via Babel), la minification, le génénération de bundles pour la production (css, js, ...), les sourcemaps, le rechargement à chaud, les checks de style et de qualité de code, etc

[rattlehead]

Un truc qui n'a rien à voir. Par pitié essayer de faire un effort dans l'utilisation de sa et ça et de se et ce, s'il vous plaît
Dans des pavés ça commence à être dure à lire.
Merci les gars :-)

[frfancha]

à être dure à lire

En effet très dure...

Nan je rigole moi aussi cela m'arrache les yeux. Pas par snobisme orthographique, juste parce que c'est difficile à comprendre (et donc malheureusement cela déprécie l'argumentation).

[Sodium]

Perso je n'ai pas l'impression qu'on bouscule mes habitudes puisque j'utilise depuis des années NPM, bien avant Angular 2. Personne ne nous oblige à utiliser NPM, si autant de gens choisissent de publier dessus c'est que c'est simple, gratuit et terriblement pratique. C'est la seule plateforme que je connaisse qui permette de publier un module en une seule ligne de commande. En ce sens, ça ne m'étonne pas qu'il soit devenu si populaire, au même titre que Github.

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.

[SurferIX]

[B][SIZE=4]

• un support pour les animations ;
• un support I18n et L10n ;
• plus de documentation, en particulier sur l’utilisation d’ES5/ES6 ;
• une meilleure performance de démarrage et d’exécution ;

Rien que ce qui manque est simplement vital pour une appli en 2015 : "il est pas encore correctement multilingue, il est lent au démarrage et à l’exécution, il est mal documenté... bref je voulais m'y mettre, mais merci pour cette info : je vais encore attendre un peu...

[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

[yann2]

[/COLOR]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

Certains regretteront quand même que le codebase (ça fait un peu destroy tous ces mots anglais ) en question soit en javascript. (oui, bon je sais, angular 2 préconise l'utilisation de Typescript, d'ailleurs moi aussi je préconise l'utilisation de Typescript )

On peut quand même rigoler de voir que les gars qui ont dit qu'il faut stopper le rendu côté serveur parce que ce n'est pas user-friendly s'amusent à intégrer du rendu côté serveur pour régler des problèmes de performance. Laisse moi profiter de l'ironie de la situation surtout qu'ils nous le vendent comme une feature révolutionnaire !!

Sinon, personnellement, qu'il y ait du rendu côté client ne me gêne pas, hein Surtout que la radicalisation de cette approche a eu le gros avantage de populariser REST. Rien n'empêche d'avoir une architecture RESTful avec une couche de rendu côté serveur, soit dit en passant.

De plus, je ne crois pas que toutes les applications web nécessitent l'utilisation d'un angular ou équivalent. Tout dépend du besoin. Si c'est juste pour mettre des messages de validation, je ne vois pas vraiment l'intérêt, à part peut être pour faire so 2016 ? (j'espère que ce n'est pas ce que sous entendait ton message) ... il faut rester pragmatique. D'ailleurs, il y a d'autres techniques pour faire du single page application avec rendu côté client : un client lourd. Firefox, par exemple, est un client lourd (et il arrive à se mettre à jour automatiquement en plus, dingue !) ! Et qu'on ne me dise pas qu'une appli web va être accessible directement via mobile/tablette/PC/grille-pain. Un téléphone mobile ne s'utilise pas comme un PC donc, dans les faits, on est soit obligé de développer deux clients, soit essayer de faire un mixte au sein d'un seul client en réorganisant le DOM en fonction de la taille de l'écran (je trouve que la deuxième solution peut vite donner du code horrible à maintenir d'ailleurs...).

Enfin, sur ces derniers mots, il y a aussi des gens qui aiment le web ce pour quoi il est fait à la base. Le web qui est accessible à tous (notamment aux malvoyants) pour un coût dérisoire. Ce web responsive pour 0 €. Ce web ou les boutons précédent et suivant du navigateur font ce qu'on attend d'eux ! Ce web où tu ne télécharges pas plusieurs méga-octets de données pour lire un article ! C'est ce web là : http://motherfuckingwebsite.com/. (tu vois, perso, je suis même resté bloqué en 1995, les gifs en moins )

Peace

[SylvainPV]

Développer deux clients pour un même site web, ou un client lourd pour consommer un service qui a sa place sur le web, c'est précisément ce que je cherche à éviter à tout prix. J'ai écrit ce bouquin pour essayer de convaincre les gens d'adopter l'approche One Web. Deux interfaces pour un même service, c'est fragmenter les usages et faire un cloisonnement d'idées. Qui s'étonne encore de voir un utilisateur de smartphone préférer la version desktop d'un site plutôt que la version dédiée mobile ? Qui pense encore à une nette séparation entre mobile et desktop à l'heure des tablettes hybrides ? Quant au client lourd, il n'est logiquement pas accessible à tous, que la restriction vienne de l'OS lui-même ou des droits de l'utilisateur. Je t'invite à lire l'intro de mon livre qui détaille davantage mon point de vue sur le sujet.

On peut parfaitement faire une SPA légère, responsive et accessible. Le coup des boutons de navigation qui ne fonctionnent pas, c'est un vieux cliché des SPA bâclées. Justement, mon projet pro actuel est la refonte complètement d'une RIA anciennement en Nuxéo vers du Angular 2 et une architecture micro-service. Et bien les boutons de navigation précédent/suivant ne fonctionnaient pas avec l'appli Nuxeo à cause de divers problèmes avec la gestion de session, et ce malgré que tout le rendu soit côté serveur. La refonte va permettre de régler ça, sans qu'il y ait un rapport direct avec le passage à un routeur JavaScript. Peu importe les choix techniques, s'il y a de mauvais développeurs ou du travail bâclé, l'utilisateur en paiera les conséquences.

Je ne dis pas d'utiliser Angular à tout bout de champ, d'ailleurs je trouve beaucoup de défauts à ce framework. Mais étant spécialisé front-end, quand je vois un projet partir sur du PHP/JSP/ASP, je ne peux pas m'empêcher de lister dans ma tête tous les avantages du rendu côté client qui seront perdus ou difficilement rattrapables.
...Usage offline, on oublie.
...Compensation de latence, niet.
...Résistance aux downtime serveur, aux pertes momentanées de connexion, nada.
...Optimiser la taille des requêtes, only data on wire, nope.
...Changer la langue du site sans rafraîchir la page, haha tu rêves !
...et je pourrais continuer encore longtemps...

[youtpout978]

...Changer la langue du site sans rafraîchir la page, haha tu rêves !
...et je pourrais continuer encore longtemps...

Il y a aussi des problèmes, le SEO pas encore vraiment bien géré, le rewriting suivant la langue assez complexe à gérer, la pauvreté du JS (pour le moment) nous obligeant à intégrer toujours plus de librairie.

J'ai développer 2 sites depuis 0 dernièrement en AngularJS et j'ai rencontré ces problèmes, après il existe des outils pour ça tel que prerender pour le SEO par exemple ... mais disons qu'avec une technologie serveur on aurait pas à s'en soucier (on peut toujours coupler les 2).

Et aussi arrivé à un moment le navigateur commence à avoir un peu de mal, quand il ne crache pas tout simplement sur la page, si la personne a un PC peu performant ou un mobile ça peut commencer à se voir les ralentissements.

Ce que je veux dire par la c'est que le Full Js n'a pas que des avantages, sur un projet précédent on avait un site Asp MVC avec les templates en Angular JS, et je trouve que c'est une bonne alternative, on peut profiter des avantages de ASP pour le code-behind le routage, et d'Angular pour le rendu côté client.

[yann2]

Développer deux clients pour un même site web, ou un client lourd pour consommer un service qui a sa place sur le web, c'est précisément ce que je cherche à éviter à tout prix. J'ai écrit ce bouquin pour essayer de convaincre les gens d'adopter l'approche One Web. Deux interfaces pour un même service, c'est fragmenter les usages et faire un cloisonnement d'idées. Qui s'étonne encore de voir un utilisateur de smartphone préférer la version desktop d'un site plutôt que la version dédiée mobile ? Qui pense encore à une nette séparation entre mobile et desktop à l'heure des tablettes hybrides ? Quant au client lourd, il n'est logiquement pas accessible à tous, que la restriction vienne de l'OS lui-même ou des droits de l'utilisateur. Je t'invite à lire l'intro de mon livre qui détaille davantage mon point de vue sur le sujet.

On peut parfaitement faire une SPA légère, responsive et accessible. Le coup des boutons de navigation qui ne fonctionnent pas, c'est un vieux cliché des SPA bâclées. Justement, mon projet pro actuel est la refonte complètement d'une RIA anciennement en Nuxéo vers du Angular 2 et une architecture micro-service. Et bien les boutons de navigation précédent/suivant ne fonctionnaient pas avec l'appli Nuxeo à cause de divers problèmes avec la gestion de session, et ce malgré que tout le rendu soit côté serveur. La refonte va permettre de régler ça, sans qu'il y ait un rapport direct avec le passage à un routeur JavaScript. Peu importe les choix techniques, s'il y a de mauvais développeurs ou du travail bâclé, l'utilisateur en paiera les conséquences.

Je ne dis pas d'utiliser Angular à tout bout de champ, d'ailleurs je trouve beaucoup de défauts à ce framework. Mais étant spécialisé front-end, quand je vois un projet partir sur du PHP/JSP/ASP, je ne peux pas m'empêcher de lister dans ma tête tous les avantages du rendu côté client qui seront perdus ou difficilement rattrapables.
...Usage offline, on oublie.
...Compensation de latence, niet.
...Résistance aux downtime serveur, aux pertes momentanées de connexion, nada.
...Optimiser la taille des requêtes, only data on wire, nope.
...Changer la langue du site sans rafraîchir la page, haha tu rêves !
...et je pourrais continuer encore longtemps...

J'espère que c'est une blague... rendu côté serveur ça ne veut pas dire que les mecs ne savent pas faire une XmlHttpRequest ou utiliser JQuery. Ca ne veut pas dire "Eviter JavaScript à tout prix". Rendu côté serveur, ça veut dire générer du DOM côté serveur.

"...Usage offline, on oublie" --> OK, très certainement
"...Compensation de latence, niet." ---> Pourquoi ? Comme je fais du rendu côté serveur je n'ai pas le droit de développer du javascript pour afficher "Votre message a été envoyé" ou ce que tu veux d'autres ?
"...Résistance aux downtime serveur, aux pertes momentanées de connexion, nada." --> OK, très certainement
"...Optimiser la taille des requêtes, only data on wire, nope." ---> Du DOM zippé, ça ne pèse pas lourd, hein... j'aimerai bien connaitre la différence entre du JSON zippé et du DOM zippé, tiens
"...Changer la langue du site sans rafraîchir la page, haha tu rêves !" ---> Pourquoi ? Tu crois qu'on est obligé de recharger la page parce qu'on fait du rendu côté serveur ? (mais honnêtement, dans l'exemple, ça ne me choque pas qu'une page se recharge sur changement de langue).
"...et je pourrais continuer encore longtemps..." ---> Ah ?

Pour que ce soit clair, rendu côté serveur ça ne veut pas dire une requête ==> une page. Tu peux très bien faire une requête qui te retourne un bout de page et qui est injecté dans ton DOM côté client (avec du code javascript, oui). Et, là, le gros avantage, c'est que ton client il fait rien. Côté serveur, tu peux faire du cache sur du HTML plutôt que sur du JSON, donc tu ne fais pas le rendu à chaque fois que 1000 clients demandent la même chose. Tu le fais une fois. Avec du rendu côté client, tu le fais 1000 fois côté client...


Et désolé, mais les sites que je consulte sur PC qui sont prévus pour tablette/mobile m’horripilent... voyez le genre d'abus où ça mène : http://www.developpez.net/forums/d15...e-trouver-job/. En gros, des sites qui perdent des fonctionnalités car optimisés pour une utilisation tablette (ou alors ils pensent que les gens sont trop bêtes ). Alors, oui, on est d'accord, c'est plus une question de choix de conception que de technologies