La semaine dernière, vous avez peut-être raté la troisième edition du Devfest Paris, qui rassemble les acteurs majeurs du web et du cloud. On y a parlé IA, data, VR, et bien sûr evolution du cloud et du web. Petit zoom sur les nouveautés d’un framework très populaire : Angular.

Angular : Un peu de contexte

Il y a 18 mois, j’ai découvert Angular dans ma mission de dev fullstack à la Digital Factory de Veolia. Je n’avais pas beaucoup d’expérience en front-end, et ce framework s’est révélé assez facile à aborder mais aussi très puissant.

Le Typescript a rendu les versions 2+ beaucoup plus esthétiques et stables (merci le typage), la documentation et la communauté très active répondent vite et bien aux questions, les commandes du CLI sont pratiques et ont une syntaxe claire et le couplage avec Material Design fait gagner beaucoup (beaucoup) de temps aux noobs du CSS comme moi.

Differential Serving

Grâce à cette fonctionnalité bientôt intégrée (aujourd’hui sur NPM), il est possible de servir différentes versions d’une application en fonction du navigateur de l’utilisateur.

Pour supporter certains vieux navigateurs (cough cough Internet Explorer), il fallait s’adapter aux standards ES5 et importer plein de polyfills, ce qui augmentait considérablement la taille de l’application, mon niveau de frustration et celui des utilisateurs qui ont un navigateur moderne.

Grâce au differential serving, Angular crée des bundles optimisés pour les navigateurs modernes et des bundles adaptés pour les navigateurs plus anciens avec une seule commande du CLI et les navigateurs chargeront automatiquement la version qui leur correspond.

Angular Elements

Angular est un framework plein de fonctionnalités et d’outils très pratiques. Forcément, ça donne des envies de prosélytisme. Grâce aux Angular Elements, il devient possible de packager des composants sous forme de web components, c’est-à-dire des composants réutilisables et indépendants du framework.

C’est une nouveauté pas si nouvelle que ça puisqu’elle existe depuis la v6, mais elle a un gros potentiel qui, pour ma part, est encore largement inexploité. Par exemple, on peut partager un slider ou un select avec quelqu’un qui travaille sur un framework différent. Ou bien intégrer une petite application Angular dans un CMS. Ou encore utiliser ces composants dans une application legacy en AngularJs quand un upgrade total n’est pas d’actualité.

Angular Material CDK

Que celui qui n’a jamais galéré à pimper le CSS de ses composants Angular Material… cesse de mentir. Le CDK Angular Material est loin d’être une nouveauté aujourd’hui puisqu’il est disponible depuis la v5.1, mais il ne cesse d’être amélioré et de nous faciliter la vie.

Enfin Material peut être customisé sans risque de calvitie, et on peut créer ses propres composants tout en restant dans le cadre des best practices Google. Dans la v7, vous trouverez un drag&drop et un virtual scroll ?

Ivy

Ça fait longtemps qu’on entend parler d’Ivy (depuis la v6) mais il semble qu’il soit enfin, presque, a peu près vraiment compatible et disponible. Ce nouveau renderer permet une compilation plus rapide, une taille des bundles réduite et des stacktraces plus facilement lisibles par un humain décaféiné, tout en restant rétro-compatible.

Concrètement, la rapidité et la taille réduite sont dues à deux concepts majeurs: la localité et le tree-shaking. La localité implique qu’Ivy compile les fichiers un par un, prenant en compte chaque composant et son template, sans ses dépendances. On a donc des instructions de compilations plus unitaires, ce qui permet un buid incremental, alors que le renderer précédent devait commencer par une analyse statique de tout le code pour générer un méga-fichier d’instructions.

Le tree-shaking, c’est Marie Kondo pour vos bundles. Ivy identifie les parties non-utilisées du code et les ignore. Grâce aux jolis petits bundles que l’on obtient avec ces deux méthodes, les templates sont inclus dans les stacktraces. Fini les messages d’erreur Kamoulox, on va enfin savoir à la ligne près où se trouve le bug.

Bazel

Bazel est un système de build (à l’instar de Gulp, Make, Maven, Gradle) qui permet d’optimiser la compilation des projets Angular. Il est utilisé depuis une dizaine d’années par Google sous le nom de Blaze. Bazel est en fait une version open-source de Blaze qui commence a être intégrée à Angular.

Bazel supporte beaucoup de langages, ainsi que des projets multilingues, et se veut simple d’utilisation grace a une sémantique high-level. L’optimisation de la compilation des projets Angular se fait notamment grâce à un système de cache et de suivi des modifications qui permet de ne re-compiler que ce qui besoin de l’être. Il est également possible d’effectuer une compilation mixte locale/cloud, qui tirera parti de la plus rapide des deux solutions. Il présente donc surtout un intérêt pour les gros projets, ceux dont le temps de build vous donne le temps d’aller reprendre un café.