Pourquoi JavaScript sur le serveur?
Remplacer PHP par JavaScript, y a-t-il de bonnes raisons pour cela?
Le même langage sur le serveur et le client
Ce n'est pas seulement une question de simplicité ou de facilité d'apprentissage. C'est un fait que passer d'un langage à l'autre facilite l'occurence des erreurs, mais l'avantage du langage unique va au-delà. Cela permet de transférer le traitement au choix chez le client ou sur le serveur. Les mêmes fonctions exactement avec les mêmes bibliothèques.
On peut choisir de placer le code sur le client pour alléger la charge du serveur car le client dispose de ressources inutilisées. Au contraire on va transfèrer le code sur le serveur pour protéger le source s'il est propriétaire, ou pour réduire le temps de chargement en n'envoyant que les seuls résultats au client.
La performance (on compare Node.js et PHP)
JavaScript et PHP sont tous deux des langages dynamiques et interprétés. Mais le premier dispose d'un compilateur JIT très performant. Je n'ai pas besoin de réaliser des tests pour le prouver, d'autres l'ont déjà fait et une étude a montré que Node.js peut être cinquante fois plus rapide que PHP (MAJ 06/2014: le site est maintenant fermé). C'est normal, le JIT est infiniment plus rapide.
L'écart se réduit certainement avec le HHVM de Facebook, une machine virtuelle JIT. Mais ce n'est pas le PHP que l'on trouve sur tous les serveurs.
Bibliothèques illimitées sans compilation
Le nombre de bibliothèques que l'on peut inclure dans un projet, notamment sur GitHub est un avantage. Elles peuvent être écrites dans n'importe quel langage (on ajoute les commandes d'exportation) et liées à JS avec la commande require.
PHP permet aussi de lier des bibliothèques écrites en C, mais il faut activer les extensions dans le fichier INI ce qui est rédhibitoire pour la distribution auprès d'utilisateurs non programmeurs.
Application web dynamique
Si l'on veut utiliser un gestionnaire de contenu pour un site portail ou un blog, PHP reste irremplaçable. Il existe des gestionnaires en JS, mais ils ne sont pas au niveau de Wordpress ou Drupal. D'un autre coté, pour une application en ligne, il y a les frameworks faits pour HTML. Par exemple Angular, Ember, qui proposent un data-binding bi-directionnel.
La différence est que les CMS voient HTML comme un code à produire, et les frameworks comme une interface avec laquelle interagir.
Ainsi, tandis que le CMS en PHP convient pour un contenu éditorial, pour une application originale avec des fonctions nouvelles, un framework offre plus de liberté.
Mais les CMS en JavaScript vont se développer à leur tour.
Offline et mobiles
Je n'ai jamais vu un site Wordpress ou Joomla fonctionner en mode offline. En théorie, un programme PHP pourrait fonctionner sur le poste client, comme le fait Java avec ses applettes (ce n'est pas une bonne référence), mais cela suppose qu'un interpréteur PHP soit présent. Cette limitation n'existe pas pour JS, il est présent sur tous les postes, dans le navigateur.
Le mode offline est particulièrement bienvenu sur les mobiles, pour éviter un temps de chargement fastidieux à chaque session mais aussi pour économiser la bande passante qui est limitée sur ces appareils.
En conclusion, le modèle LAMP (Linux, Apache, MySQL, PHP) a été conçu et popularisé pour l'époque des ordinateurs et logiciels de bureau et un Web de pages statiques, complété certes par Ajax, mais ce n'est qu'une rustine dynamique sur un système statique.
Il n'est pas forcément optimal pour les appareils actuels, les mobiles, les applications en ligne fonctionnant aussi hors ligne.
Un CMS en JavaScript sur le serveur
Le modèle LAMP ne convenait pas aux applications modernes, notamment par défaut d'un mode offline, impossible avec PHP. Wordpress en est le meilleur exemple. Même si ce CMS à de nombreuses qualités et de nombreux avantages par rapport à ses concurrents, notamment celui de la simplicité d'utilisation et de personnalisation, il convient de moins en moins aux plateformes modernes, à cause de sa base LAMP.
Comme je le suggère dans cet article, de nouveaux CMS commencent à apparaître basés sur JavaScript et Node.js. Un exemple avec Ghost. Ce CMS à obtenu une levée de fond conséquente sur KickStarter avec le support de plusieurs compagnies, dont Microsoft qui a investi (on parle de 50000 $) pour favoriser son développement.
Et les termes de la présentation du logiciel s'accordent bien avec mes propres conclusions:
Chez Ghost, nous pensons que l'utilisation de JavaScript non seulement nous donne à accès à des communautés d'esprits brillants en croissance rapide, mais il rend aussi le projet accessible à d'autres communautés qui ne sont pas concernées par les projets PHP, la vieille garde. JavaScript a passé le test de la durée et Ghost, conformément à sa mission, peut travailler étroitement avec les communautés qui font avancer l'innovation sur le Web.
Apparemment une bonne partie des commentaires sur la première partie, et notamment sur Hacker News proviennent de la vieille garde ;)
Reste à démontrer plus précisement en quoi l'utilisation de JavaScript permet de faire un CMS plus moderne.
Tableau de bord personnel
Wordpress utilise des widgets pour permettre au webmaster de réaliser l'interface du site, et il en est de même avec le CMS JavaScript. Mais Ghost va plus loin: on peut construire aussi son propre tableau de bord en ajoutant et déplaçant des widgets...
Le tableau de bord est construit comme une application Web ou pour mobile: il tient dans une seule page tandis que Wordpress utilise le principe hérité des applications de bureau avec une multitudes d'onglet dédiés chacun à une des fonctions de gestion du site.
Edition sans contraintes
La création d'article se fait sur deux panels: à gauche, le "code source", qui n'est plus en HTML mais en markdown. Et à droite le contenu tel que le voit le lecteur.
Ce choix se justifie par la volonté de construire un CMS simple, limité au blogging, ce qu'était Wordpress à l'origine. Cela réduit les problèmes de formatage. Il y a souvent une difficulté à obtenir ce que l'on veut avec l'éditeur de Wordpress (TinyMCE), car il à ses propres règles et il supprime les balises que l'on insère quand cela ne lui convient pas. C'est quelque chose qui est inhérent à ces éditeurs en ligne qui n'ont pas les capacités qu'à DreamWeaver de synchronisation entre le source et l'affichage. Le markdown a des limitations, mais sa simplicité permet d'obtenir cette synchronisation et de réaliser un billet en étant plus à l'aise.
L'accès aux articles antérieurs et à leur édition est aussi facilité dans Ghost par une double fenêtre. On déroule la liste dans une fenêtre et on édite l'article sélectionné. Il est facile de passer de l'un à l'autre. Wordpress du fait de sa conception ancienne, requiert de passer d'une page à l'autre pour les mêmes opérations ce qui rend l'édition plutôt laborieuse.
Thèmes et plugins sans templates
Réaliser un thème en JavaScript et HTML semble plus facile qu'avec HTML et PHP, et les plugins plus encore. Un thème ici est une page HTML et CSS, avec des champs dédiés aux différents contenus du site. Un plugin est un script JavaScript que l'on charge dans la page ou que l'on ajoute en tant que module à Node.js.
Il n'y a pas de raison de rencontrer ces problèmes de compatibilité de plugins à la fois avec les nouvelles versions du logiciel et avec les autres plugins, qui remplissent les forums Wordpress de complaintes. Dès lors que le logiciel a une conception moderne basée sur WebSocket, comme Advanced Explorer sur ce site, les différents modules peuvent communiquer par messages et les mêmes commandes recevant les même réponses, les différents modules peuvent évoluer indépendamment sans inconvénient.
Fonctionne sur mobiles
L'avantage de JavaScript et Node.js est de permettre à Ghost de fonctionner sur tous les appareils en tant qu'application car il est plus rapide et plus léger que Wordpress. L'auteur a accès au tableau de bord sur une tablette ou un mobile.
Il est évident qu'en supprimant ne serait-ce que les 1300 KO de l'éditeur TinyMCE et les 500 KO de jQuery, on accélère notablement le chargement du tableau de bord! En fait le répertoire JavaScript de base de Wordpress 2.9 contient plus de 3 megas de code.
Pour accéder au tableau de bord sur un mobile, il faudrait au moins le mode offline et stocker tout le code nécessaire localement. Mais ce n'est pas possible avec un logiciel écrit en PHP.
Tous les hébergements mutualisés ne supportent pas Node.js. Mais il en existe tel notamment Gandi. Et il y a le cloud.
Mise à jour: Après avoir lu les commentaires des lecteurs (sur la version anglaise et sur HN), je me rends compte qu'en fait, l'avantage de JS sur PHP n'est pas dans la liste des fonctionnalités, mais plutôt dans l'expérience qu'elles procurent. J'ai réalisé quelques applications en ligne en PHP, et je regrette maintenant de ne pas les avoir réalisées en JS avec Node, car tout aurait été bien plus simple et le résultat meilleur.