Journal Javascript côté serveur, intéressant ou pas ?

Posté par  .
Étiquettes :
16
21
sept.
2009
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/
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/

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

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

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/

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

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/

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/

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

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/

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/ ).

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 ?

  • # haxe

    Posté par  . Évalué à 5.

    Si tu veux utiliser le même langage côté client et serveur, tu peux essayer HaXe.
    http://haxe.org/

    • [^] # Re: haxe

      Posté par  . Évalué à 2.

      Je connaissais pas Haxe, mais si j'ai bien compris ça oblige le développeur à apprendre un nouveau langage de plus.

      A voir si ça vaut le coup.

      • [^] # Re: haxe

        Posté par  . Évalué à 4.

        C'est assez proche de ActionScript / JavaScript, mais avec plusieurs backends et un certain effort de rigueur il me semble.

        • [^] # Re: haxe

          Posté par  . Évalué à 1.

          C'est en effet basé sur EcmaScript, orienté Objet. Et beaucoup plus strict que ce que ActionScript 3 l'est. (Javascript n'est pas encore orienté objet nativement, ainsi que AS2 ).

          Et pour information, c'est le créateur de mtasc (compilateur libre d'AS2, plus stricte que ne l'était le compilateur officiel de feu Macromedia, et pondant un bytecode plus véloce) qui est aussi le créateur de Haxe (et consort, c'est à dire Neko/NekoVM, ....)

          Et autre petite information, les différents jeux MotionTwin (www.motion-twin.com) sont basés dessus.

          • [^] # Re: haxe

            Posté par  (site web personnel) . Évalué à 4.

            > Javascript n'est pas encore orienté objet nativement

            Ha bon ?
            Etrange, car j'ai juste l'impression de faire de l'orienté objet tous les jours en javascript...

            Attention à ne pas confondre langage orienté objet et langage à classes.

            Le javascript (l'ecmascript) est un langage à prototype et non un langage à class, mais ça n'enlève pas le côté objet.
            As3 permet de créer des classes, interfaces, etc mais si je ne me trompe c'est tout de même traduit en prototype par derrière.

            • [^] # Re: haxe

              Posté par  . Évalué à 1.

              Méa culpa c'est ce que je voulais dire. Je parlais de classe en effet et si je disais que Javascript n'intégrait pas les classes nativement, c'est que l'on pas réelement d'implémentation d'ECMAScript 4 dans Javascript (dans le sens utilisable partout, car on trouve surement des VM le supportant).

    • [^] # Re: haxe

      Posté par  (site web personnel) . Évalué à -7.

      Un gros oublie de l'article est de parler de l'alternative mod_perl :)

      Python / Ruby / PHP5 c'est bien beau mais c'est dépassé!

  • # Un bout de temps que c'est utilisé !!! [NON LIBRE]

    Posté par  (site web personnel) . Évalué à 3.

    En feuilletant la documentation d'Opera Mini, je me suis rendu compte que le javascript est évalué coté serveur pour ce navigateur.

    Opera utilise ainsi une technologie qui leur permet d'évaluer la page web coté serveur et transmet la page résultant sous forme binaire appelée OBML [http://dev.opera.com/articles/view/opera-binary-markup-langu(...)]. L'avantage de cette solution à l'avantage de consommer très peu de bande passante et de diminuer le calcul coté client.

    Implémenté dans la version 5 du navigateur Opera Mini, le support du javascript coté serveur est assez impressionnant [http://dev.opera.com/articles/view/opera-mini-5-beta-develop(...)]. En effet celui-ci permet de naviguer sur facebook, twitter, etc...

    Peut-être cette technique va-t-elle se répandre dans l'avenir ? (à vos réflexions)

    • [^] # Re: Un bout de temps que c'est utilisé !!! [NON LIBRE]

      Posté par  . Évalué à 1.

      J'ai jamais dis que le Javascript côté serveur était nouveau, d'ailleurs à en croire Wikipedia, Netscape le faisait en 1996 :

      http://en.wikipedia.org/wiki/Server-side_JavaScript

      Après il me semble que Opera l'utilise également pour son truc Opera Unite.

      • [^] # Une approche très prometteuse

        Posté par  . Évalué à 2.

        Avant de me lancer, je tiens à te remercier Frédéric pour ce journal très instructif.


        Pour le reste, l'approche utilisée par Opera Mini, me semble très prometteuse. Elle permet d'éviter beaucoup de problèmes (de sécurité notamment) dès le départ. Sans compter les autres avantages qu'elle véhicule et que tu as cité.

        indéniablement, cela donne un avantage incontestable au JS par rapport aux autres langages PHP et compagnies.

        Cela simplifiera énormément les usines à gaze qui servent actuellement d'application Web+ serveur Web. En terme d'architecture cela se simplifiera grandement.

    • [^] # Re: Un bout de temps que c'est utilisé !!! [NON LIBRE]

      Posté par  . Évalué à 3.

      Ca veut dire que toute page vue avec Opera Mini va transiter par un proxy de chez Opera ? J'espère avoir mal compris, parce que niveau confidentialité, c'est un peu limite...

      • [^] # Re: Un bout de temps que c'est utilisé !!! [NON LIBRE]

        Posté par  (site web personnel, Mastodon) . Évalué à 6.

        C'est justement le principe d'Opera Mini, déporter la technologie côté serveur, qui sont des sortes de proxys intelligents. Ben oui faire un vrai brouteur web en 64Ko, ça me semble difficile...

        Leur FAQ est très claire à ce sujet :

        Est-ce qu'Opera Software peut voir, en clair, mes mots de passe et numéro de carte de crédit ? De quel chiffrement profitent ces données ?

        Le chiffrement utilisé a pour but de protéger la communication d'une intrusion entre le client (le navigateur sur le mobile) et le serveur/convertisseur d'Opera Mini. Si vous n'avez pas confiance en Opera Software, assurez-vous de ne pas utiliser nos applications pour communiquer toutes sortes d'informations sensibles.

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Un bout de temps que c'est utilisé !!! [NON LIBRE]

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Il y a également Opera Unite et les widgets Opera qui sont une implémentation JS serveur, c'est assez malin d'ailleurs en réutilisant des trucs client. Par exemple pour redimensionner une image, on la met dans un canvas, duquel on peut ensuite créer un nouveau fichier.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Ce que j'en pense...

    Posté par  (site web personnel) . Évalué à 5.

    Que Javascript coté serveur, on peut en faire depuis 1996 et Netscape Enterprise Server...
    Visiblement, même en arrivant après, Python, Ruby et PHP ont eu plus de chances. :D

    • [^] # Re: Ce que j'en pense...

      Posté par  . Évalué à 4.

      Ouais mais le Javascript c'est à la mode maintenant, on en mets partout, même dans les PDF, Adobe ils assurent de ce côté là, ça ouvre quelques failles de sécurité de plus pour les méchants :)

    • [^] # Re: Ce que j'en pense...

      Posté par  (site web personnel) . Évalué à 3.

      ah le bon vieux temps du SSJS qu'il fallait compiler... c'était un enfer à debugger.

    • [^] # Re: Ce que j'en pense...

      Posté par  . Évalué à 2.

      C'est vrai que côté historique, le javascript est plutôt chargé... On se souviendra de LiveScript, mais surtout de Jscript, l'implémentation sauce Microsoft du standard, avec son lot d'incompatibilités au niveau du langage comme dans les notions d'accès au DOM. C'est l'une des nombreuses raisons pour lesquelles il est difficile de faire du JS compatible avec tous les navigateurs.
      A ceux qui disent "détester le javascript", je leur conseille de regarder les vidéos de Douglas Crockford; ils comprendront que les défauts qu'ils trouvent à Javascript sont en fait liés à l'environnement du navigateur, le DOM, ou le BOM, qui sont franchement hostiles. Le langage en lui même est plutôt agréable à manipuler, via la notion d'objet/hashmap, les regexp intégrées, les lambdas/closures...

  • # Pas con...

    Posté par  . Évalué à 1.

    Je verrai bien une application type jeu, scripté en Javascript au lieu du LUA.

    • [^] # Re: Pas con...

      Posté par  . Évalué à 1.

      Juste pour info, le jeu 0ad (passé récemment en open-source ) se scripte en JavaScript (via SpiderMonkey). Je ne sais, par contre, pas ce qui a motivé ce choix technique par rapport au LUA.

      • [^] # Re: Pas con...

        Posté par  (site web personnel) . Évalué à 2.

        Je crois que LUA est plus simple et plus petit. Les jeux n'ont d'habitude pas une grosse API de scriptage, LUA est donc bien plus efficace qu'un gros moteur javascript dans ce cas.

        • [^] # Re: Pas con...

          Posté par  . Évalué à 1.

          Justement dans le cas sus mentionné, l'API de scriptage avait besoin de proposer quelque chose de plus gros???

  • # Bof

    Posté par  . Évalué à 7.

    C'est plutôt l'inverse qu'il faudrait faire : mettre un langage sympa côté client...

    • [^] # Re: Bof

      Posté par  . Évalué à 1.

      Des applets java? humm

      • [^] # Re: Bof

        Posté par  . Évalué à 1.

        Je ne pensais pas aux applets Java (bien que ce soit préférable à du Flash ou du Silverlight pas libre).

    • [^] # Re: Bof

      Posté par  (site web personnel) . Évalué à 2.

      Il existe des interpréteurs Ruby, Python (et x86!) écrits en... Javascript.

      • [^] # Re: Bof

        Posté par  . Évalué à 1.

        Ah c'est cool ça, on pourrait alors développer un browser en Python, le lancer dans un autre browser via l'interpréteur Javascript, et dedans on relancerait un interpréteur Ruby en Javascript... On peut aller loin comme ça :)

    • [^] # Re: Bof

      Posté par  . Évalué à 1.

      Moi j'aime bien le javascript.

      Même plus que le ruby pour certaines choses. Le problème, c'est plus les api des navigateurs. Mais le langage en lui même a vraiment des bonnes idées.

      Bon, il a aussi des trucs nuls comme pas de valeurs par défaut pour les paramètres d'une fonction.

      Envoyé depuis mon lapin.

  • # CouchDB

    Posté par  . Évalué à 2.

    Mentionnons également CouchDB (http://couchdb.apache.org ) qui développe une approche complémentaire : la pénétration de javascript dans la base de données.

    Les applications lourdes en javascript ont de plus en plus tendance à générer leur HTML à partir de données encodées en JSON (http://www.json.org/ ). Plutôt que de générer ce json côté serveur à partir de la base de données, l'idée est de stocker directement ces données en JSON, et de les accéder avec un moteur puissant et distribué écrit (partiellement) en Erlang (http://www.erlang.org/ ).

    Les requêtes base de données sont écrites en javascript en suivant le principe MapReduce(http://labs.google.com/papers/mapreduce.html ). Cela représente un peu plus de travail en perspective que les requêtes bases de données abstraites habituellement par un framework Web comme Rails ou Django, mais au moins, le développeur n'a pas l'impression de confier une partie critique de son appli web à un blob SQL dont il ne maîtrise (habituellement) pas tous les rouages. Et puis, si l'application est populaire, les problèmes de montée en charge reviennent à la face du développeur qui doit optimiser ses accès base de données de toute façon.

    L'inconvénient majeur par rapport à SQL est que, si le système est distribué, le contenu de la base n'est pas cohérent : en parlant à deux serveurs différents, on peut avoir deux versions chronologiquement décalées du même objet. Mais le problème n'est pas si important dans l'univers des applis web (les données à jour apparaîtront au prochain rechargement). Et CouchDB gère les conflits.

    Il est donc possible, avec un moteur de Javascript serveur et CouchDB, d'avoir un framework web qui génère en Javascript la page lors du chargement initial. Puis lorsque l'utilisateur interagit avec le site, le visuel est regénéré côté client, en utilisant les mêmes fonctions, et le client interagit directement en échangeant du JSON avec l'interface REST de CouchDB (http://en.wikipedia.org/wiki/Representational_State_Transfer ) plutot qu'avec le framework.

    Bref, je vous encourage à l'essayer. Un peu jeune pour être en production mais c'est tellement plus naturel que du SQL :)

    • [^] # Re: CouchDB - J'ose!

      Posté par  (site web personnel) . Évalué à 9.

      la pénétration de javascript dans la base de données.

      OH OUI! Plus fort!!!!!

    • [^] # Re: CouchDB

      Posté par  . Évalué à 7.

      Il faut vraiment voir les bases de données comme un truc où stocker trois tuples qui se courent après.

      Je n'ose imaginer une base de donnée de taille normale (prenons linuxfr) en json.

      Il m'arrive de stocker trois trucs dans du json, mais de là à en faire le format de stockage d'une base de donnée, faut vraiment avoir des xeons à n'en plus finir, et ne pas être écolo.

      Envoyé depuis mon lapin.

    • [^] # Re: CouchDB

      Posté par  . Évalué à 2.

      Un peu jeune pour être en production mais c'est tellement plus naturel que du SQL

      Et pour les jointures, les requêtes imbriquées etc., ça reste "naturel" ? :)

  • # Witty

    Posté par  (site web personnel) . Évalué à 1.

    J'aimerais également citer l'honorable projet Witty:
    http://www.webtoolkit.eu/wt
    http://www.webtoolkit.eu/widgets#/
    En plus de proposer une façon de programmer similaire à QT, on peut également developper avec du Java et du Ruby.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.