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

61PARTAGES

5  0 
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

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

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