AngularJS est mort ! Vive Angular !
publié leSous ce titre troll et racoleur, se cache la nouvelle fraîche de la sortie de la version finale d’Angular 2eme édition. En effet le 15 septembre 2016, Google annonçait la sortie de leur nouveau framework dans le but d’endiguer le flot de développeurs se lançant corps et âmes sur React.
Finale vous avez dit finale ?
Selon la Team Angular “Finale” désigne une stabilité validée sur un large panel de Use Cases et un framework optimisé pour la productivité du développeur, performant et léger. Personnellement j’aurais rajouté la présence d’une documentation complète et à jour, mais Google est habitué au fait de nous donner ce dernier point bien après le lancement de leurs frameworks, d’autant que pour le coup la documentation Angular est tout à fait honorable.
Premier point perturbant, aucun script de release dans le package, pas de angular.js ou de angular.min.js. Autrement dit impossible de démarrer un projet from scratch en téléchargeant simplement la release. Certes ce point est corrigé par la CLI, outil pratique pour les projets Angular. Pardon je rectifie : indispensable pour les projets Angular vu qu’il n’existe aucun autre moyen propre d’amorcer un projet. On commence à sentir la nécessité de se marier avec un éco-système imposé.
ng new
Vous l’avez compris, je n’aime pas qu’on m’impose mes outils, cela ne veut pas dire que je n’aime pas ces outils. Angular-CLI fait donc partie de la release finale d’Angular et vous allez devoir travailler avec lui, cependant c’est un outil exceptionnel et Open-Source. Cela signifie que si la façon dont votre projet est généré ne vous plaît pas, vous pouvez faire un fork de l’outil et l’adapter à votre propre cas. Par défaut vous démarrez avec un outil qui vous amorce votre code, l’analyse statique tslint, la mécanique de tests unitaires, la mécanique de tests end-to-end, le module loader (webpack), un mode de développement avec Hot Reload, un mode de packaging/livraison. Il ne manque que l’intégration automatique sur le serveur d’intégration continue, mais on ne peut pas demander cela à un outil générique.
Le résultat d’un ng new MonProjet est un petit bébé de 243,5 MB essentiellement en node_modules de dépendances et outils.
Par contre il y a encore des progres à faire :
Could not start watchman; falling back to NodeWatcher for file system events.
Visit http://ember-cli.com/user-guide/#watchman for more info.
Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
- configuration has an unknown property 'tslint'. These properties are valid:
object { amd?, bail?, cache?, context?, devServer?, devtool?, entry, externals?, loader?, module?, name?, dependencies?, node?, output?, plugins?, profile?, recordsInputPath?, recordsOutputPath?, recordsPath?, resolve?, resolveLoader?, stats?, target?, watch?, watchOptions? }Attention cette erreur est du à la beta23 de webpack pas à l’équipe cli directement, dont on saluera l’extraordinaire réactivité car ils ont fix le bug quasi instantanément : https://github.com/angular/angular-cli/issues/2234. On met à jour et on recommence :
08:43:cedric@NG2\>../tools/node_modules/.bin/ng serve
Could not start watchman; falling back to NodeWatcher for file system events.
Visit http://ember-cli.com/user-guide/#watchman for more info.
** NG Live Development Server is running on http://localhost:4200. **
3289ms building modules
31ms sealing
0ms optimizing
0ms basic module optimization
97ms module optimization
1ms advanced module optimization
9ms basic chunk optimization
0ms chunk optimization
2ms advanced chunk optimization
0ms module and chunk tree optimization
103ms module reviving
5ms module order optimization
2ms module id optimization
3ms chunk reviving
0ms chunk order optimization
8ms chunk id optimization
58ms hashing
0ms module assets processing
114ms chunk assets processing
2ms additional chunk assets processing
0ms recording
0ms additional asset processing
1320ms chunk asset optimization
790ms asset optimization
22ms emitting
Hash: 517d555b0a7373505b00
Version: webpack 2.1.0-beta.22
Time: 5869ms
Asset Size Chunks Chunk Names
main.bundle.js 2.83 MB 0, 2 [emitted] main
styles.bundle.js 10.2 kB 1, 2 [emitted] styles
inline.js 5.53 kB 2 [emitted] inline
main.map 2.88 MB 0, 2 [emitted] main
styles.map 14 kB 1, 2 [emitted] styles
inline.map 5.59 kB 2 [emitted] inline
index.html 473 B [emitted]
assets/.npmignore 0 B [emitted]
Child html-webpack-plugin for "index.html":
Asset Size Chunks Chunk Names
index.html 2.81 kB 0
webpack: bundle is now VALID.
Impeccable !
Small Payload and Performance
Un petit ng build --prod pour livrer notre application (qui n’a subi aucune modification) génère un dossier dist contenant le script main de 833KB(189KB zippé) pour une appli qui ne fait rien, ça fait cher le time to first byte. Toutefois avec le lazy loading inclu dans Angular, cette taille initiale est pratiquement la même quelque soit votre application, cependant j’espère que les futures versions vont poursuivre la cure d’amaigrissement commencée. (c’est dans leur roadmap : Even more speed and payload size improvements)
L’AOT compilation à la rescousse
Malheureusement pas encore arrivé dans la CLI, vous allez devoir le faire à la main, cependant profits are real, DAMN REAL ! avec plus de 50% de réduction de la taille initiale (oui les 833KB mentionnés plus haut fondent de moitié). Cette évolution récente (Aout) diminue non seulement le poids de votre application mais augmente également la performance de l’exécution de celle-ci. Les gains ne sont pas aussi spectaculaires (environ 8 %) mais existent et c’est un enjeu suffisant pour vouloir le mettre dès le départ sur tous vos projets angular2, d’autant que c’est inclu dans le tarif d’achat du framework : 0€ & 1 ligne de commande (Espérons juste que cela arrive rapidement dans la CLI).
Developer Productivity
Tout ce que vous avez pu lire jusqu’à présent dans cet article pourrais vous faire penser que je n’aime pas Angular, et c’est … FAUX. Je lui reproche son obésité c’est vrai, mais la team fait beaucoup d’efforts pour corriger ce fait, en contrepartie de ce petit problème Angular est simplement à ce jour le meilleur framework de développement composant à ma connaissance (Certaines personnes qui me connaissent viennent probablement de tomber de leur chaise). Cela tient en assez peu de choses en fait : les annotations. Certes elles viennent de TypeScript et non d’Angular, mais ce sont bien celles fournies par ce dernier qui rendent le développement d’applications extrêmement véloce. Pour le moment aucune autre librairie n’a, à ma connaissance, exploité TypeScript à ce niveau. Cela fait entrer le développement web dans une autre dimension : la cours des grands. Les annotations sont entièrement dédiées à la productivité du développeur et c’est exactement ce qu’elles parviennent à faire dans Angular, toute la magie du framework s’utilise à travers ces métadonnées que l’on place sur nos composants permettant de se focaliser sur le code UTILE, le seul qu’un développeur devrait avoir à écrire.
Angular fourni dans sa version finale :
- Les composants (TY Captain Obvious)
- Les directives
- Les pipes
- Le module de communication HTTP (XHR et JSONP)
- Le router capable de faire du lazy loading
- Des formulaires avancés
- Le tooling pour tester
Et ce n’est que le début avec notament une future API web worker encore expérimentale et d’autres évolutions encore à venir.
Conclusion
Il va falloir rester réveiller, car ce framework va beaucoup bouger au cours des montées de SemVer cependant il est d’ores et déjà ready to dev moyennant d’accepter que ce n’est pas le plus performant à l’heure actuelle (il se comporte assez bien tout de même). En gros il faut vous poser la question du duel : Productivité vs Performance pour choisir ou non Angular. Si votre but est la productivité alors Angular, si votre but est la performance alrors une autre solution sera plus appropriée.