En tant que développeur on hésite parfois à prendre des décisions, par peur de l’impact que cela peut avoir sur les temps de développement, sur le bon fonctionnement des applications etc…
L’autre question que l’on se pose souvent est : « Suis-je tout seul à me poser ces questions ? »
Comme exemple je vais prendre le cas précis de mon application web Shyrka (gestion de comptes bancaires).
Je travaille sur cette application depuis des années (c’est mon hobby 🙂 ). Pour l’instant elle n’a jamais été diffusée au grand public, par peur de ne pas avoir ensuite le temps de suivre les demandes de supports, d’évolutions etc…
Jusqu’à présent Shyrka utilise PHP (framework MVC développé par mes soins) et coté client (navigateur) il y a un peu de Javascript et aussi du Jquery.
Le langage Javascript monte en puissance depuis plusieurs mois, grâce entre autre à node.js, mais aussi aux progrès des Navigateurs en terme de compatibilité. De plus il existe aujourd’hui des dizaines d’APIs Javascript.
De l’autre coté PHP a du mal à évoluer. Java reste complexe et traîne une mauvaise réputation en terme de sécurité. Tout cela laisse un boulevard pour Javascript qui est en train de se créer une place de choix dans le développement Web.
Pour en revenir à Shyrka, un soir je me suis dis mais pourquoi ne pas essayer de limiter au maximum les rechargements de page en ne faisant transiter entre le serveur et le navigateur que les données, sans aucune mise en forme (code HTML). L’idée extrême étant de développer l’application dans une seule page HTML tout étant ensuite géré avec Javascript…
Cette idée semblait un peu ‘bizarre’ mais en cherchant un peu sur Internet j’ai découvert que ce concept existe et qu’il a même un nom :
SPA pour Single Page Application.
En schématisant voici le principe :
- Une page HTML qui contient l’ensemble de l’interface (div, onglet, nav, boutons…)
- Du code Javascript (beaucoup de code) pour gérer les événements, les éléments HTML (DOM)
- Des appels Ajax (XMLHttp) entre le navigateur et le serveur pour récupérer uniquement des données
- Du code PHP (Java ou Node.js…) coté serveur pour traiter les demandes et interroger la base de données entre autre
Par exemple pour afficher le solde d’un compte, Javascript s’occupe d’afficher les éléments HTML nécessaires (div, input…), ensuite une requête XMLHTTP est exécutée pour récupérer le solde (code PHP qui fait un count dans la BDD). La valeur retournée est ensuite insérée dans la page au bon endroit.
Principaux avantages de ce type de solution :
- Affichage très rapide coté navigateur : seules des fragments de page sont modifiées et la page n’est jamais rechargée en totalité (sauf au démarrage)
- Optimisation du trafic réseau, les fichiers HTMl, JS et CSS ne sont chargés qu’une seule fois
- Les appels entre navigateur et serveur sont également optimisé car seules transitent des données et aucun code (ou très peu) de mise en page (HTML, CSS..)
- Séparation complète entre le back-Office (serveur) et le front-office (html)
- Possibilité d’utiliser le back-office avec une front-office différent (application mobile par exemple)
- Certains traitements sont transférées du serveur vers le navigateur => on allège ainsi la charge serveur, pratique si l’application est utilisée par des dizaines (centaines) de personnes.
Inconvénients :
- Beaucoup, beaucoup de code Javascript
- Prendre en compte les différences en les navigateurs au niveau de la compatibilité Javascript
- Maitriser le fonctionnement du DOM, des événents (click etc…)
- Obligation d’avoir Javascript d’activé sur le navigateur
- Javascript est un langage permissif (pas de typage fort des variables par exemple) ce qui peut perturber au début
Voici une image qui résume ce concept
Nb : Article original de 05/2015 sur mon ancien blog