Chaque projet client vient avec ses spécificités et, en tant que développeur·euse à KNP il nous incombe la plupart du temps de choisir ou de conseiller sur la suite d’outils nécessaire à leur mise en place.

L’écosystème javascript est extrêmement riche, à en donner le vertige. J’espère que cet article pourra aider des développeurs·euses, débutant·e·s ou confirmé·e·s sans un grand bagage sur les problématiques web front, à déterminer de quoi il·elle·s ont besoin.

Je ne vais pas me concentrer ici sur des librairies spécifiques, mais sur les patterns/types d’outils. Cet article n’est pas exhaustif et ne répond qu'à des problématiques généralistes.

Pourquoi choisir une stack front est devenu si compliqué ?

Quand Symfony a été créé, le Server-Side Rendering (SSR) était la norme. Un client (généralement un navigateur internet) envoyait une requête à votre serveur, qui renvoyait une page HTML qui était affichée telle quelle au client. Javascript avait un rôle secondaire, il permettait d’ajouter quelques interactions sympathiques sur la page.

Au fil des ans, les possibilités apportées par javascript se sont multipliées. De plus en plus utilisé, de nombreux frameworks ont vu le jour... C’est comme ça que sont arrivés les Single Page Application (SPA). Avec cette architecture, le serveur ne renvoie plus qu’une page HTML vide, hydratée côté client en javascript. Différents points d’entrées permettent ensuite de récupérer ou d'interagir avec des données (architecture REST par exemple), toujours depuis l’application javascript.

Ces frameworks ont apporté une efficacité inédite dans l’organisation des assets front (html/js/css), mais ne viennent pas sans inconvénients. On pense notamment au téléchargement du code javascript et à la génération du rendu côté client pouvant induire des lenteurs à l’arrivée sur le site, ainsi qu’un référencement moins efficace par les moteurs de recherche.

On assiste désormais à une montée en puissance des frameworks SSR javascript, qui reprennent les outils utilisés pour écrire des SPAs mais en les exécutant cette fois côté serveur.

Pour autant, il ne faudrait pas faire l’erreur de penser que chacune de ces innovations remplace la précédente. Certaines applications n’ont pas besoin de framework javascript. Certaines SPAs n’ont pas besoin de SSR. Et aucun programme n’a besoin de complexité superflue.

Ai-je besoin d’un framework javascript ?

Exemple: React, VueJS, Svelte…

Twig n’est pas obsolète ! Les avantages de se passer d’un framework javascript sont conséquents :

• L’architecture de votre projet s’en trouvera grandement simplifiée : moins d’outils à apprendre et à s’approprier, un service/serveur en moins dans votre infrastructure,
• Une meilleure productivité à court terme : moins de code à écrire, moins de configuration à mettre en place.

De l’autre côté de la balance :

• L’expérience utilisateur sera moins fluide à la navigation car le serveur renvoie chaque page intégralement (il existe des solutions techniques à ce problème),
• Cela peut-être un vrai challenge d’organiser une grande quantité de code javascript sans l’aide d’un framework dédié.

Si vous développez un MVP, une petite application, et/ou que l'expérience utilisateur n’est pas centrale dans votre projet, vous n’avez probablement pas besoin d’un framework javascript.

Ai-je besoin d’un framework SSR javascript ?

Exemple: NextJS, Gatsby, Nuxt…

Vous avez donc choisi de ne pas faire de SSR depuis votre application Symfony, mais peut-être souhaitez-vous combiner les avantages d’un framework javascript et du SSR.

Vous aurez donc besoin de SSR si :

• Le référencement est important,
• Le site doit être accessible rapidement même à des utilisateurs ayant une mauvaise connexion.

Ai-je besoin d’une librairie de gestion d’état ?

Exemple: Redux, Apollo Client, Mobx…

Les frameworks javascript possèdent des solutions intégrées pour gérer l’état de l’interface. Malgré ça, des librairies de gestion d’état sont souvent utilisées. Elles vont vous aider à vous organiser pour récupérer, stocker, et modifier les données dans votre application.

Vous en avez probablement besoin si votre application remplit l’un de ces critères :

• Vos interfaces sont complexes et dépendent des mêmes données à plusieurs endroits,
• Votre application implique beaucoup de récupération de données (par nature c’est souvent le cas des SPAs puisqu’elles démarrent vides),
• Vous profiteriez d’un cache sur les données récupérées pour soulager votre serveur.

Ai-je besoin d’un framework css ?

Exemple: Bootstrap, Bulma…

Les frameworks CSS mettent à votre disposition des classes pour mettre en place un design rapidement. Mais ils se prêtent généralement mal à la surcharge et peuvent rapidement devenir une barrière entre votre css et ce que vous souhaitez obtenir.

Si les éléments qu’ils exposent vous conviennent tel quel, ils pourront vous faire gagner du temps.

Si vous travaillez avec des maquettes ou que souhaitez avoir une interface personnalisée, passez votre chemin.

Ne passez pas à côté d’une occasion d’utiliser juste ce qu’il vous faut… Less is more !

Besoin de conseil ? Contactez-nous pour un accompagnement personnalisé :D