Javascript coté serveur

Par Laurentj le vendredi, novembre 13 2009, 06:39 - Technologies Web - Lien permanent

Ça commence à faire pas mal d'année que je fais du javascript, non seulement pour le web, mais aussi dans les applications XUL. Ce qu'il y a d'intéressant à utiliser Javascript avec le XUL, c'est qu'on peut se lâcher, et utiliser tout le potentiel du javascript de la plateforme Mozilla, comme les générateurs et iterateurs, les propriétés et méthodes avancées sur les objets de base (comme sur Array). Même si je ne suis pas fan de certaines constructions syntaxiques^[1].

Et depuis quelques jours j'ai une lubie : pourquoi ne pas utiliser javascript coté serveur, en remplacement de PHP par exemple ?

Et j'ai découvert sur wikipedia qu'il existait quelques dizaines de projets de générateurs de pages web à base de javascript. La majorité de ces projets reposent sur les moteurs JS de Mozilla :

SpiderMonkey, le moteur (en C) utilisé dans Firefox 3/Gecko 1.9.0 et précédent
Rhino, un moteur en java

Ceux à base de SpiderMonkey m'intéresse plus particulièrement. Je ne les ai pas encore tous regardé, mais jslibs semble sympa, dans la mesure où la dernière version ne repose plus sur SpiderMonkey, mais sur TraceMonkey, le moteur JS accéléré de Firefox 3.5.

Pour faire le choix d'un de ces projets, il va falloir regarder de plus près les API proposées. En effet, il faut savoir qu'un moteur JS ne fait qu'exécuter du code, et ne contient nativement que quelques objets primitifs comme String, Array, Date, Math... C'est au code embarquant de "brancher" des bibliothèques ou fonctions C sur des objets JS (faire des wrappers donc), pour enrichir l'API utilisable dans le code JS. Ce que fait d'ailleurs un navigateur, pour les objets window, document, les objets DOM etc.

Reste aussi à faire quelques benchmarks, pour voir si ça vaut vraiment le coup par rapport à PHP, Python ou autre..

Notes

[1] disons que depuis la publication de ce billet, j'ai un avis moins tranché :-) On s'y fait

Commentaires

1. Le vendredi, novembre 13 2009, 08:53 par insolite-du-geek

Suis curieux & impatient de voir les résultats du benchmark entre le JS TraceMonkey, PHP et Python.

2. Le vendredi, novembre 13 2009, 10:40 par ED

Aptana Jaxer existe depuis un petit moment mais j'avoue que j'avais classé ça un peu en "gadget"

http://www.jaxer.org/

Ca utilise SpiderMonkey.

3. Le vendredi, novembre 13 2009, 10:50 par Clochix

Dans le cadre de la bidouillabilité, je m'intéresse moi aussi de plus en plus au SSJS (j'ai écrit un billet sur le sujet il y a peu). On est en train de diminuer de plus en plus les pré-requis pour pouvoir bidouiller le Web, mais on pourra difficilement se passer de la connaissance d'un peu de JavaScript. Dès lors, autant qu'on puisse aussi s'en servir sur le serveur et partager du code entre le client et le serveur.
Si tu ne l'as pas encore fait, je te conseille de jeter un œil aux différentes bibliothèques JS qui commencent à implémenter CommonJS, j'ai l'impression qu'il y a beaucoup de potentiel de ce côté (des projets comme Narwhal ou NodeJS par exemple).

4. Le vendredi, novembre 13 2009, 12:12 par ReLuc

Avec Jaxer tu peux faire du XPCOM c'est cool non ?

5. Le vendredi, novembre 13 2009, 12:20 par Gourmet

