Découverte d'AnalogJS : le meta-framework Angular moderne

Sommaire

• Introduction et contexte

• Qu’est-ce qu’AnalogJS ?

• La construction d’AnalogJS : sur quoi repose-t-il ?

• AnalogJS et le SSR : quelle différence avec @angular/ssr ?

• Cas d’usage concrets, exemples simples et principes clés

• Les raisons d'adopter AnalogJS

• Les limites: ce qu'il faut savoir avant de se lancer

• Conclusion

Introduction et contexte

Ces dernières années, l'écosystème frontend a vu fleurir de nombreux meta-frameworks comme Next.js pour React ou Nuxt pour Vue. Ces nouveaux arrivants ont révolutionné le domaine en proposant une intégration plus poussée du développement Web : Server Side Rendering (SSR), Static Site Generator (SSG), routing simplifié ou encore une optimisation de performances directement intégrée dans l'outil. Ces intégrations répondent à un besoin réel du terrain concernant les projets modernes, notamment autour du Search Engine Optimization (SEO) et de la simplification des architectures.

De son côté, Angular est historiquement orienté Single Page Application (SPA). Si le framework propose aujourd'hui une solution SSR officielle via @angular/ssr (depuis Angular 17), sa mise en place reste à la charge du développeur et peut nécessiter une configuration non négligeable selon le contexte projet. En parallèle, les ajouts des Signals ou des standalone components indiquent clairement une volonté de moderniser l'expérience développeur.

AnalogJS s'insère dans cette dynamique en proposant une approche inspirée par les meta-frameworks modernes et avec pour but de simplifier les problématiques full-stack dans les projets Angular.

Plus loin que la simple découverte de l'outil, l'objectif de cet article est de comprendre ce qu'apporte AnalogJS à l'écosystème Angular et dans quels contextes son utilisation apporte de la valeur.

Qu’est-ce qu’AnalogJS ?

Comme dit précédemment, AnalogJS est un meta-framework construit au-dessus d'Angular. A l'image de ce qu'apporte Next.js à React ou Nuxt à Vue, AnalogJS cherche à simplifier l'ajout de nouvelles fonctionnalités telles que le SSR, le SSG ou encore certaines capacités full-stack.

A l'inverse d'une bibliothèque supplémentaire dans le projet, AnalogJS ne remplace pas Angular mais agit comme une surcouche structurante. Angular reste au centre de l'application (au niveau des composants, des injections de dépendances, du routing ou encore de la réactivité), tandis qu'AnalogJS apporte un cadre pour organiser le projet, gérer le build et faciliter l'intégration de fonctionnalités plus avancées.

Selon moi, le point fort d'AnalogJS réside dans sa capacité à améliorer la Developer Experience (DX). En préférant Vite à l'outillage traditionnel embarqué par Angular, j'ai notamment constaté des temps de démarrage plus courts, un live reload plus fluide et une configuration plus légère. En effet, dans mes tests sur un projet Angular de taille moyenne, le démarrage du serveur de développement passe de ~8 secondes à moins de 2 secondes avec Vite. Le Hot Module Reload (HMR) devient lui quasi instantané de son côté. Ces chiffres ne sont pas universels et varient suivant la taille du projet et des performances de la machine. Cumulées pendant la phase de développement, ces petites améliorations font une réelle différence quand les heures passées sur un projet deviennent importantes. En clair pour moi une belle réussite qui concilie les fondamentaux propres à Angular tout en adoptant une structure et une approche plus moderne, déjà adoptée par la concurrence.

La construction d’AnalogJS : sur quoi repose-t-il ?

Il est important de voir AnalogJS comme un assemblage cohérent de technologies complémentaires, chacune répondant à un besoin précis aussi bien côté backend que frontend.

Côté frontend, AnalogJS repose naturellement sur Angular. On y retrouve les grands principes du framework tels que les composants standalone, l'injection de dépendances, les mécanismes de routing ou encore les dispositifs de réactivité modernes tels que les Signals. L'objectif ici n'est pas de modifier la façon que l'on a de développer en Angular, mais venir ajouter un cadre plus structuré autour de ces pratiques modernes.

L'un des principaux atouts réside dans l'adoption de Vite comme bundler et serveur de développement. Ce choix permet d'améliorer les performances en phase de développement et représente un choix cohérent avec l'évolution actuelle de l'écosystème frontend dans lequel Vite tend à devenir un standard.

