La version finale d’Angular 2.0 désormais disponible

Par offline j'entend l'utilisation d'un fichier manifest (d'ont je viens de voir sur mdn que l'utilisation est devenue obsolète :/).
Contrairement au Ctrl-S, les pages restent dans le navigateur se qui a de nombreux avantage.

Avec l'utilisation de manifest dynamique (pas spécialement simple a mètre en place) on peut forcer la régénération des pages en caches a partir du serveur et/ou préparer une utilisation (d'une partie) d'un site en offline, par contre une fois en offline, sois on se contente d'une navigation entre les pages en caches, soit on switch vers une navigation en JS (voir un mixe des deux), il est évident que sans connexion aux serveur les pages ne peuvent plus être charger depuis celui-ci.

Ce cas d'utilisation peut paraitre assez spécifique, mais il répond parfaitement a certain besoin.

Aussi générer complètement une pages coté serveur n'empêche pas que la suite de la navigation sois uniquement géré en JS (sans pour autant dupliquer de la logique), après tous dépend de se que l'on dev comme application.
C'est d'ailleurs comme sa que l'on fonctionnais à la base en faisant de l'Ajax, le serveur génère une page, la page évolues grâce aux JS (en proposant éventuellement une mini-navigation via des "sous-vue"), mais des qu'on passe à une autre fonctionnalité du site, le serveur génère une autre page avec un contexte js différent.

Bonjour

Citation:

---

Envoyé par SylvainPV

C'est une vulgarisation bien éloignée de la réalité. On parle ici de contenu dynamique, mais dynamique par rapport à quoi ? Dans la majorité des cas, il variera selon les utilisateurs. Donc tes 1000 clients auront 1000 rendus différents. Et la précompilation des templates serveur existe aussi pour les templates client, donc l'argument ne tient pas.

---

... Tu peux reprendre ce que je dis dans son contexte. Je sais très bien de quoi je parle et quand je dis que tu peux cacher c'est que tu peux cacher ! Voici le contexte initial :

Citation:

---

Envoyé par yann2

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

---

J'ai mis en gras dans le texte pour que ce soit plus facile à trouver :D

Je reprend l'exemple twitter. Justin Bieber écris un tweet. Un follower de Justin Bieber veut afficher le tweet. Le serveur twitter calcule le DOM à afficher, le cache et l'envoie à ce follower. Pour les follower suivants, il suffira d'envoyer le DOM en cache. C'est plus clair, là ? Je ne vois pas où je fais de la vulgarisation ?!!

Citation:

---

Envoyé par Marco46

Et donc je réitère, où est le problème ?

---

Ben écoute, je t'invite à lire pourquoi twitter est revenu sur du rendu côté serveur. Ils ont pris comme base de mesure le temps nécessaire pour que l'utilisateur puisse lire le premier tweet. Dans l'article ils disent avoir réduit ce temps de 80% en moyenne. Franchement si tu n'arrives pas à comprendre pourquoi en faisant moins d'opérations on a une application plus rapide je ne vois pas comment continuer le débat...

Citation:

---

Envoyé par Marco46

J'ai beaucoup de mal à voir comment tu vas faire pour dev une webapp de gestion (cas standard) avec un cache serveur des vues ne serait-ce que d'un point de vue intégrité des données ça va être le vietnam rapidement.

---

Pour le cache tu le gères comme n'importe quel cache. Il peut avoir une durée de vie, il peut être invalidé, tu peux demander si ton cache est toujours valide. En pratique et personnellement, je le baserai sur les en-têtes HTTP standard. OK, ça envoie une requête mais elle retournera juste 304 NOT MODIFIED. Tu peux aussi cacher côté client dans ton app JS mais du coup il faut pouvoir le prévenir qu'il n'est plus valide (plusieurs solution, le client le demande au serveur via requête (donc là, ça revient au même que d'utiliser les en-têtes HTTP mais en moins standard...), le cache a une durée de vie, websocket, etc.) Au niveau intégrité, si je reprend l'exemple d'un tweet, tu mappes le DOM du tweet avec son ID et sa VERSION. A noter que tu as exactement le même genre de problème quand tu caches des données :aie:

