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

Le , par Stéphane le calme, Chroniqueur Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Marco46 Marco46 - Modérateur 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 ...
Avatar de p5yk0 p5yk0 - Futur Membre du Club https://www.developpez.com
le 03/03/2016 à 18:16
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...
Avatar de yann2 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
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 03/03/2016 à 22:18
Citation Envoyé par p5yk0  Voir le message
Ç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.

Citation Envoyé par yann2
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
Avatar de - https://www.developpez.com
le 03/03/2016 à 23:19
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
Avatar de yann2 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
Avatar de SylvainPV 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...
Avatar de - https://www.developpez.com
le 04/03/2016 à 2:01
Citation Envoyé par yann2 Voir le message
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 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...).
Les frameworks css comme foundation 6.0 permettent de créer des sites responsives sur téléphone Mobile 5 pouces et qui rendent très bien sur ordinateur de bureau, tout s'adapte automatiquement.
Il n'y a pas 2 versions de l'appli ou du site web. C'est le framework css qui fait tout le travail.
Sinon, bah,comparer Php-Sql-base relationnelles, pour moi quand tu vois AngularJs 1.x-AngularFire-noSql à côté, ben , la différence c'est la facilité, la puissance, la flexibilité extrême, l'ingéniosité est du côté du couple Angular-AngularFire noSql, bref le resultat des dernières recherches anglo saxonnes en matière de web, une technologie qui te permet de faire ce que tu veux, un peu similaire à node.js+ expressjs mais bien plus facile , pourvu qu'ils continuent.
Avatar de youtpout978 youtpout978 - Membre expert https://www.developpez.com
le 04/03/2016 à 9:39
Citation Envoyé par SylvainPV Voir le message
...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.
Avatar de SylvainPV 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.
Contacter le responsable de la rubrique Accueil