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.

Mise à jour 11 mai 2013: Modifié le paragraphe sur les bibliothèques. A la suite des commentaires d'utilisateurs sur la version anglaise de l'article, je dois clarifier quelque chose. PHP disposait d'une commande dl pour inclure des bibliothèques externes qui a été supprimée avec la version 5.3. Ainsi que la commande include ou require pour inclure d'autres sources PHP dans le fichier actuel.
La commande require de Node.js permet de lier le programme à des bibliothèques externes en JS ou autre langage, cela ne se compare pas.

Mise à jour 13 mai 2013: 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 (quoiqu'on en pense), 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. C'était la raison de cet article et cela en appelle d'autres.

Deuxième partie: Un CMS en JavaScript sur le serveur. Comparaison de Ghost (JavaScript) et Worpdress (PHP).