J'utilise Python Spidemonkey depuis un peu moins de 2 ans dans un projet perso de domotique.
JS est là pour permettre une programmation simple d'actions non prévue par l'IHM (elle ne peut pas tout faire l'IHM) et sans aller jusqu'à bidouiller le code python de gestion.
Python exporte donc les principaux éléments de l'architecture (capteurs, actionneurs) et quelques méthodes et c'est JS qui fait le boulot (l'IHM repose également sur JS via Dojo).

C'est pratique, pas rapide (mais je m'en fiche) et ça ouvre des opportunités.
Historiquement, le moteur Rhino est le plus avancé.
D'ailleurs, si ça n'a pas changé, Batik, qui s'appuie dessus, est la référence en ce qui concerne l'implémentation de SVG.
db

6. Le vendredi, novembre 13 2009, 12:39 par Bruno

J'ai fait une présentation sur ce sujet à OSDC.fr. Les slides sont en ligne sur http://dev.af83.com/fr/javascript/o...

En gros, le javascript coté serveur, c'est encore très "jeune", mais ça progresse vite. Comme Clochix, je te conseille de regarder du coté CommonJS et Narwhal.

7. Le vendredi, novembre 13 2009, 13:28 par lipki

Le problème du js (pour moi) c'est l'implémentation de la POO qui date une peut(bcp), corriger moi si je me trompe, mais on en est encore au prototype.

C'est peut être mieux que le php, mais c'est pas encore la panacée.

8. Le vendredi, novembre 13 2009, 18:39 par laurentj

Ok, merci, je vais regarder jaxer, commonJS et Narwhal :-)

@lipki : ce n'est pas parce que c'est pas objet, que ce n'est pas bien. Javascript est plus proche d'un langage fonctionnel (qui ont le vent en poupe en ce moment) qu'un langage objet. Disons que c'est une autre manière de programmer.

@bruno : merci pour les slides :-)

9. Le vendredi, novembre 13 2009, 20:04 par bibo

En ce moment, c'est node.js qui fait le + de buzz.

Détail : il est basé sur V8 ;-)

10. Le samedi, novembre 14 2009, 05:13 par metagoto

@lipki : la POO basée sur les prototypes n'est pas du tout obsolète, bien au contraire.

Pour js coté server, j'ai dans mes cartons une extension V8 pour php: embarquer le moteur de Google dans php. Et bien lors de mes tests, pour des boucles, des manipulations d'array etc, V8 était grosso modo 10 fois plus rapide que php. Ca doit être encore plus flagrant maintenant car pas mal d'améliorations ont été apportées au moteur de Google. Et pour info, je testais avec php 5.3.

Actuellement, je m'amuse à mettre V8 coté server (via du fastcgi) dans une appli de test (mon lien). C'est beaucoup plus performant que php, mais une bonne partie de l'app est implémentée en C++. Le js vient se greffer à quelques endroits comme la partie templating. Je n'ai pas encore fait de bench sérieux, mais je pense que à fonctionnalités équivalentes (c'est à dire beaucoup moins complet que php pour du templating), et bien c'est plus performant. Mon idée de base était que le format JSON est parfait pour passer et traiter des données de templates.

JSON, d'ailleurs, voila une bonne raison de mettre js coté server. CouchDB, MongoDB l'ont bien compris. js a un bel avenir devant lui.

11. Le mercredi, novembre 18 2009, 16:24 par bibo

Et voila des slides présentant node.js :http://nodejs.org/jsconf.pdf.

Pour résumé le concept de node.js : "aucune I/O ne devrait bloquer l'application" D'ou une programmation à l'évenement (ou callback)

12. Le mercredi, novembre 18 2009, 16:25 par bibo

Juste pour dire que node.js utilise common.js pour la gestion des modules.

13. Le mercredi, novembre 18 2009, 17:45 par laurentj

@bibo : ça a l'air vraiment bien nodejs !

dommage toutefois que c'est v8: pas de generator, d'iterator et cie.. pas de JS 1.8 quoi :)

14. Le lundi, novembre 30 2009, 11:43 par Gabriel K.

J'aime bien le twit de Tim Bray sur node.js, très simple.
Just watched Ryan Dahl's node.js talk. Um, wow. http://jsconf.eu/2009/video...
Si on parle de node.js même dans le monde java, c'est qu'il y a du buzz

15. Le jeudi, décembre 10 2009, 16:39 par manatlan

appjet ... était une société qui proposait un framework SSJS ...
tu éditais tes sites, en ligne, tout en JS ... c'était vraiment bien.
Ils viennent de se faire racheter par google ... et je prédis du JS sous GAE sous peu.

jy[B]log