Comme je vous l’indiquais dans mon précédent article, dans le cadre d’une requête venant d’un navigateur, les Frameworks peuvent être utilisés pour deux scénarios :
- Soit le Framework fait le traitement de la requête et renvoie une page HTML complète, le rendu est donc fait côté serveur et le navigateur ne fait qu’afficher la page.
- Soit le Framework lit la requête dans le navigateur, fait une requête à une ou plusieurs urls ( API REST ) si besoin pour récupérer des données. Les données sont affichées directement dans le navigateur en modifiant le HTML, c’est le rendu côté client.
Les plus beaux stands du Bazar *: Le rendu fait côté client
Cette technique est utilisée depuis très longtemps mais elle n’a jamais été aussi structurée que depuis quelques temps. Le séquençage de la requête est le même que le rendu fait côté serveur, à la seule différence que le corps de la page est vide. En effet, c’est lors de l’initialisation du javascript que la page va se construire et que le contenu va apparaître. Ce temps d’initialisation, peut s’étendre d’une fraction de secondes à plusieurs secondes en fonction de l’ordinateur, de l’utilisateur et de la complexité de l’application.
Ainsi les données brutes ne sont pas traitées par ces Frameworks (c’est possible mais je ne vous le conseille pas), ils ne s’occupent que de l’affichage.
On peut éviter cela avec des solutions qui génèrent le contenu de la page d’arrivée de l’utilisateur, le reste de la navigation se faisant directement côté utilisateur (avec Ember Fast ou ReactJS). Grâce à cette approche on résout le problème de la page blanche pour l’utilisateur et les robots des moteurs. L’internaute voit ainsi une page avec du contenu et les robots peuvent indexer ces contenus.
Le langage Javascript, a un nombre incroyable de Frameworks. Grâce à l’avènement de NodeJS et la démocratisation de NPM, le langage Javascript devient LE langage du navigateur ( aka “côté client” ). Personnellement je pense que ce bazar est une bonne chose, mais il faut avouer que c’est difficile de s’y retrouver lorsqu’on veut choisir.
j’ai donc pris le parti d’analyser seulement EmberJS, AngularJS et ReactJS avec Flux.
- EmberJS appartient à Tilde, entreprise qui fournit des solutions Rails.
- AngularJS a été créé par un développeur pendant son temps libre au sein de Google. Mais aujourd’hui, google a assigné une équipe dédiée pour son développement. La version 2 d’Angular est même très soutenue par Microsoft.
- ReactJS et Flux sont issus de Facebook et sont le résultat de plusieurs années d’optimisation de facebook.com.
Remarque :
Google crawle les sites web construits en Javascript et il existe quelques maigres recommandations officielles de leur part sur le sujet. Au moment ou j’écris ces lignes et à ma connaissance, il est le seul moteur de recherche qui est capable de le faire. Il faut donc pré-générer les pages en HTML pour les autres moteur de recherche.
Vous avez le choix entre deux approches : soit vous pouvez le faire à la volée lorsqu’un robot se présente, soit vous générez toutes les pages de votre site à l’avance.
Quelque soit le choix que vous aurez fait, vous pouvez passer par un tiers ou mettre en place une solution vous même. La mise en place de la solution prend du temps mais requiert aussi :
- l’intégration de la solution dans votre processus de mise en production.
- la mise en place d’un moyen de test des pages générées pour les chefs de projet mais aussi les développeurs.
En définitive, tout est une question de ressource, si vous en avez les capacités, cette technologie peut vraiment vous aider.
Personnellement, je pense que si le projet a une forte dépendance au référencement naturel, une technologie faisant le rendu côté serveur est plus adaptée. Aussi bien pour des raisons humaines que budgétaires 🙂
Les cas de Ember Fastboot et de ReactJS : Le premier est un serveur fait par l’équipe du Framework EmberJS pour générer la page côté serveur à la volée. Ainsi l’’internaute voit quelque chose dans son navigateur le temps que le navigateur finisse de charger le javascript contenant l’application. Il a été créé pour le Framework EmberJS mais la documentation indique qu’il peut être utilisé avec ExpressJS. ReactJS s’intègre aussi très bien avec ExpressJS pour permettre de générer des pages à la volée. Vous pouvez évidemment mettre en Cache les pages générées par les deux solutions pour économiser du temps de traitement.
Communauté
AngularJS a la plus grosse communauté entre EmberJS et ReactJS. C’est le plus vieux des trois et l’aura de Google a influencé grandement sa popularité.
Le Couple ReactJS+Flux à une communauté qui augmente également très rapidement. EmberJS à une communauté plus large que ReactJS mais elle est relativement stable depuis quelque années. Trouver une réponse lors de la phase de démarrage ne devrait pas être un problème pour les trois Frameworks.
Remarque pour les développeurs :
Je parle de couple ReactJS+Flux car ReactJS seul n’est pas un Framework à proprement parler. En effet, il ne s’occupe que des composants qui permettent l’affichage du contenu. Flux, s’occupe de rapatrier la donnée. Par ailleurs, il faut bien comprendre que Flux est avant tout un concept , même si Facebook a mis à disposition son implémentation, il en existe de nombreuses autres.
Documentation
Les documentations des trois Frameworks sont excellentes. Flux étant un concept, sa documentation dépend du projet qui en a fait l’implémentation. Certaines comme Fluxxor sont plutôt bien faites, à contrario, la libraire mise à disposition par Facebook a une documentation plutôt limité.
Les communautés de ces 3 Frameworks font un gros travail d’approfondissement dans la compréhension des concepts que ces Frameworks implémentent. Ils publient énormément de tutoriels écrits et de formations vidéos très abordables.
Infrastructure
Ces Frameworks côté client n’ont pas besoin d’une infrastructure très complexe : Il leur faut simplement un serveur HTTP envoyant la page initiale (avec ou sans contenu pré-généré).
En effet, le gros de l’infrastructure sera pris par l’API REST côté serveur, qui va communiquer avec le Framework. Ce dernier peut être également écrit en Javascript (ExpressJS par exemple) ou grâce à une application en PHP.
Une chose est à retenir : un Framework front end va communiquer avec un autre applicatif pour traiter la donnée, il le fait généralement en REST. C’est l’application côté serveur qui va effectuer les requêtes en base de donnée et envoyer les données au Framework.
Concept à maîtriser
Les Frameworks front end requièrent la compréhension des patrons de conceptions ( Design Pattern ). Angular 1 et Ember ont tous les deux implémentés le patron de conception MVC : Model, Vue, Controlleur.
Mais Angular 2 et ReactJS on une approche différente : ils définissent les différentes parties comme des composants ( AngularJS, ReactJS ). Ce concept n’est pas nouveau en soi mais son implémentation dans le cadre de ces Frameworks a besoin d’être compris et maîtrisé.
L’optimisation côté client est un point à ne pas oublier. L’application étant exécutée entièrement côté client, le chef de projet devra avoir une vision claire des utilisateurs ciblés.
Cette information va aider le développeur à optimiser les performances de l’application.
Si par exemple les utilisateurs sont dans des zones ou la connexion internet est mauvaise et/ou qu’ils possèdent des ordinateurs peu puissant, il faudra rendre l’application la plus légère possible tout en gardant les fonctionnalités.
Un des enjeux par exemple pour une application étant utilisée dans des zones de connexion limitées, est d’être la plus légère possible tout en conservant les fonctionnalités essentielles.
Il faut absolument savoir compiler : avec la ribambelle de packages utilisés dans nos projets, il faut savoir mettre en place un moyen de compiler l’ensemble du code dans un seul fichier ( Webpack ou Browserify ). Ce fichier est alors envoyé côté client et est exécuté.
Évidemment, Il faut aussi mettre en place des tests utiles pour éviter les régressions lors du développement.
Avantage
Ces Frameworks permettent de créer des applications rapidement. Ils ont tous un système de modules. Cela permet d’avoir une séparation claire des fonctionnalités dans le code. Cela permet aussi de récupérer des modules réalisés par d’autres personnes afin de gagner du temps sur le développement. Elles permettent de mettre en place des sites très modulables et personnalisables. En effet, l’essence même de ces outils est de manipuler les éléments HTML d’une page. De ce fait, avoir des fonctionnalités qui personnalisent l’affichage est possible.
Chef de projet
Ces Frameworks permettent de mettre en place des applications qui ne rechargent plus la page entière, seule la section qui a besoin de données est rechargée.
Développeur
Leurs composants de base permettent de gérer l’affichage mais aussi de se brancher à des APIs facilement. Ils permettent aussi de réduire la charge du serveur car ce dernier n’aura plus qu’à traiter la donnée et à la renvoyer dans un format très simple ( JSON ).Il n’aura donc plus besoin de générer la page de l’utilisateur en HTML.
Inconvénient
Au même titre que les Frameworks cités dans la partie précédente, les Frameworks front end demandent un temps d’adaptation. Même s’ils sont plus légers, le temps est relatif à l’expérience du développeur. De plus, ce dernier doit faire preuve de discernement lors de la recherche d’informations pour ne pas tomber dans des pièges.
Développeur
La mise en place des compilateur est assez long. En effet, la configuration peut être assez longue car ils ont tous leur façon de gérer les différentes étapes. Si votre application est un Saas, il faut prendre des précautions à la taille des fichiers JS envoyés au client. En effet, il faut bien configurer le compilateur pour qu’il crée plusieurs fichiers de sortie correspondant au contexte de l’utilisateur.