Comme tout outil créé dans un cadre donné, on sait qu'on pourra sans doute l'utiliser dans un autre cadre mais ce n'est pas forcément le plus adapté. On voit au fil du temps de plus en plus de gens parler de tuer Angular ou React ou les frameworks front. Personnellement je suis totalement d'accord pour beaucoup d'utilisation qui pour moi sont non-sens mais pas dans l'absolu.

Frontend fatigue

Un point à prendre en compte quand on entend une envie de tuer les frameworks front c'est la framework fatigue : pour faire du front, on a de plus en plus d'outils à connaître, de plus en plus de points à prendre en compte, de nouveau de plus en plus de framework, etc. Le fait que ça bouge tout le temps est bien au sens où on essaie de toujours faire mieux mais j'ai l'impression qu'on perd l'essentiel au passage et qu'on fait parfois beaucoup d'overengeneering...

Du côté des frameworks on se retrouve assez vite à développer dans un écosystème plutôt fermé. C'est certain qu'on retrouve pas mal de concepts et de librairies qui sont partagées car totalement génériques, mais on a vite fait d'utiliser un wrapper prévu pour React ou Angular, voir des implémentations très spécifiques (je pense par exemple à NgRx qui est une alternative à Redux mais uniquement pour Angular).

Overkill

Je vois de plus en plus de gens qui passent par une SPA (Single Page Application, les applications qu'on crée généralement avec un framework front) alors qu'on est face quasiment à 100% a du contenu statique ou juste un formulaire tout simple dans validation (ou presque).

Est-ce que tout le monde réalise qu'on ajoute une énorme de complexité alors qu'on aurait pu simplement utiliser des pages html toute simple ? Voir du SSR (Server Side Rendering) avec un tout petit php (ou autre, je suis pas difficile) si on a besoin de récupérer le contenu depuis une base de donnée ?

Surtout qu'on se retrouve très souvent avec des nouvelles problématiques. Par exemple le SEO (Search Engine Optimisation) car le contenu affiché via une SPA n'est pas indexé par les robots Google ou ses compères. Un autre problème des SPA est le délai avant le premier affichage ou le délai avant lequel on peut interagir à cause du temps de chargement des fichiers javascript (qu'on compense en partie via de nouveau outils…).

SSR + SPA = ❤️ ?

De plus en plus de gens passent par des outils de Server Side Rendering – comme Angular Universal, Next.js, Nuxt.js ou plus récemment Remix – pour des SPA.

Je pense que ces outils sont un non-sens dans beaucoup de cas : on prend une technologie prévue pour faire des écrans très dynamiques gérés côté client pour basculer ce code côté serveur ce qui donne des écran peu (voir pas du tout) dynamique. Ce n'est pas très adapté, on est en javascript/typescript, donc on déploie du nodejs côté backend pour servir des pages pratiquement statiques ou pour des apps qu'on aurait peut-être dû développer simplement avec une autre technologie plutôt que forcer une technologie client-side à rentrer dans le backend.

JAMStack

Après l'étape SSR, on a vu débarqué le mouvement JAMStack qui a pour idée que la solution à tous nos problèmes c'est de fabriquer un site html statique à chaque fois qu'on crée une nouvelle version de l'application ou du contenu. Mouvement fortement piloté par Netlify, qui offre un système de build et déploiement sur CDN assez impressionnant.

Je comprends pourquoi on peut vouloir faire ça. Typiquement, j'utilise quasi au quotidien une documentation créée avec Docusaurus pour pouvoir l'héberger en statique (via des Github pages) mais avoir quand même un système de recherche.

Mais est-ce encore une fois vraiment ce qu'on veut ? Est-ce qu'on veut vraiment avoir tout un ensemble de brique compliqué pour simplement avoir un site statique à la fin ? Personnellement je trouve encore une fois que c'est overkill pour beaucoup de cas.

WebComponent ❤️

Avant de partir sur une SPA, je pense qu'il est aujourd'hui plus que jamais le temps de se poser la question des WebComponents.

Autant en vanilla js ce n'est pas forcément très sympa comme technologie mais avec des outils légers comme Stencil ou Lit (mon préféré j'avoue) on peut avoir quasiment le confort des gros frameworks SPA en étant le plus léger et standard possible.

J'évoque les WebComponent, mais dans beaucoup de cas, je pense que la meilleure solution c'est de n'avoir aucun composant du tout, même aucun javascript. On peut parfois penser que faire directement du html et css c'est old-school et dépassé, mais c'est surtout que ces dernières années on a très fortement complexifié le web et que dans certains cas ça ne suffit plus.

Angular ❤️ forever

Dans le même temps je nuance tout ce que j'ai dit jusque-là : je ne jetterai pas Angular ou React ou Vue ou n'importe-quel-framework pour l'instant.

Autant je défends l'idée qu'on en a pas besoin pour pas mal de cas, autant il y a des cas où ça répond à des vrais besoins et même très bien. Je peux prendre l'exemple tout simple de ma mission actuelle : je travaille sur des outils développés sous la forme de SPA mais qui viennent remplacer (ou compléter avant remplacement) des outils clients lourd développés il y a facilement 10 ans. Les utilisateurs ouvrent leur navigateur le matin, le ferme le soir. Au final nos applications ne sont pas des sites web mais bien des applications web.

Là on a un vrai sens à utiliser un framework frontend : on ne veut pas de référencement, on ne veut pas avoir à installer quoi que ce soit chez nos utilisateurs (et donc gérer des mises à jours, des erreurs d'installation, etc.), on ne veut pas recoder une gestion de fenêtre, on veut pouvoir faire du style facilement, on veut un design system, on a pas du tout besoin d'interaction avec l'OS, on veut profiter de l'écosystème JS pour se faciliter la vie. Le web est parfait pour ça : si l'application doit être mise à jour, on déploie la mise à jour sur nos serveurs et on attend que l'utilisateur recharge la page ou on demande à l'utilisateur de rafraîchir la page et c'est bon, les utilisateurs n'ont pas à s'occuper de comment ça fonctionne, juste utiliser notre application qui est clairement plus user-friendly que ce qu'ils avaient avant, en grande partie parce que c'est beaucoup plus simple avec du CSS de le faire.

Je pense qu'on peut trouver beaucoup de cas comme ça. Mais ce n'est pas le gros des cas qu'on croise sur le web.

Conclusion

Comme très souvent quand j'aborde ce genre de sujet, la réponse à la question du début est autant oui que non. En fait c'est toujours pareil : on a tendance à utiliser une technologie à la fois dans le contexte pour laquelle elle a été prévue mais en même temps pour tout et n'importe quoi, parfois en allant jusqu'à tordre ou sur-outiller la solution pour que ça fonctionne.

Comme j'aime à dire : on peut utiliser un marteau pour enfoncer une vis, mais avec un tournevis c'est vachement plus pratique ! 😎

En tout cas, quand vous arrivez face à un problème qui vous semble compliqué à résoudre techniquement parlant ou un problème qui fait intervenir beaucoup de technologie, n'hésitez pas à vous poser 5min pour vous demander si c'est le bon choix d'outil qui a été fait.

Sources :

Crédit photo : https://pixabay.com/illustrations/hammer-screw-blow-violence-895666/