Discussion :

[Michael Guilloux]

Angular 4.0 est disponible
cette nouvelle version du framework JavaScript de Google promet des applications plus petites et plus rapides

Attendue depuis le 1^er mars, conformément à un calendrier établi par Google, la version stable d’Angular 4.0 vient enfin d'être mise à la disposition des développeurs. Avant d'entrer dans les nouveautés de cette version, l'équipe Angular annonce aux développeurs qu'Angular 4 est compatible avec Angular 2.x.x pour la plupart des applications, histoire de les rassurer après l'expérience douloureuse de rupture de compatibilité entre Angular 1 et Angular 2 ; ce qui a été causé par la réécriture totale du framework avec de nouvelles API et de nouveaux modèles.

Concernant les nouveautés de cette version, les développeurs doivent s’attendre à des applications Angular plus petites et plus rapides. Cela a été rendu possible grâce à deux changements essentiels. D’abord, des modifications au code AOT généré permettent de réduire la taille du code de vos composants d’environ 60 % dans la plupart des cas. Cela est plus notable pour les applications plus complexes. Avec les releases candidates, des développeurs ont également indiqué que la migration vers Angular 4 leur a permis de voir une réduction, de plusieurs centaines de kilo-octets, de la taille de leurs paquets en production.

Pour les développeurs qui n’utilisent pas les animations dans leurs applications, les gains seront encore plus notables. Les animations ont désormais leur propre paquet et ont donc été retirées du paquet @angular/core. Cela signifie que le code supplémentaire qu’elles généraient ne sera plus inclus dans vos paquets de production. Votre code sera donc plus léger.

En passant à Angular 2, le framework de Google a été réécrit avec TypeScript, le surensemble JavaScript typé de Microsoft. L’un des objectifs de l’équipe Angular pour cette nouvelle version était donc de passer de TypeScript 1.8 à TypeScript 2.1 ou même 2.2. Cela a été fait avec Angular 4 et permet du coup au framework de Google de profiter de certains avantages. Passer à la version plus récente de TypeScript signifie en effet une meilleure vérification de type dans une application et de meilleures performances pour ngc, le compilateur pour les templates Angular.

Entre autres nouveautés, on note encore qu'Angular Universal, le projet qui permet aux développeurs d'exécuter Angular sur un serveur, est également à jour et s’aligne sur la nouvelle version du framework de Google. Vous trouverez bien d’autres petites nouveautés sur le blog Angular.

Angular 4 est la première version majeure du framework JavaScript de Google après les changements annoncés en décembre dernier. Pour ceux qui auraient manqué un épisode, il n'y a pas eu d'Angular 3. Google a préféré passer directement à la version 4.0 pour diverses raisons. Cela s'explique notamment par la volonté d’aligner tous les paquets Angular sur le même numéro de version. Ce qui sera plus facile à maintenir et aidera à éviter toute confusion à l'avenir. Il faut en effet noter que les bibliothèques Angular de base sont hébergées dans un seul dépôt GitHub, et elles étaient toutes à la version v2.3.0 en décembre dernier, sauf le paquet @angular/router qui était à la version v3.3.0. Faire un bond vers Angular 4 permet donc juste d'aligner tous les paquets sur le même numéro de version.

Google prévoit de sortir une version majeure de son framework tous les six mois, ce qui annonce donc la sortie d'Angular 5.0 pour septembre ou octobre prochain. Entre-temps, plusieurs mises à jour seront apportées à la nouvelle version du framework.

Source : Blog Angular

Et vous ?

Que pensez-vous de cette nouvelle version ?
Quelles nouveautés appréciez-vous le plus ?

Voir aussi :

Il n'y aura pas d'Angular 3, Google prévoit de passer à la version 4.0 prévue pour mars 2017 et qui devrait être compatible avec Angular 2
NativeScript 3.0 : le framework de développement mobile cross-platform avec JavaScript prévoit le support d'Angular 4, sa sortie est prévue en avril

[grunk]

Passage de Angular 2.4 à 4.0 sans problème de mon coté.

la nouvelle syntaxe if/else dans les template peut vraiment être pratique !