Citation:

---

Envoyé par Marco46

Ton analyse se tient sur une webapp qui a un contenu statique qui ne change que très très peu. Alors là oui tu peux raisonnablement cacher certaines vues. Sur ce cas ok, reste la latence du réseau (importante en mobile).

Mais la plupart du temps sur des webapps le contenu est dynamique et il est évolue trop rapidement pour se permettre de cacher des vues pré-interprétées. Et là le rendu côté client explose littéralement le rendu côté serveur.

---

C'est OK, si le client peut simuler la logique du serveur... c'est ce qu'on disait avant. Je suis désolé, mais j'ai plus l'impression qu'il y a plus de cas où tu es de toutes façons obligés de soumettre tes modifications au serveur que de cas où tu peux rester tout seul dans ton coin sur ton application cliente. Par exemple, ce forum tu pourrais en faire une version offline mais l'intérêt est vachement limité et c'est juste de la lecture seule... (ou alors je n'imagine pas le bordel). Pour le mobile, il faut, évidemment, éviter de trop utiliser le réseau mais, il faut également éviter de trop utiliser le processeur. Ils sont de plus en plus puissants mais ils consomment aussi beaucoup d'énergie.

Un autre article, réalisé par un fan d'angular visiblement : https://medium.com/@jeffwhelpley/use...f7d#.3pyzgibb9 la partie 4 c'est ce que j'essaie de vous faire rentrer dans le crâne...

Après, il faut voir ce que vous appelez "rendu côté client". Pour moi le rendu c'est "Comment les données s'affichent". On est bien d'accord ? Si je veux afficher une horloge sur une application web, je ne vais pas demander le rendu de l'horloge au serveur toutes les secondes mais je vais modifier la valeur directement dans le DOM (uniquement la valeur, pas le DOM (rendu) en lui même). C'est pareil, si je veux afficher un message à l'utilisateur en JS sans faire un aller/retour au serveur, je vais juste changer la valeur dans le DOM pour y mettre mon message. Ce n'est pas parce que le rendu et côté serveur qu'on ne peut pas faire ce genre de choses côté client.

J'avais déjà lu cet article de Medium, il est très juste. Les arguments sur la SEO et le load time première page première visite sont à mes yeux ce qui justifie des solutions comme Angular Universel ou autre. Curieusement, le point 4 est le seul avec lequel je ne suis pas d'accord. De ma propre expérience, passer à un rendu client s'est toujours traduit par un gros gain de performance au temps de transition entre les pages, principalement parce que ce temps de rendu est négligeable comparé à la latence réseau, et qu'une vue HTML pèse logiquement plus lourd que sa structure JSON sous-jacente (si on considère que les templates sont mis en cache, bien entendu, donc pas le cas première page première visite). J'en parle dans mon article sur le templating client.

Pourquoi ce désaccord sur la question des performances ? Je pense simplement qu'on ne travaille pas sur le même genre d'application. Mettre en cache du DOM est impensable pour nos projets pros, qu'il s'agisse de JSP ou d'Angular. Nous faisons principalement des plates-formes web pour les entreprises, et tous les utilisateurs ont des rendus différents selon le contenu, leurs permissions, le contexte et les données qui changent tout le temps. Ces mêmes utilisateurs ont aussi de bons PC et smartphones, pas des foudre de guerre non plus, mais de la génération actuelle. Je veux bien concéder que ça puisse marcher pour Twitter (ils mettent en cache des partials et non le DOM complet, puisqu'il y a sur un tweet beaucoup d'infos dynamiques, likes, retweets, heures relatives etc..). Mais par rapport à nos besoins actuels, ce n'est clairement pas (plus ?) pour nous. J'ai bossé avec JSP et PHP comme tout le monde et je ne pense pas revenir en arrière faire des pages serveur. Ne serait-ce que pour la compensation de latence, qui est devenu un must-have pour la réactivité de l'UI selon moi, et qui serait bien trop délicate à reproduire avec une surcouche JS sur du rendu server side.

Enfin, vu qu'on a fait le tour des arguments et que personne n'a jusque ici réussi à convaincre l'autre, j'imagine que chacun a sa part de vérité et qu'il sera difficile de trouver un consensus. Je vais donc en rester là pour ma part. Libre à vous de continuer ce débat server vs client, mais ça m'arrangerait si vous pouviez rester courtois. Je n'aime pas bosser le week-end :mrgreen:

Un super post en Anglais qui compare les syntaxes de 9 frameworks Js sur un simple exemple de binding de data:

http://engineering.paiza.io/entry/2015/03/12/145216

Aurelia a l'air sympa. Angular js1.x aussi évidemment... C'est le plus simple et clair à comprendre pour un débutant, il est génial, même sans ng-repeat.

Angular 2.0 .. Hem :ptdr: Mieux vaut ne rien dire...:oops::(:( Meuhh le code à rallonge, c'est pas trop mon trip là tu voieeees ....:mouarf::ptdr: ou alors j'suis pas assez intelligent pour coder comme cela, ce qui est aussi possible, faut que j'essaye quand même.

J'vais p'tet continuer avec le 1.x et/ou Aurelia un moment moi ...:lol: (Genre 5 ans ...)

Ben... Ractive.js et Vue.js ont pas l'air mal non plus en fait ... Si angular Js1.x n'est plus dispo (Ce qui n'est pas possible) ou que j'éprouve de réels pbs de perfs, je passerais sur Aurelia, avec les classes, j'men fout.

Windows 2000 était bien, windows millenium une regression, ça me fait penser un peu à...

Je vais en faire rager quelques un, mais moi j'adore la notation $scope... Je fais même pas du controller As !:ptdr: J'adore la sensation de travailler "dans le scope", par rapport à une vue dans angular js1.3 :P


Pièce jointe 203167

Hello,
ravi de voir qu'on commence à parler d'Angular 2 (tout doucement mais certainement) ^^

Je suis contrib et membre de l'équipe Angular 2 Universal. Effectivement, un des problèmes traités par Universal c'est le chargement de la première page. Mais pas que, il y a aussi la SEO et l'expérience utilisateur et surtout la gestion des "states" lors du chargement de l'application.

Je parle de tout ça dans mon talk : http://slides.com/wassimchegham/angular2-universal

Pour le moment, on se concentre principalement sur Nodejs. Mais on a en tête d'autres technos comme PHP, Java ou encore .Net. Ou n'importe quelle platform avec un bridge JS/V8 ;)

Jeff et Patrick donneront un talk à la ng-conf sur l'avancement du projet, si vous voulez en savoir plus.

Citation:

---

Envoyé par wchegham

Pour le moment, on se concentre principalement sur Nodejs. Mais on a en tête d'autres technos comme PHP, Java ou encore .Net. Ou n'importe quelle platform avec un bridge JS/V8 ;)

---

Le slide explique le pourquoi initial (réduire la durée de bootstrap) mais il n'explique pas le comment.

Dans le comment je ne comprends pas pourquoi il y a besoin de supporter divers langages backend.

Si je comprends bien le problème il s'agit de pré-interpréter côté serveur l'état initial que doit avoir l'index.html et la 1ère vue affichée à l'utilisateur afin de s'économiser le temps de bootstrap d'angular.

Du coup ça signifie que ça doit être à un moteur javascript (via phantomjs par exemple) de générer ce 1er état ?

Pour le support nodejs ok il faut bien un contexte d'exécution mais quel rapport avec Python, Java, etc ... D'autant que la webapp n'est pas forcément installée sur un serveur d'application, elle est souvent déployée sur un apache en statique.

L'utilisation du framework Angular 2 avec d'autres langages est en effet très intéressant ! Allez voir le projet Angular2Boot qui permet de programmer Angular 2 en Java 8, cela donne une très bonne expérience de développement !
Le site est là : http://lteconsulting.fr/angular2boot/

Le succès d'angular 1 a été provoqué par le développeur, qui a créé son nouveau framework, Aurélia.
La raison du succés aux usa fut le concept MVC pour Javascript et le 2 way binding(même si c'est pas forcément terrib').

Moi je vais donc suivre le développeur à l'origine du succès d'angular 1 et je feras donc du aurélia.

Si c'est pour faire des syntaxes complexes et des classes angular2 comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

<div> <input type="text" [value]="newTodoTitle"> <button (click)="addTodo()">+</button> <tab-container> <tab-pane title="Good kids"> <div [ng-repeat|todo]="todosOf('good')"> <input type="checkbox" [checked]="todo.done"> {{todo.title}} <button (click)="deleteTodo(todo)">X</button> </div> <tab-pane> </tab-container> </div>

---

Alors autant se taper du JavaWeb anglo-saxon qui date des années 1990, du temps ou les connexions internet étaient en 54 ko, au moins, ce langage est réputé.

Si l'on conceptualise bien, Angular 2 détruit le concept MVC ET le 2 way binding, qui furent les raisons du succès de angular 1 , en Inde par exemple. En plus, il faut maitriser 3 nouveaux langages pour l'utiliser (Typescript, etc ...). Les personnes venant de Php ne voudront pas passer la dessus par exemple, il n'y aura pas la magie existante pour le 1.0

Citation:

---

Envoyé par devwebsympa

Le succès d'angular 1 a été provoqué par le développeur, qui a créé son nouveau framework, Aurélia.
La raison du succés aux usa fut le concept MVC pour Javascript et le 2 way binding(même si c'est pas forcément terrib').

Moi je vais donc suivre le développeur à l'origine du succès d'angular 1 et je feras donc du aurélia.

---

Rob Eisenberg n'a jamais bossé sur Angular 1... Il bossait sur Durandal avant, et a joint l'équipe d'Angular 2 en février 2014 : http://eisenbergeffect.bluespire.com/leaving-angular/

Malheureusement, raconter n'importe quoi n'est pas une infraction sur ces forums, c'est juste fatiguant pour tout le monde.

Citation:

---

Envoyé par SylvainPV

Rob Eisenberg n'a jamais bossé sur Angular 1... Il bossait sur Durandal avant, et a joint l'équipe d'Angular 2 en février 2014 : http://eisenbergeffect.bluespire.com/leaving-angular/

Malheureusement, raconter n'importe quoi n'est pas une infraction sur ces forums, c'est juste fatiguant pour tout le monde.

---

Désolé mais il est parti du projet angular 2, et vu la nouvelle syntaxe pour le moins spéciale, on comprends pourquoi:mouarf: Du coup, Aurelia est mieux, même si c'est de l'anglo saxon.

Tien, j'ai trouvé un autre exemple de syntaxe moquée par un dev anglo-saxon, il la deteste :

Code:

---

1 2 3 4 5

<li *ngFor="#hero of heroes" [class.selected]="hero === selectedHero" (click)="onSelect(hero)"> <span class="badge">{{hero.id}}</span> {{hero.name}} </li>

---

Heu c'est quoi le * là, une blague ? et le # et ils pensent que les gens vont utiliser ça ? Mouah ah :mouarf: Autant faire de vieilles applications des années 1999 en spring si c'est ça, ou en aurélia. De toute façon, on peut très bien garder angular js1.x pendant 5 ans encore, c'est du freeware et les tonnes de librairies qui ont été développées sur github sont disponibles.. Personne ne se servira de cette nouvelle syntaxe. Une théorie serait que Microsoft qui ne vends plus de logiciels, géné par le succès de AngularJs1.x qui est gratuit , a tout fait pour détruire la simplicité du framework, c'est tout à fait possible ce genre de choses.
Lorsqu'on veut créer des applications, ce qui est important c'est de savoir si de bonnes librairies existent pour aller plus vite, or AngularJs1.x en dispose de pleins. je doute qu'il y en ait en Angular 2.
En plus aurelia gère intelligemment le 2 way binding.

Une seule réponse : https://hackernoon.com/why-learning-...c8a#.scv6cd6hq

Angular v2 n'est même pas compatible v1.

Vous imaginez une équipe de 5 devs qui font de l'Angular v1, tout un site ?
Allez calcul :
- une personne à 1700 nets / mois = 3400 à faire rentrer dans la boîte (oui, CIPAV + URSAFF + CRG + CRDS etc etc, donc le double)
- 4 devs = 3400 x 4 = 13600 / mois
- on suppose qu'ils sont bons et que tout se passe bien : un bon site = 6 mois de devs = 13600 x 6 = 81600.

Et après avoir investi 81600 €, on voit que tout le boulot fait n'est plus compatible v1 <> v2 ? Qu'il faut repasser du temps pour avoir au final le même site, les mêmes fonctionnalités mais juste qu'il soit compatible v2 ?
C'est pour ça que j'ai refusé de consacrer du temps à mettre en place des cours pour AngularJS, et donc d'étudier de près ce framework.
L'environnement NodeJS/JavaScript (cela inclut Angular) est simplement l'environnement le moins stable jamais crée.

Allez-y gaiement les downers et haters (bref les KKTD derrière leurs claviers) !

End of story.

Salut,

Par curiosité, c'est quoi Angular en quelques mots ? Qu'est-ce que cela apporte de plus ?

Merci.

Citation:

---

Envoyé par SylvainPV

Les ressources que j'utilise :
https://github.com/timjacobi/angular2-education
https://egghead.io/series/angular-2-fundamentals
et bien sûr la doc toute neuve pour la beta : https://angular.io/docs/js/latest/index.html

---

Merci. J'ai regardé quelques vidéos et je me suis demandé quel est cet EDI que l'auteur utilise et qui m'a l'air bien ? Par exemple dans cette vidéo : https://egghead.io/lessons/angular-2...d-to-angular-2

Est-ce WebStorm ?

@Beginner: oui c'est Webstorm, dans son mode présentation. Pour Angular ça va prendre plus que quelques mots. Essaie le quickstart comme ça tu te feras une idée. Pour un débutant qui souhaite s'initier aux frameworks client, je recommanderai plutôt de partir sur quelque-chose de plus accessible comme Backbone, pas le plus récent mais avec un code source exceptionnellement concis et lisible. Une fois à l'aise avec les concepts classiques des frameworks JS, tu auras tout le loisir ensuite d'essayer d'autres frameworks et de choisir celui qui te plaît le plus pour lequel tu es payé.

Merci je vais voir ça... De toute façon ce n'est pas pour maintenant, pour l'instant je préfère d'abord apprendre ce que je peux du JS...

Citation:

---

Envoyé par SurferIX

Une seule réponse : https://hackernoon.com/why-learning-...c8a#.scv6cd6hq

Angular v2 n'est même pas compatible v1.

Vous imaginez une équipe de 5 devs qui font de l'Angular v1, tout un site ?
Allez calcul :
- une personne à 1700 nets / mois = 3400 à faire rentrer dans la boîte (oui, CIPAV + URSAFF + CRG + CRDS etc etc, donc le double)
- 4 devs = 3400 x 4 = 13600 / mois
- on suppose qu'ils sont bons et que tout se passe bien : un bon site = 6 mois de devs = 13600 x 6 = 81600.

Et après avoir investi 81600 €, on voit que tout le boulot fait n'est plus compatible v1 <> v2 ? Qu'il faut repasser du temps pour avoir au final le même site, les mêmes fonctionnalités mais juste qu'il soit compatible v2 ?
C'est pour ça que j'ai refusé de consacrer du temps à mettre en place des cours pour AngularJS, et donc d'étudier de près ce framework.
L'environnement NodeJS/JavaScript (cela inclut Angular) est simplement l'environnement le moins stable jamais crée.

Allez-y gaiement les downers et haters (bref les KKTD derrière leurs claviers) !

End of story.

---

Je ne comprends pas, le lien parle de quelqu'un qui développe une application en prenant une version Alpha d'un framework qui démarre une nouvelle version majeure, bien sur qu'il faut s'attendre à des breaking changes jusqu'à la version finale, c'est l'esprit de la version. C'est comme s'il faisait tourner ses war sur Java 9 en cours de dev alors que Jigsaw n'est pas finalisé et que tous les TU ne passent pas.

Il n'est de plus pas nécessaire de toujours vouloir migrer une application, il faut voir l'intérêt technique et économique avant. Dans le cas d'Angular, la version 1 sera encore maintenue en parrallèle de la 2. Concernant l'upgrade, des développements sont en cours pour effectuer une migration de la part d'Angular : https://angular.io/docs/ts/latest/guide/upgrade.html

Après, le processus d'upgrade n'est pas encore finalisé, il est donc préférable d'attendre encore et ne pas se lancer dans un truc alpha pour du code de production, ça reste la base.

Après je suis bien évidemment d'accord que le monde Js évolue très très vite, avec beaucoup d'évolutions. Dans ma boite, on a démarré aucune application sur Angular 2 pour le moment. On y viendra mais pas tout de suite, surement pendant 2017 mais je ça m'étonnerait que quoi que ce soit se passe à ce niveau avant la fin de l'année, hormis des formations, on a plusieurs appli de prod qui tournent sur des versions différentes d'AngularJS 1, certaines utilisent le $scope, d'autres les components avec Angular 1.5 et ça se passe très bien.

J'ai vécu la même expérience que l'auteur de ce billet, à démarrer une appli Angular 2 sur la beta0 et à la mettre à jour en parallèle des développements jusqu'à la finale. Du coup je comprends ce qu'il ressent.

Oui ça a été une vraie galère de suivre ces mises à jour et oui, c'était une mauvaise décision de partir sur une beta. Ceci dit il y a un mécontentement légitime, qui est le nombre de breaking changes qui ont survenu après la première release candidate. L'équipe Angular a été vivement critiquée pour ça, cf: https://www.reddit.com/r/angularjs/c...ase_candidate/

Le passage en RC a été effectué très rapidement (bâclé ?) et juste avant la ng-conf. Ce qu'on a ressenti en tant que développeur, c'est d'assister à un pur coup marketing qui ne tienne pas compte de la réalité de l'état des développements. D'où les changements radicaux qui ont suivi dans la phase RC (nouveau routeur, nouveaux formulaires, NgModules etc.). Ces changements ont coûté beaucoup de temps et d'argent aux entreprises qui avaient fait confiance dans l'appellation Release Candidate pour démarrer leurs développements à ce moment là.

Ils sont maintenant passés en semver, ce qui devrait arranger les choses j'espère.

Citation:

---

Envoyé par SylvainPV

Le passage en RC a été effectué très rapidement (bâclé ?) et juste avant la ng-conf. Ce qu'on a ressenti en tant que développeur, c'est d'assister à un pur coup marketing qui ne tienne pas compte de la réalité de l'état des développements. D'où les changements radicaux qui ont suivi dans la phase RC (nouveau routeur, nouveaux formulaires, NgModules etc.). Ces changements ont coûté beaucoup de temps et d'argent aux entreprises qui avaient fait confiance dans l'appellation Release Candidate pour démarrer leurs développements à ce moment là.

Ils sont maintenant passés en semver, ce qui devrait arranger les choses j'espère.

---

Bah non, s'ils étaient sur semver ça voudrait dire que la prochaine version de angular 2 contenant un breaking change serait versionnée en 3.0.0. Ou alors j'ai manqué quelque chose ?

C'est le cas :)

Pièce jointe 221253
https://github.com/angular/angular/milestones

Alors ça c'est une bonne nouvelle :)

Curieux de voir comment ils vont gérer leur communication avec angular 2 en version 3.0.0 :aie:

Citation:

---

Envoyé par SurferIX

Une seule réponse : https://hackernoon.com/why-learning-...c8a#.scv6cd6hq

Angular v2 n'est même pas compatible v1.

Vous imaginez une équipe de 5 devs qui font de l'Angular v1, tout un site ?
Allez calcul :
- une personne à 1700 nets / mois = 3400 à faire rentrer dans la boîte (oui, CIPAV + URSAFF + CRG + CRDS etc etc, donc le double)
- 4 devs = 3400 x 4 = 13600 / mois
- on suppose qu'ils sont bons et que tout se passe bien : un bon site = 6 mois de devs = 13600 x 6 = 81600.

---

Tu es loin de la réalité dans ton calcul déjà un dev c'est 300€ par jour mini pour un client, 400€ en province pour un dev expérimenté voir facile 500€ à Paris (tu pars de 5 dev et tu calcul pour 4), avec les prix Parisiens tu peux facile en avoir pour 300 000€ en 6 mois pour 5 dev.