Pourquoi WordPress s’oriente vers le Javascript

Le problème du tout “PHP”

A l’origine d’Internet les pages web étaient « imprimées » virtuellement par un serveur et affichées sur votre machine. A chaque nouveau clic, une nouvelle page était générée puis envoyée par Internet jusqu’à votre ordinateur.

C’est encore sur ce modèle que se base aujourd’hui grandement WordPress.

Si je schématise le fonctionnement :

Lorsque vous demandez une page web, le client (c’est-à-dire votre machine), lance une requête HTTP via le navigateur vers le serveur. Celui-ci va générer la page demandée via PHP / MySQL et retourner une page HTML.

Le souci, c’est qu’aujourd’hui les sites web sont plutôt vus comme des applications web : imaginez qu’à chaque action sur Facebook, ou qu’à chaque nouveau tweet sur votre mur, il y ait un rechargement de page. Même chose pour des applications professionnelles comme Trello. Ce serait très frustrant !

Imaginez maintenant que demain, votre interface d’administration de WordPress soit une application ‘One page’, c’est-à-dire qu’une fois chargée, il n’y ait plus de rechargement de page à chaque action.

Le gain de temps et de ressources serveur serait énorme.

De plus on ne peut pas mettre l’interface d’administration en « cache » comme on le fait en front avec une extension du type WPRocket par exemple car les données changent tout le temps.

C’est pour cela qu’aujourd’hui l’administration n’est pas au top niveau en terme de performances. J’ai enregistré le temps de chargement de mon éditeur, avec l’inspecteur de Chrome ouvert :

On remarque qu’il faut près de 9 secondes pour que la page soit entièrement chargée et prête à l’utilisation. Il y a eu pas moins de 180 requêtes pour près de 2Mo transférés (car j’ai des images dans mon article).

C’est très long. La plupart des éléments ont été rechargés pour rien, pour ainsi dire : ils n’ont pas changé entre temps (les scripts par exemple).

C’est donc une frustration grandissante des utilisateurs de WordPress, et il est plus que grand temps de devoir changer cela.

Mais avant d’arriver à une interface plus fluide, il faut opérer certains changements, et c’est notamment l’arrivée de l’API Rest qui a permis de poser la première pierre à l’édifice.

Tout a commencé avec la REST API

C’est vers la fin 2015, lors du WordCamp US, que Matt Mullenweg, le créateur de WordPress, annonçait l’arrivée officielle de l’API REST au coeur de WordPress.

Il conseillait aux développeurs d’apprendre en profondeur Javascript : Take Every Opportunity to really beef up your JavaScript Chops

Selon lui, le web tend de plus en plus à utiliser Javascript, pour des pages web plus rapides et plus dynamiques, et WordPress va suivre le mouvement. L’API est un premier pas vers cette approche.

Alors, c’est quoi déjà une API REST ?

Ok ! Donc l’API permet à du JS de facilement lire / écrire / mettre à jour et supprimer des données en contactant le back-end, c’est-à-dire la partie PHP. C’est de cette manière que l’on s’approchera d’une application sans rechargement complet de page.

Gutenberg utilise donc l’API au travers de Javascript pour sauvegarder le brouillon et enregistrer un article. (En vérité c’était déjà le cas avant pour les brouillons seulement).

Bénéfices de WordPress en mode ‘One Page’

Le principe de l’application ‘One page’ c’est que le serveur (côté PHP donc) s’occupe de traiter les données, on parle de CRUD (Create, Read, Update, Delete), ces données sont envoyées via l’API en objets simples (au format JSON) et c’est le front, donc Javascript via le navigateur, qui s’occupe de créer le template de la page, dynamiquement.

Le serveur n’a donc plus besoin de générer une page HTML, et s’occupe simplement de distribuer des données brutes.

Javascript peut alors dynamiquement créer l’affichage en fonction de ces données, et mettre à jour le rendu si d’autres données arrivent, sans rechargement.

Si je schématise, en me basant sur le précédent schéma :

Le bénéfice ici est le gain de temps de chargement ainsi que l’économie de ressources serveur. Javascript peut alors adapter le rendu de la page en temps réel en fonction des informations reçues.

Je soupçonne donc qu’à l’avenir, les autres parties de l’administration WordPress vont suivre ce modèle et basculer en JS (mais avant cela il faudra d’abord résoudre le problème des hooks PHP et de la rétrocompatibilité).

C’est un travail titanesque et il faudra encore patienter quelques années pour en arriver là.

On pourrait même déjà créer des thèmes qui ne nécessitent pas de rechargement de page, et utilisent l’API Rest pour fonctionner. Des concepts ont vu le jour dans ce sens. Mais on n’en est pas encore là.

Répartition des technologies Gutenberg

Alors comment se répartit le code de Gutenberg actuellement ? On s’imagine bien qu’il y aura une majorité de code en Javascript et React, mais combien exactement ? Reste-t’il du PHP ? Voici ce qu’en dit le projet Github de Gutenberg :

• Javascript : 77%, on constate qu’en effet, JS occupe la plus grande partie du code de Gutenberg
• PHP : 10%, il reste tout de même 10% de PHP, pour s’intégrer au coeur de WordPress
• CSS : 6%. Il faut pas mal de CSS pour gérer l’éditeur, les panneaux d’options et les blocs par défaut
• HTML : 6%, idem pour le HTML
• Shell : 1%, des scripts de ligne de commande pour faire marcher le tout (qui ne devraient peut-être pas être dans la version définitive)

Même les apps mobiles se mettent à JS !

Si vous avez suivi un peu l’évolution du web ces dernières années, vous avez vu Javascript prendre de l’importance au fur et à mesure.

Et aujourd’hui même les développeurs d’applications mobiles préfèrent utiliser une technologie du type React native (une librairie issue de ReactJS), qui permet de faire une application mobile iOS et Android, plutôt que de devoir apprendre les langages respectifs de chaque plateforme.

Prenez l’exemple de Slack, le logiciel de chat pour les pros. Malgré le fait que ce soit l’une des start-up avec la plus grosse progression de tous les temps, ils ont préféré utiliser des technologies comme React Native, qui permettent à chaque application sur chaque système d’exploitation de se baser sur la version web.

Vous vous imaginez la dette technique et le nombre de compétences pour gérer une application iOS, Android, Windows, Mac, Linux et Web aujourd’hui ?

C’est le Web et notamment le JS qui permettent de réunir le tout en une seule technologie. Et je peux vous assurer que beaucoup de développeurs et grands groupes suivent le pas.

Du coup c’est une très bonne idée pour WordPress de faire la même chose. Je laisse la parole à Victor, un collègue développeur d’apps mobile, qui en parlera mieux que moi :

Développer React

Formateur

Le conseil de Victor Sabatier

Développeur indépendant

React Native permet, grâce à la puissance de React et d’un peu de magie de générer des interfaces natives à partir de JS. Vous avez tous les avantages de l’hybride avec les avantages du natif.

J’arrive à produire des applications 80% plus rapidement, et au niveau performances les benchmarks indiquent que je suis presque au niveau du natif. Que des avantages en faveur de React Native.

Mes utilisateurs adorent et en plus, la note est bien moins salée.

Suivez-moi sur Twitter : @sabativi

WordPress suit donc l’évolution technologique du web et s’adapte pour proposer à terme une interface plus fluide à la réactivité immédiate.

C’est pour cela qu’il lui est nécessaire de basculer vers des technologies plus modernes, comme JS et React.

Dans le prochain cours nous allons nous attarder sur le choix d’utiliser React dans WordPress, et ses implications.