IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

210PARTAGES

5  0 
Angular 2.0 est disponible en version bêta
Le framework JavaScript annonce un gain de vitesse impressionnant

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

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.


Page AngularJS pour commencer à apprendre la nouvelle version

Source : Blog AngularJS

Et vous ?

Utilisez-vous ce framework JavaScript ? Que pensez-vous de cette nouvelle version ?

Voir aussi

AngularJS : les développeurs dans le trouble au sujet de la version 2.0, quel va être l'avenir du framework JavaScript de Google ?
AngularJS : faut-il aller vers la version 2.0 ? Un point sur les coûts de migration vers cette nouvelle version
Angular 2 sera basé sur TypeScript : convergence de AtScript et TypeScript 1.5, c'est une collaboration entre Google et Microsoft
Vous avez lu gratuitement 6 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de yann2
Membre expérimenté https://www.developpez.com
Le 03/03/2016 à 19:31
Citation Envoyé par p5yk0 Voir le message
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
6  1 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 03/03/2016 à 17:48
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 ...
4  0 
Avatar de wchegham
Membre habitué https://www.developpez.com
Le 20/03/2016 à 13:38
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.
3  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 08/05/2016 à 15:50
Citation Envoyé par devwebsympa Voir le message
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...aving-angular/

Malheureusement, raconter n'importe quoi n'est pas une infraction sur ces forums, c'est juste fatiguant pour tout le monde.
5  2 
Avatar de yann2
Membre expérimenté https://www.developpez.com
Le 04/03/2016 à 0:12
Citation Envoyé par SylvainPV  Voir le message
[/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
2  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 04/03/2016 à 10:39
@youtpout978: oui, les crawling bots ne sont pas encore au point pour indexer correctement les SPA. C'est le principal intérêt des solutions dites "isomorphic js" ou "universal js" selon moi, ça et le 1% d'utilisateurs avec JS désactivé. Je n'ai jamais concrètement mis en place une solution de ce genre, je me contente de détecter les crawlers avec une liste d'User Agent connus et de les rediriger vers un fichier HTML statique bourré de mots-clés. Jusqu'ici ça fait l'affaire, mais j'espère que les crawlers sauront mieux gérer AJAX dans les années à venir.

Pour les ralentissements, le data-binding d'Angular 1 est assez gourmand, je suis en train d'écrire un article à ce sujet. Il y a eu de nets progrès avec Angular 2. Mais si ça en vient à crasher le navigateur, c'est qu'il y a un problème dans le code, je ne vois pas d'autre explications.
2  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 05/03/2016 à 17:20
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
2  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 24/09/2016 à 0:07
@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é.
2  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 26/09/2016 à 20:22
C'est le cas


https://github.com/angular/angular/milestones
2  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 04/03/2016 à 1:41
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...
1  0