Une histoire sur les architectures frontend - Naissance de l'ingénieur FE

Dans les discussions récentes, nous avons exploré divers modèles d'architecture d'application, en insistant sur l'importance cruciale d'isoler la logique métier et le code au sein d'une organisation. Les décisions prises tôt lors du développement d'une application influencent profondément la cohérence et la maintenabilité futures. Une erreur à ce stade peut entraîner des modifications coûteuses et chronophages plus tard dans le cycle de vie de l'application. En se concentrant spécifiquement sur les modèles d'architecture frontend, il devient impératif de comprendre comment les pages web sont livrées et mises à jour dynamiquement pour l'expérience utilisateur.\n\nCette série explorera davantage les architectures au niveau de l'application pour les produits web modernes, y compris les applications monopage (SPAs) utilisant des frameworks comme React, Vue et Angular, les modèles Backend for Frontend (BFF) et les techniques de rendu côté serveur telles que SSG (génération de site statique), ISR (régénération statique incrémentale) et SSR (rendu côté serveur) avec des technologies comme Next.js, Nuxt et Astro. D'autres sujets incluent les monolithes frontend et les architectures microfrontend.\n\nHistoriquement, les applications web étaient construites comme des applications multipages (MPAs), où chaque interaction utilisateur déclenchait un rechargement complet de la page en récupérant un nouveau document HTML depuis le serveur. Ces applications à client léger contrôlées par le serveur utilisaient peu JavaScript, ce qui entraînait des expériences utilisateur lentes et moins réactives. Pour améliorer cela, AJAX (JavaScript asynchrone et XML) a été introduit, permettant des mises à jour partielles de la page sans recharger l'ensemble du document HTML. AJAX a introduit l'API XMLHttpRequest, facilitant les requêtes et réponses de données asynchrones, améliorant ainsi l'interactivité via des techniques comme les Promises et les callbacks, qui ont ensuite évolué vers l'API fetch() largement utilisée.\n\nCependant, à mesure que les applications devenaient plus complexes, les limites de performance des moteurs JavaScript sont devenues évidentes. La forte dépendance aux manipulations du DOM et aux nombreuses appels asynchrones rendait la gestion de la logique frontend lourde. Pour relever ces défis, Google a introduit le moteur JavaScript V8, une avancée majeure dans le développement web. V8 a mis en œuvre la compilation Just-In-Time (JIT), traduisant JavaScript en code machine natif optimisé au lieu de l'interpréter ligne par ligne. Il a également incorporé des optimisations avancées telles que les classes cachées, la mise en cache en ligne et un ramasse-miettes amélioré.\n\nL'avènement de V8 a non seulement accéléré l'exécution de JavaScript mais a aussi favorisé la création de Node.js en 2009, qui a considérablement étendu l'écosystème JavaScript tant côté client que serveur. Complétés par des innovations comme le routage côté client utilisant l'API History, les implémentations de DOM virtuel, la modularisation basée sur les composants et les bundlers, ces technologies ont collectivement permis les SPAs. Les SPAs offrent une navigation fluide sans rechargement de page, des interfaces utilisateur rendues côté client et des bases de code modulaires maintenables.\n\nL'émergence des SPAs représente un moment charnière dans l'ingénierie frontend, donnant naissance au rôle dédié d'ingénieur frontend. Elles ont ouvert la voie à des applications web plus interactives et complexes, alimentant la popularité des tableaux de bord et des plateformes SaaS (Software-as-a-Service). Cette évolution a également inspiré le développement de bibliothèques et frameworks innovants par les grandes entreprises technologiques. Bien que les SPAs aient transformé le développement frontend, elles ont aussi posé les bases pour des avancées architecturales supplémentaires qui continuent de façonner l'avenir des applications web.