URL: https://linuxfr.org/users/fguillot/journaux/javascript-c%C3%B4t%C3%A9-serveur-int%C3%A9ressant-ou-pas Title: Javascript côté serveur, intéressant ou pas ? Authors: Frédéric Date: 2009年09月21日T17:20:34+02:00 Tags: postgresql Score: 16 Depuis que Mozilla et Google ont sortis des moteurs Javascript très performants ont voit sortir de plus en plus de petits projets visant à implémenter le Javascript côté serveur. Traditionnellement, dans le cadre de développement web, ont est plus habitué à rencontrer du PHP, Python, Ruby, Java ou autre... Aujourd'hui, Spidermonkey/TraceMonkey et Google V8 sont facilement embarquable dans un programme écrit en C/C++. Il devient alors possible d'exposer des fonctions en Javascript depuis du C/C++. Ce qui permet d'étendre et d'ajouter de nouvelles fonctionnalités. Site officiel de Google V8 : [http://code.google.com/p/v8/](http://code.google.com/p/v8/) Tracemonkey : [https://wiki.mozilla.org/JavaScript:TraceMonkey](https://wiki.mozilla.org/JavaScript:TraceMonkey) Il existe également le projet Rhino de Mozilla qui est une implémentation de Javascript en Java. Cependant Rhino n'a pas pour but d'être aussi performant que les solutions présentés ci-dessus. Page officiel du projet Rhino : [http://www.mozilla.org/rhino/](http://www.mozilla.org/rhino/) De plus Mozilla s'intéresse à ce sujet car il tente de normaliser les implémentations Javascript côté serveur en établissant des recommandations connues initialement sous le nom de ServerJS aujourd'hui appelé CommonJS. Ces recommandations sont définies en concertations avec les personnes présentes sur la Mailing-list du projet. Page officiel de CommonJS : [http://wiki.commonjs.org/wiki/CommonJS](http://wiki.commonjs.org/wiki/CommonJS) Par exemple, "SecurableModule" fut la première recommandation ratifiée. Celle-ci vise à normaliser le chargement de modules externes depuis du code en Javascript. Plus d'informations par ici : [http://wiki.commonjs.org/wiki/Modules/SecurableModules](http://wiki.commonjs.org/wiki/Modules/SecurableModules) Désormais le projet vise à normaliser une API commune pour toutes les implémentations. Par la force des choses on risque de se retrouver avec quelque chose d'aussi puissant et extensible que du PHP/Python/Ruby.... mais en Javascript. Voici quelques implémentations de Javascript côté serveur, celles-ci sont ne sont pas forcément compatible avec CommonJS car se sont des projets qui ont bien souvent débutés avant cela. De plus certains projets visent à rendre le Javascript comme un langage à tout faire en y exposant un maximum de bibliothèques existantes. **nodejs** : [http://tinyclouds.org/node/](http://tinyclouds.org/node/) L'un des projets les plus prometteur je pense, il utilise le moteur Google V8 et il est codé en C++. Mais son gros point fort est qu'il est pensé pour fonctionner de manière totalement asynchrone. C'est à dire que toutes les entrées/sorties sont gérées de manières asynchrone ce qui colle bien au Javascript avec les closures et callbacks. Histoire de ne pas réinventer la roue le projet utilise les librairies libev et libeio. Mais le point qui devient intéressant se sont les benchmarks ! Les performances atteintes par nodejs sont du même ordre que thin/EventMachine du monde Ruby. Ce qui est pas si mal. Le benchmark : [http://four.livejournal.com/1019177.html](http://four.livejournal.com/1019177.html) A noter que nodejs utilise sont propre serveur HTTP et non pas un système de CGI ou FastCGI couplé avec un autre serveur HTTP. De plus le développeur a commencé à concevoir un système de module que l'on peut charger dynamiquement. Le premier module permet d'interagir avec Postgresql de manière asynchrone. Certains ont même commencé à concevoir des frameworks au-dessus de nodejs. Bref affaire à suivre. **v8cgi** : [http://code.google.com/p/v8cgi/](http://code.google.com/p/v8cgi/) Comme son nom l'indique le but ici est d'utiliser le Javascript comme CGI ou bien en tant que module Apache. Il utilise le moteur de Google et il est codé en C++. Il expose plusieurs librairies comme GD, Mysql, SQlite etc... Son principe de fonctionnement est similaire à PHP, un système de base et des modules externes écrits en C/C++. Malheureusement, CGI ou module Apache ne permettent pas d'obtenir de bonnes performances face à des solutions comme nodejs. Pour moi ce projet ne fait que répéter l'existant et n'apporte pas de réelle innovation. **Helma NG** : [http://helma.org/wiki/Helma+NG/](http://helma.org/wiki/Helma+NG/) Projet développé en Java et utilisant Rhino de Mozilla. Je n'ai pas vraiment suivi ce projet car le Java ne m'intéresse peu. Cependant Helma vise à implémenter une solution côté serveur complète en y apportant un ensemble de module et même un framework. Sans l'avoir testé son principal défaut, est à mon avis, les faibles performances notamment à cause de Rhino. (cf. benchmark de nodejs avec narwhal qui utilise Rhino comme backend). **flussperfd** : [http://redmine.flusspferd.org/projects/show/flusspferd](http://redmine.flusspferd.org/projects/show/flusspferd) Ce projet est plutôt généraliste il a pour but de faciliter le développement de modules. Il est basé cette fois sur Spidermonkey. Bon j'ai pas vraiment testé... **jslibs** : [http://code.google.com/p/jslibs/](http://code.google.com/p/jslibs/) Le but ici est clairement de faire de Javascript un langage généraliste. Basé sur Spidermonkey, il propose plusieurs modules qui expose des librairies connues telles que libpng, libjpeg, libvorbis, sqlite etc... Plusieurs exemples de code sont donnés sur la page d'accueil, on voit qu'il est possible de lire un fichier audio ou de capturer les images d'une webcam en quelques lignes de Javascript. Apparement le développement du projet est plutôt orienté sur des plateformes Windows. **Conclusion** Bon il existe des dizaines de projets différents, impossible de tous les présenter. Mais ils ont tous un but commun, utiliser le Javascript comme un langage généraliste. Alors quels avantages par rapport aux solutions existantes comme Python ou Ruby ? Dans le cadre de développement d'applications web (que je différencie de site web) on peut imaginer un partage de code entre le serveur et le client. C'est ce que fait par exemple Jaxer développé par Aptana ( [http://jaxer.org/](http://jaxer.org/) ). On peut aussi penser que dans une application web qui utilise de manière intensive le Javascript côté client, utiliser du Javascript côté serveur peut simplifier les choses. On utilise un seul langage des 2 côtés, le ou les développeurs web n'a plus qu'a connaître un seul langage. Le Javascript est normalisé par l'ECMA, développer avec langage de base standardisé est peut-être un gage de pérennité dans le temps pour son application ? Pour beaucoup de gens Javascript est un langage de seconde classe cantonné au navigateur web. Mais aujourd'hui on possède des moteurs Javascript libre très performants, qui peuvent selon moi tout à fait concurrencer du Python/PHP/Ruby. En utilisant des serveurs applicatifs avec des I/O asynchrones on peut atteindre de très bonnes performances et une bonne montée en charge (scalable). Après tout se sont ces techniques qui sont utilisés par nginx/lighttpd/haproxy. Alors vous en pensez quoi de Javascript côté serveur ? intéressant ou pas ? Une chance face à Python/Ruby/PHP5 ?

AltStyle によって変換されたページ (->オリジナル) /