Why I didn’t choose Angular

By Rama, published on 18/11/2023, 17:36

3 minutes read

Angular 2.0

A l’origine je voulais utiliser Angular pour faire ce blog. Etant donné que j’étais en train de l’apprendre pour mon travail je me disais que ça m’aiderait à mieux apprivoiser les concepts du framework. Malheureusement ça ne s’est pas passer comme prévu...

Ça y est ! J’ai fait le design du blog. Je me réjouis de bientôt pouvoir passer à l’intégration de ce que j’ai designé.

Angular ou Vue ?

Maintenant je dois choisir sur quel framework web je code mon blog. J’ai 3 ans d’expériences avec le framework Vue, c’est le framework avec lequel je suis le plus à l’aise. Cependant j’ai récemment découvert Angular, le framework front-end de Google dans le cadre de mon poste de Software Engineer chez Ansys. J’hésite entre les deux. D’un côté c’est un framework avec lequel je sais que je vais être efficace et je vais rapidemment pouvoir avancer sur le projet. Mais d’un autre côté je trouve que ce projet est l’occasion de changer ma routine de développeur et d’approfondir mon apprentissage d’Angular, dont la learning curve est considérable.  

Je décide alors me lancer le défi de partir sur Angular !

C’est parti pour dev en Angular ! 😎  

C’est parti ! Je me mets à mon clavier et je commence à cogiter. Je fais l’archictecture du site, quelques components par là, quelques services ci. En seulement quelques heures, un 1er Proof of Concept est prêt.
Je suis déjà très content du résultat, coder un design que l’on a soi-même créé c’est satisfaisant !

Cependant je me rend vite compte que coder avec Angular prend du temps... beaucoup de temps. C’est en premier lieu du à mon inexpérience sur ce framework. Je n’ai pas l’habitude de coder à la Angular way. Mais c'est aussi Angular lui-même qui induit un développement plus lent que des frameworks comme Vue ou React. En effet Angular est un framework opinionated, c’est-à-dire qu’il impose certaines conventions, l’utilisation du Typescript, et son approche monolithique. Après quelques années d'expériences dessus c'est un outil redoutablement efficace, mais avant cela la learning curve de Angular est difficile. On est contraint d’apprendre un nouveau language Typescript et d’utiliser RxJS et penser OB-SER-VA-BLE ! Tout cela ralentit beaucoup le développement. Cela donne l’impression qu'une fonctionnalité implémentée en un clin d'œil avec Vue prend beaucoup plus de temps avec Angular.

RxJS

 RxJS est intégré dans la façon dont Angular fonctionne, vous devez donc suivre un modèle de programmation réactive. J'ai fini par apprécier RxJS, mais j'ai eu (et j'ai toujours) beaucoup de mal à penser réactif. C'est certainement payant, mais imposer cela à un framework peut être un frein considérable pour les personnes qui n'ont pas d'expérience avec la programmation réactive.

 

Seulement je me rends compte qu’il y a un hic.  Comment faire du SSG avec Angular ? En faisant quelques recherches je suis rassuré. Je tombe d’abord sur le meta-framework AnalogJS. Je le npm install et je le teste vite fait. Mais un truc me gène : je ne trouve pas de générateur d’image static. Or étant donné que j’héberge ces images sur mon NAS qui n’est pas toujours allumé, il est indispensable que les images du blog soient générées statiquement et hebergé sur Vercel.  En continuant mes recherches je tombe sur la solution officielle de Angular: Angular Universal. Mais après l’avoir testé et je retourne au même constat : pas de générateur statiquement d’images. N’y a t-il pas d’optimiseur d’images sur Angular ? Venant de l’écosystème Nuxt qui a Nuxt Images cela me surprend.

Cela m'embête vraiment puisque je n'ai ni l'envie ni le temps de coder un crawler d'images pour le prerendering côté serveur...

Le temps de la remise en question

Après avoir galéré avec Angular pendant quelques jours je me résous à passer tout sous Vue avec Nuxt 3. Je n’aurais jamais le temps de faire le reste des objectifs du journal d’apprentissage sinon. 