Il n'ya à que le passage à angular-cli 1.0 qui m'a posé problème avec ng build --prod qui plantait lamentablement alors que ng serve marche correctement.
La faute aux membres du component utilisé dans les templates html qui doivent désormais être en public au lieu de privé. (bon courage si vous avez plusieurs dizaines de components).

Je trouve le rythme effréné de mise à jour compliqué à suivre. Difficile de passer une semaine sans devoir mettre à jour quelque choses si on veux pas être largué

[hotcryx]

Je ne pense pas qu'on doit suivre toutes les releases.
On n'en finirait plus avec Bootstrap, Jquery...

[marc.collin]

c'est certain, mais il y a aussi d'autre framework plus simple je trouve tel que smart client ou bien vuejs (qui progresse très rapidement).

[dukoid]

faut évoluer sinon on se fait dépasser....

[marc.collin]

je rajouterais que plus tu attends de mettre à jour tes libs... plus ça sera difficile.

[dukoid]

exactement marc. suivez l'évolution, passez un peu de temps pour mettre à jour et vous en gagnerez pour plus tard

[Invité]

C'est quoi cette mode de je passe du de la version 2 à la version 42 ... pourquoi ? Exemple avec windows (il y a d'autres exemples)

[grunk]

C'est quoi cette mode de je passe du de la version 2 à la version 42 ... pourquoi ? Exemple avec windows (il y a d'autres exemples)

Pour le coup ca se justifie par le fait que tout les modules de angular étaient en version 2.x.x sauf 1 qui était en 3.x.x .
Il était donc assez logique de tout normaliser en 4.x.x à la prochaine version majeure.

Je ne pense pas qu'on doit suivre toutes les releases.
On n'en finirait plus avec Bootstrap, Jquery...

Sur un projet en production je veux bien. Mais sur un projet en développement , c'est quand même dommage de prendre 6 mois à 1 ans de dette technique au moment de la sortie du projet.