Côté backend, le meta-framework s'appuie sur Nitro, outil provenant de l'écosystème Nuxt. Il permet de gérer le rendu côté serveur, les endpoints de l'API ainsi que les différentes stratégies de déploiement (Node, serverless ou edge). Cela permet de centraliser les besoins front et back dans un même projet, sans besoin d'externaliser un backend pour des besoins simples. Au-delà des technologies qu'AnalogJS utilise, il repose aussi sur des principes structurants hérités des meta-frameworks modernes: forte convention de structure projet, intégration native du SSR / SSG, et une volonté de réduire la configuration au profit de conventions (convention over configuration).

Pour mieux comprendre ce qu’AnalogJS apporte au quotidien, il est donc utile de s’intéresser aux principales fonctionnalités qu’il met à disposition et à la manière dont elles s’intègrent dans le développement d’une application.

AnalogJS et le SSR : quelle différence avec @angular/ssr ?

Avant d'aller plus loin dans les cas d'usage, il est important de clarifier un point: Angular propose déjà une solution de SSR officielle via @angular/ssr (anciennement Angular Universal). La question est alors: pourquoi utiliser AnalogJS pour faire du SSR ?

Les deux approches ne s'opposent pas mais elle ne répondent pas tout à fait au même besoin final.

Avec @angular/ssr, le SSR est une fonctionnalité que l'on ajoute à un projet Angular existant. C'est une approche flexible, bien intégrée à Angular et qui convient très bien à une architecture établie.

AnalogJS adopte une philosophie différente: le SSR y est natif et structurant dès le départ. Il est partie intégrante du cadre proposé, au même titre que le routing basé sur les fichiers et les API routes. C'est Nitro qui prend en charge la couche serveur, ce qui apporte une plus grand flexibilité sur les stratégies de déploiement.

Pour résumer:

Le choix entre les deux dépend moins d'une question de performances que de contexte projet: si vous démarrez sur un nouveau projet avec des besoins full-stask et SEO, AnalogJS offre un cadre clé en main, parfait pour débuter. Si vous cherchez à inclure du SSR sur un projet Angular existant, @angular/ssr reste la voie la plus directe et la plus officielle.

Cas d’usage concrets, exemples simples et principes clés

Au-delà des concepts expliqués plus haut dans l'article, l'intérêt d'AnalogJS apparaît surtout lors de la mise en place rapide d'un projet réel. Voici quelques exemples simples qui illustrent les principes clés du meta-framework.

Création d'une page avec routing basé sur les fichiers

AnalogJS utilise un système de file-based routing, ce qui évite d'avoir à configurer le router Angular pour des pages simples dans l'application.

Par exemple, si on veut créer une page /users, il suffit de créer un fichier avec ce chemin dans le projet:

src/routes/users.page.ts

Et de rajouter ce contenu exemple pour le test:

import { Component } from '@angular/core';

@Component({
  standalone: true,
  template: `
    <h1>Users</h1>
    <p>Liste des utilisateurs</p>
  `
})
export default class UsersPage {}

La route est automatiquement disponible, sans ajout de configuration supplémentaire. La structure de fichiers est alors une représentation abstraite de ce que va être celle côté application.

Créer un endpoint API simplement

AnalogJS permet aussi de créer des endpoints pour le backend directement dans le projet, pratique pour éviter d'avoir à mettre en place un backend séparé pour des besoins simples.

Par exemple, un endpoint pour simplement récupérer des utilisateurs :

src/server/api/users.get.ts

Avec le contenu suivant :

export default defineEventHandler(() => {
  return [
    { id: 1, name: 'Guillaume' },
    { id: 2, name: 'Alan' },
    { id: 3, name: 'William' },
  ];
});

Ce endpoint est alors directement disponible via :

/api/users

Cela devient particulièrement utile pour mocker facilement de la donnée (pour des tests, cas aux limites) mais aussi pour centraliser une logique simple côté serveur.

Une fois cette API disponible, on peut la consommer simplement côté composant :

