Angular 2.0 est disponible en version bêta
Le framework JavaScript annonce un gain de vitesse impressionnant
Le 2015-12-16 12:36:24, par Michael Guilloux, Chroniqueur Actualités
Mise à jour le 15 / 09 / 2016 : La version finale d’Angular 2.0 désormais disponible, l’équipe Angular évoque déjà les prochaines nouveautés et améliorations du framework JavaScript
Deux ans après avoir été annoncé, Angular 2.0 est désormais disponible en version stable. La réarchitecture du framework JavaScript libre et open source développé par Google apporte des gains de performances énormes. Angular 2.0 devrait également permettre de développer les applications plus rapidement et les rendre plus maintenables. Mais la rupture avec la version 1 inquiète de nombreux développeurs. Pour faciliter la migration vers Angular 2, Google devrait donc publier un outil open source, déjà utilisé en interne, pour aider les développeurs à migrer semi automatiquement leurs applications, même en cas de changements de rupture. Il existe par ailleurs un guide de Telerik pour aider les développeurs à « convertir » leurs connaissances Angular 1 vers Angular 2.
L’équipe Angular évoque déjà les nouveautés et améliorations qui pourraient arriver bientôt dans le framework. Il s’agit entre autres des Web Workers qui devraient quitter la phase expérimentale, mais également d’Angular Material 2, une suite de composants de material design pour Angular 2. L’équipe prévoit aussi de travailler plus sur les animations et d’améliorer le support pour plus de langages, y compris Java et Go. Les développeurs pourront également disposer de plus de guides et exemples pour différents cas d’utilisation spécifiques d’Angular 2.
Sources : Blog AngularJS, Changelog (GitHub), Blog Juri Strumpflohner
Deux ans après avoir été annoncé, Angular 2.0 est désormais disponible en version stable. La réarchitecture du framework JavaScript libre et open source développé par Google apporte des gains de performances énormes. Angular 2.0 devrait également permettre de développer les applications plus rapidement et les rendre plus maintenables. Mais la rupture avec la version 1 inquiète de nombreux développeurs. Pour faciliter la migration vers Angular 2, Google devrait donc publier un outil open source, déjà utilisé en interne, pour aider les développeurs à migrer semi automatiquement leurs applications, même en cas de changements de rupture. Il existe par ailleurs un guide de Telerik pour aider les développeurs à « convertir » leurs connaissances Angular 1 vers Angular 2.
L’équipe Angular évoque déjà les nouveautés et améliorations qui pourraient arriver bientôt dans le framework. Il s’agit entre autres des Web Workers qui devraient quitter la phase expérimentale, mais également d’Angular Material 2, une suite de composants de material design pour Angular 2. L’équipe prévoit aussi de travailler plus sur les animations et d’améliorer le support pour plus de langages, y compris Java et Go. Les développeurs pourront également disposer de plus de guides et exemples pour différents cas d’utilisation spécifiques d’Angular 2.
Sources : Blog AngularJS, Changelog (GitHub), Blog Juri Strumpflohner
La version 2.0 d’Angular, le framework JavaScript libre et open source développé par Google, vient d’atteindre la phase bêta. Ce qu’il faut noter dans cette nouvelle version, c’est une réécriture et une réarchitecture du framework qui ont permis d’introduire de nombreux avantages. Gain de vitesse impressionnant et de meilleures capacités de développement mobile sont ce qui caractérise Angular 2.0 dont la version finale est prévue au début de l’an prochain.
Angular 2.0 est beaucoup plus rapide qu’Angular 1. La vitesse du framework aurait été multipliée par huit, d’après Brad Green, directeur de l’ingénierie de Google en charge du framework. Ce gain de performance peut être observé au niveau du rendu et de la mise à jour des pages. En effet, la nouvelle version fournit un support pour accélérer le chargement initial des pages grâce à un prérendu côté serveur. Elle introduit encore une compilation hors-ligne et unique qui permet d’accélérer le démarrage des applications.
À cela, il faut ajouter un algorithme pour une détection ultra rapide des changements, que ça soit pour les grandes applications de bureau ou pour les applications sur les appareils à faible mémoire comme les téléphones mobiles. Comme autre expérience introduite avec Angular 2.0, vous pourrez exécuter tout votre code et une bonne partie du framework dans un processus séparé via des Web Workers, a expliqué Brad Green dans un billet le mois dernier. Au-delà des applications web pour bureau, Angular 2 a été conçu de sorte à bien fonctionner également pour les applications mobiles web, hybrides et natives.
Comme l’explique le directeur de l’ingénierie de Google chargé d’Angular, la phase bêta signifie que le framework peut être utilisé pour construire avec succès de grandes applications. Les développeurs peuvent donc dès maintenant envisager de construire des applications avec Angular 2 ou mettre à niveau leurs applications Angular 1 existantes. Google propose pour cela deux bibliothèques : ngUpgrade et ngForward.
La première bibliothèque permet aux développeurs de commencer à écrire des composants Angular 2 dans leurs applications Angular 1 existantes, et ensuite remplacer les composants Angular 1 au fur et à mesure qu’ils sortent de nouvelles versions de leurs applications. ngUpgarde facilite ainsi la transition entre les deux versions en permettant de tirer parti des avantages d’Angular 2 tout en conservant les fonctionnalités d’Angular 1. Les développeurs pourront par exemple profiter de l’amélioration de la vitesse et des API d’Angular 2 immédiatement alors qu’ils remplacent des composants Angular 1 pendant les sorties de nouvelles versions de leurs applications.
En ce qui concerne la deuxième bibliothèque ngForwrad, elle cible les développeurs qui, pour une raison ou une autre, voudront éviter d’avoir à la fois des bibliothèques Angular 1 et 2 exécutées simultanément dans leurs applications. ngForward vous permet d’écrire des applications Angular 1 en utilisant les conventions et styles d’Angular 2. Les développeurs pourront ainsi s’habituer à la nouvelle version, et auront beaucoup moins de travail à faire lorsqu’ils seront prêts à migrer vers Angular 2.
La bêta d’Angular 2.0 annonce aussi de manière imminente la sortie de la version finale. Pour cela, l’équipe de développement a déjà abordé la dernière ligne droite pour apporter quelques améliorations supplémentaires et faciliter l’apprentissage de la nouvelle version. On pourra citer dans leur liste de tâches les points suivants :
- réduire la taille des binaires Angular ;
- rendre la CLI (Command Line Interface) Angular utilisable tout au long du processus de développement ;
- développer une API qui répond aux besoins des développeurs pour le Component Router ;
- 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 ;
- un guide de style architectural ;
- amélioration des tests unitaires et des tests de bout en bout ;
- plus de support pour le web mobile et les applications mobiles installables ;
- des composants Material Design pour Angular 2 ;
- une plateforme d’outils pour un support d’IDE avancé ;
- un meilleur support pour ECMAScript 6 et le compilateur Babel.
Source : Blog AngularJS
Et vous ?
Voir aussi
-
SodiumMembre extrêmement actifCa a l'air assez prise de tête de s'y mettre en tout cas.
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.le 17/12/2015 à 16:05 -
rattleheadMembre expérimenté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 :-)le 21/12/2015 à 15:13 -
yann2Membre expérimentéle 03/03/2016 à 19:31
-
Marco46Expert éminent séniorJ'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 ...le 03/03/2016 à 17:48 -
voyager57Membre du ClubIls essayent un peu de pousser l'utilisation de TypeScript, or j'aurais aimé utilisé le simple JS. J'attend de voir si cela ne pose pas de problème pour utiliser ce framework.le 16/12/2015 à 15:48
-
goldberggMembre avertiLe rendu coté serveur sert aussi au référencement des page par google (entre autre) avec l'utilisation des ancres commençant par "#!" par exemple.le 17/12/2015 à 9:01
-
Logan MauzaizeRédacteur/ModérateurParce 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.
Cela ne prouve toujours qu'une chose : ton cas d'utilisation ne correspond pas à un développement mobile.
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 :
- 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.
- 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 ?
- 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. - 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.
- 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. - 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. - 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. - 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.
- Sauf qu'un framework peut en dépendre d'autres.
- 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 - Non tu ne seras pas obligé mais l'avantage c'est que tu peux déjà presque le faire
- 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.
- 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'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.
- Je pense pas que quelqu'un est dit cela ... Mais il y a tout de même toujours un minimum à connaître.
- 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.
- 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. - 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.
- Soit c'est mal dit, soit c'est idiot (désolé mais voir juste ci-dessous).
- Simplement parce que la solution visual studio n'est pas industrialisable et intégrable dans une chaîne de livraison.
- 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"). - 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é. - 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. - 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. - 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.
- 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.
- 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.
- 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.
- 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. - 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. - 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.le 14/01/2016 à 14:50 -
SylvainPVRédacteur/ModérateurLa 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-...irtual-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.le 15/01/2016 à 1:22 -
wcheghamMembre habitué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.le 20/03/2016 à 13:38 -
SylvainPVRédacteur/ModérateurRob 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...aving-angular/
Malheureusement, raconter n'importe quoi n'est pas une infraction sur ces forums, c'est juste fatiguant pour tout le monde.le 08/05/2016 à 15:50