Formation « Créer des blocs avec Gutenberg »

Pourquoi WordPress s’oriente vers le Javascript

Lecture : 6 minutes • 2

Eyh ! Mais j'étais très bien moi avec mon PHP ! Il va falloir tout réapprendre ? On va voir dans ce cours que WordPress migre peu à peu vers du Javascript, et on va voir quelles en sont les raisons.

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 :

Requête classique client serveur
La requête est envoyée du client par le navigateur. Le serveur renvoie une page HTML

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 ai 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 ai 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.

Matt Mullenweg
Matt Mullenweg lors d’un WordCamp

Il conseillait aux développeurs d’apprendre en profondeur Javascript :

Take Every Opportunity to really beef up your JavaScript Chops
Matt Mullenweg

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 ?

Cours dédié

API REST

Définition

Une API Rest est un système permettant de lire/écrire du contenu brut (c'est-à-dire sans mise en forme HTML) dans un système informatique. Les demandes sont effectuées au travers de requêtes HTTP sous forme d'URLS. Le résultat est transmis sous forme d'objet JSON, le successeur du XML. C'est un format facilement lisible par tous les langages de programmation.Le but d'une API est d'assurer un échange de données entre plusieurs systèmes et ce peu importe la technologie utilisée. L'API REST de WordPress peut être utilisée notamment pour créer une application mobile native.La requête API WordPress : http://example.site/wp-json/v2/posts permet de récupérer la liste des derniers articles par exemple

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.

Information

L’API REST est aujourd’hui bien implantée dans WordPress, et on aura d’ailleurs l’occasion de l’utiliser à plusieurs reprises au travers de cette formation, notamment pour aller chercher les informations d'un article ou un produit.

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 :

une requête API client serveur
Le serveur est contacté pour récupérer des données brutes en JSON

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 :

repartition technologique Gutenberg
JS représente plus de 75% du code 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.

Les applications Slack pour mobile et desktop
Les applications Slack pour mobile et desktop

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 :

Victor Sabatier
Développer React
Formateur

Le conseil 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.

2

Questions, réponses et commentaires

  1. imath

    Le 25 mai 2018

    Salut Maxime, très bel article et quelles belles perspectives 🙂 Je ne sais pas si tu as suivis wp.hooks qui a été intégré au Core puis retiré, mais il est d’ores et déjà possible comme le fait Gutenberg d’intégrer une librairie de hooks JavaScript. Elle est disponible via npm : https://www.npmjs.com/package/@wordpress/hooks Autrement, ton point sur la rétro compatibilité est très juste A+

    1. Maxime BJ

      Le 25 mai 2018

      Merci pour l’info ! Je vais regarder ça de plus près !

Laisser un commentaire