import { Component, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Component({
  standalone: true,
  template: `
    <h2>Users</h2>

    <ul>
      <li *ngFor="let user of users">
        {{ user.name }}
      </li>
    </ul>
  `
})
export default class UsersPage {

  http = inject(HttpClient);

  users: User[] = [];

  ngOnInit() {
    this.http.get<User[]>('/api/users')
      .subscribe(data => this.users = data);
  }

}

Cette implémentation devient alors une arme redoutable pour toute élaboration de projets internes ou prototypes type Proof of Concept (PoC) mais reste tout autant efficace pour des projets plus importants.

Server-side data fetching

Un autre point fort d'AnalogJS réside dans sa capacité à charger des données côté serveur avant le rendu d'une page côté utilisateur. Ce mécanisme, inspiré de ce que proposent Next.js ou Nuxt, repose sur une fonction load() associée à une page. Cette fonction s'exécute côté serveur au moment de la requête, ce qui garantit aux données d'être présentes dans le HTML dès le premier octet envoyé au navigateur.

Reprenons l'exemple de notre page /users. Plutôt que de faire un appel HTTP dans le composant Angular après le rendu initial de la page, on peut déléguer ce chargement au server en ajoutant un fichier .server.ts associé :

import { PageServerLoad } from '@analogjs/router';

export const load = async ({ params }: PageServerLoad) => {
  const response = await fetch('https://mon-api.com/users');
  const users = await response.json();

  return { users };
};

Côté composant, les données sont récupérées via injectLoad(), sans aucun appel HTTP supplémentaire :

import { Component } from '@angular/core';
import { injectLoad, toSignal } from '@analogjs/router';
import { load } from './users.server';

@Component({
  standalone: true,
  template: `
    <h1>Users</h1>
    <ul>
      @for (user of data().users; track user.id) {
        <li>{{ user.name }}</li>
      }
    </ul>
  `
})
export default class UsersPage {
  data = toSignal(injectLoad<typeof load>(), { requireSync: true });
}

Dans une SPA Angular standard ou sans faire de server-side côté AnalogJS, le HTML initial arrive vide et les données sont chargées après, côté client. Ici, le serveur résout les données avant d'envoyer la réponse, ce qui permet deux effets intéressants :

• SEO : les crawlers Web voient un contenu à la première requête, ce qui permet une meilleure indexation du contenu de la page.

• Performance : le contenu est affiché immédiatement, sans état de chargement intermédiaire / loader qui pourrait altérer l'expérience utilisateur.

Ce mécanisme devient alors un allié pertinent sur des pages à fort enjeu SEO comme des fiches produits, des articles de blog ou des pages de résultats, là où afficher un contenu vide en attendant un appel API côté client n'est pas acceptable.

Utiliser du Markdown pour générer des pages de contenu

Comme ses concurrents directs, AnalogJS permet de créer des pages de contenu à partir de fichiers Markdown, très utile pour de la documentation, un blog ou des pages de contenu pur.

Exemple de fichier dans la structure de projet :

src/routes/blog/mon-article.md

# Mon article

Voici un exemple de contenu Markdown avec AnalogJS.

- Simple
- Rapide
- Efficace

La page est alors accessible via ce segment URL :

/blog/mon-article

Ce mécanisme de génération de contenu via Markdown permet aussi de séparer le contenu et la logique applicative.

Gérer le SEO et les meta tags d’une page

Une autre force que j'accorde à AnalogJS est de faciliter l'optimisation SEO grâce au SSR. Contrairement à une SPA classique dans laquelle les meta tags sont parfois mal gérés par les crawlers Web, AnalogJS permet de définir proprement les informations SEO au niveau des pages de l'application.

Exemple simple pour un titre et une description :

import { Component } from '@angular/core';
import { Meta, Title } from '@angular/platform-browser';

@Component({
  standalone: true,
  template: `
    <h1>Users</h1>
    <p>Liste des utilisateurs de l'application</p>
  `
})
export default class UsersPage {

  constructor(
    private title: Title,
    private meta: Meta
  ) {
    this.title.setTitle('Utilisateurs | Ma Super Plateforme');

    this.meta.addTags([
      { name: 'description', content: 'Liste des utilisateurs de la plateforme' },
      { name: 'author', content: 'Jean RICHARD' }
    ]);
  }

}

On peut également ajouter des meta tags Open Graph pour améliorer le partage sur les réseaux :

this.meta.addTags([
  { property: 'og:title', content: 'Utilisateurs | Ma Super Plateforme' },
  { property: 'og:description', content: 'Liste des utilisateurs' },
  { property: 'og:type', content: 'website' }
]);

Ce type d'optimisation permet de simplement gérer page par page ses interactions avec le SEO et les données que l'on veut voir apparaître côté navigateur.

Ces différents exemples montrent qu'AnalogJS ne se limite pas à juste proposer de nouvelles fonctionnalités, mais cherche surtout à simplifier l'implémentation de problématiques devenues centrales dans l'écosystème Angular moderne : routing structuré, endpoints API simples, gestion de contenu ou encore optimisation du SEO.

Les raisons d'adopter AnalogJS

Au-delà de tous ces aspects techniques, la vraie question que l'on est en droit de se poser est la suivante : dans quels contextes ces apports justifient-ils réellement l'adoption d'AnalogJS ? Comme souvent avec ce genre d'outillage, la réponse dépend moins des fonctionnalités que des besoins réels du projet, de sa complexité ou encore de ses contraintes d'architecture.

Dans les expérimentations que j'ai pu mener, AnalogJS montre surtout son intérêt lorsqu'il permet de simplifier des problématiques habituellement coûteuses à mettre en place dans un projet Angular, notamment autour du SSR ou de la structuration full-stack.

Voici quelques raisons qui, selon moi, peuvent justifier son adoption :

• Améliorer l’expérience développeur et la productivité

L'ajout de Vite et l'approche plus conventionnelle permettent de réduire le temps passé sur la configuration et d'accélérer les cycles de développement. À l'échelle d'une équipe, ce type de gains peut avoir un réel impact sur la vélocité et la Developer Experience (DX) apportée au projet.

• Moderniser l’approche Angular sur de nouveaux projets

AnalogJS permet de démarrer rapidement avec un ensemble moderne et complet (SSG, SSR, conventions de structure projet) sans avoir à faire évoluer d'une manière ou d'une autre une architecture existante. Cette approche rend ce méta-framework particulièrement efficace dans une logique de projets greenfield (projets démarrés from scratch, sans stack à maintenir ou à faire évoluer).

• Une alternative crédible pour les projets nécessitant du SEO ou contenu public

On croise souvent des projets hybrides (portails, homepages simples exposées avec un dashboard derrière, plateformes SaaS…). AnalogJS permet alors d'éviter de devoir sortir d'Angular ou de multiplier les stacks techniques additionnelles pour un même besoin.

• Se positionner sur les évolutions modernes de l'écosystème Angular

Monter en compétences sur ce type d'outillage permet d'anticiper d'éventuelles évolutions de l'écosystème et de renforcer une certaine crédibilité technique sur des sujets d'architecture front moderne.

Les limites: ce qu'il faut savoir avant de se lancer

Avant d'adopter AnalogJS sur un projet, il est important de connaître les limites actuelles. L'outil étant encore "jeune", AnalogJS présente aussi des contraintes qui peuvent nuire à son adoption. Voici les principaux points que j'ai identifiés :

• Une documentation parfois incomplète

Sur certains cas d'usage avancés, il faut aller directement lire le code source du framework pour débloquer certaines mises en place compliquées.

• Une communauté plus petite

Contrairement à Nuxt ou Next.js, AnalogJS dispose d'une communauté plus réduite que ses concurrents. Ce qui signifie concrètement qu'il y a moins de ressources disponibles en ligne, moins de retours d'expérience et que les temps de résolution de problèmes sont plus longs.

• Des breaking changes encore fréquents

Entre les différentes versions, ces changements peuvent surprendre sur un projet où la stabilité long terme est une contrainte forte.

• Un risque de friction en équipe

Si les développeurs ne sont pas familiers avec l'approche adoptée par les meta-frameworks, il y a un risque de ralentissement de l'onboarding au lieu d'augmenter la productivité.

• Pertinence limitée pour certains projets Angular

La complexité supplémentaire introduite par AnalogJS est difficile à justifier quand une SPA Angular classique répond déjà au besoin, que ce soit lors d'une migration d'Angular vers AnalogJS ou tout autre projet sans besoin SSR / SEO.

Conclusion

AnalogJS s'inscrit dans une évolution logique de l'écosystème Angular qui cherche à améliorer la Developer Experience et les architectures hybrides. En s'inspirant des méta-frameworks modernes, il simplifie la mise en place d'outillages natifs là où l'implémentation côté Angular peut s'avérer plus complexe.

Pour autant, il ne faut pas voir AnalogJS comme une solution universelle. Son adoption implique l'ajout d'une surcouche structurante, qui peut apporter de la valeur dans certains cas mais aussi, à l'inverse, ajouter de la complexité dans d'autres contextes. Le choix d'AnalogJS dépend alors du contexte projet dans lequel il s'insère : visibilité SEO/Web, performance, structuration full-stack ou encore l'organisation et les connaissances des équipes techniques.

Avec ce recul, AnalogJS m'apparaît davantage comme un levier d'architecture à adopter dans des cas précis de problématiques projet, plutôt que comme un nouveau standard Angular. La vraie valeur de cet outil réside dans la capacité des équipes techniques à savoir quand l'utiliser, mais aussi quand ne pas l'utiliser. Cette capacité de discernement technique est cruciale pour faire la différence entre une tendance et une véritable décision d'architecture.