[T`lash]

C'est quoi cette mode de je passe du de la version 2 à la version 42 ... pourquoi ? Exemple avec windows (il y a d'autres exemples)

Sachant que pour Windows Microsoft avait une raison on ne peut plus valable : de nombreux systèmes testent la version de Windows pour adapter leur fonctionnement, et il est courant de comparer le début de la chaîne à "Windows 9" pour savoir s'il s'agit de Windows 95 ou 98. Cela peut paraître étrange de tenir compte de versions aussi anciennes, mais il y a encore beaucoup de logiciels en fonction datant du début des années 2000 qui font ce genre de tests.

Il n'était donc pas possible de passer de Windows 8.1 à Windows 9.

[sitexw]

Il ne faut pas s'attarder sur les version de release (0.0.x), je ne compte même pas le nombre de version que j'ai sauté ^^ !
J'ai même dans certain cas sauté des version mineurs (0.x.0), pour vous dire... Après, la rétrocompatibilité reste globalement bonne avec Angular (>2).

Sinon, ça annonce de bonnes nouvelle tous ça =)

[dj_mez]

Bonjour,

Y a-t-il un comparatif des frameworks JS actuels et lesquels ont le plus d'avenir ?

Merci

[dukoid]

le classement varie selon les pays.

API et framework :
1. jQuery
2. angularJS
3. reactJS
4. ember vue backbone ...
5. Angular

En France, aux niveaux des offres d'emplois, les entreprises recherchent souvent des dév. angularJS. c'est un peu normal vu que ce framework existe depuis un bout de temps...

[Marco46]

La plupart des intervenants sur ce fil devraient peut être songer à lire la définition de semver. C'est le système de versionning utilisé par Angular.

Il faut également comprendre que AngularJS et Angular sont deux frameworks différents et distincts. Passer de AngularJS 1.x vers Angular est clairement une migration importante. Passer de Angular x.y.z a Angular x+1.y.z est seulement une montée de version d'une dépendance.

Concernant la vitesse des montées de version, c'est comme ça le développement moderne front. Ça bouge tout le temps, si l'application a une durée de vie importante il est critique d'effectuer les montées de version et les migrations au fil de l'eau le plus tôt possible. Il faut éviter de prendre de la dette technique car comme certains l'ont déjà mentionné, cela coute moins cher de résoudre ces problèmes rapidement plutôt que de laisser tout s'accumuler et de chercher à tout faire d'un coup.

[pterrat]

La plupart des intervenants sur ce fil devraient peut être songer à lire la définition de semver. C'est le système de versionning utilisé par Angular.

Il faut également comprendre que AngularJS et Angular sont deux frameworks différents et distincts. Passer de AngularJS 1.x vers Angular est clairement une migration importante. Passer de Angular x.y.z a Angular x+1.y.z est seulement une montée de version d'une dépendance.

Concernant la vitesse des montées de version, c'est comme ça le développement moderne front. Ça bouge tout le temps, si l'application a une durée de vie importante il est critique d'effectuer les montées de version et les migrations au fil de l'eau le plus tôt possible. Il faut éviter de prendre de la dette technique car comme certains l'ont déjà mentionné, cela coute moins cher de résoudre ces problèmes rapidement plutôt que de laisser tout s'accumuler et de chercher à tout faire d'un coup.

C'est très bien résumé. Au final, il est intéressant de se tenir à jour assez régulièrement. Il ne faut cependant pas oublier que le but final est de satisfaire des clients et que il s'en foutent de la technologie. Est-ce qu'il est primordial de passer de Angular 2 à Angular 4? Au final, on s'aperçoit que les différences entre les deux sont uniquement basés sur les performances. Ces améliorations de performance ne seront d'ailleurs pas super visible si on développe avec des bonnes guidelines.

@dj_mez Selon moi, les frameworks avec le plus d'avenir sont ceux qui se vendent le mieux auprès des clients, et les clients sont rassurés par des grands groupes => React ou AngularJS ou Angular 2

[Marco46]

Il ne faut cependant pas oublier que le but final est de satisfaire des clients et que il s'en foutent de la technologie.

Ça n'a absolument aucun rapport.

Est-ce qu'il est primordial d'effectuer les montées de versions et migrations de techno ? Oui sous peine de devoir réécrire entièrement à moyen terme. C'est la pérennité de l'application qui est en cause, par pérennité je n'entends pas l'exécution mais la capacité à effectuer des évolutions. C'est tout à fait différent.

Tu parles de clients donc tu écris l'application pour quelqu'un, c'est son appli donc c'est son problème de gérer le financement du paiement de la dette technique pour être à même de la faire évoluer dans le temps. Si le client veut une appli en "one shot" et ne compte pas la faire évoluer, pas de soucis, c'est son problème. Il ne faut pas ensuite venir pleurer si la moindre évolution sur un besoin non prévu à l'avance coute un bras.

Le post de demon66 montre une ignorance des enjeux.

[demon66]

@dukoid "exactement marc. suivez l'évolution, passez un peu de temps pour mettre à jour et vous en gagnerez pour plus tard"

Non pas obligatoirement au contraire. On ne gagnera rien plus tard étant donné que l'on se retrouve dans une spirale infernale où l'on passe la moitié du temps à mettre à jour au lieu de programmer. Et ça, cela impacte considérablement le travail à effectuer sur des applications en entreprise.
C'est le problème qui a été rencontré dans d'autres nombreux framework php notamment comme sous Symfony. Où les mises à jour deviennent tellement récurrente que cela devient un nid à problème "dans le future".
Donc on ne gagne à aucun moment dans le temps c'est plutôt l'inverse. C'est le constat "objectif" qu'on fait beaucoup de développeur ou chef de projet et je suis de cet avis.
Les mises à jours peuvent être nombreuses sur certains paquets, les bugs peuvent le devenir tout autant et le risque est de se retrouver à corriger des bugs qu'il n'y avait pas à l'origine et qui font perdre un temps considérable si l'on ajoute à cela, la veille techno dédié aux paquets d'un système (php et javascript par exemple) + le suivie de la doc des nouvelles releases + les tests des nouveaux paquets + correction de bugs potentiels.
Ce n'est pas gérable dans le temps au contraire. Donc si une appli tourne bien, on ne met à jour que les paquets de correctifs concernant la sécurité.