JavaScript côté Serveur

« Où est le temps pour la lecture et la recherche ? Où est le temps pour apprendre à se documenter ? Où est le temps pour la réflexion individuelle et collective ? ». Jack Lang.

Lorsqu'on m'a parlé de JavaScript côté serveur, j'ai cru qu'il s'agissait d'une nouveauté. Ce n'était pas le cas ; dans l'équipe R&D, certains utilisaient déjà du Javascript côté serveur dans les années 97-98 avec le serveur resin de Caucho.

Une introduction, pour ceux qui aiment les introductions

Qui dit JavaScript, dit navigateur !

Le JavaScript est l’un des langages les plus populaires, si ce n’est pas le plus populaire. Pratiquement, toute application web utilise JavaScript. Le plus utilisé, mais aussi le plus méprisé.

Jusqu’à un passé proche, qui dit JavaScript, dit navigateur. Avec la différence et les incompatibilités entre les moteurs JavaScript des navigateurs, le développement JavaScript demeure pénible! Interprété et exécuté côté client, plusieurs restrictions sont imposées à ce langage. Et si on passait au JavaScript côté Serveur ?

L’idée date de 1996 lorsque NetScape a implémenté le premier composant JavaScript coté serveur. Ce composant baptisé LiveWire a été inclus dans le serveur Enterprise Server 2.0. Puis, Netscape a planifié de développer un navigateur totalement en Java. Pour ce faire, elle a eu besoin d’une implémentation JavaScript en Java, une implémentation qui entrainera après la naissance de Rhino, un interpréteur JavaScript côté serveur.

Bien que l’idée a été abandonnée dans les années suivantes, on assiste aujourd’hui à des tentatives plus sérieuses pour utiliser JavaScript coté serveur, dans l’optique de ne plus avoir à se préoccuper de savoir quel navigateur exécutera le code, et d’autre part d’avoir moins de restrictions imposées au langage.

JavaScript côté serveur, pourquoi?

Aujourd'hui, des sérieuses tentatives visent à concevoir et implémenter des serveurs JavaScript. Ceci est du aux avantages qu'offre ce langage côté serveur.

  • Côté fonctionnel
    • Couche d'abstraction des moteurs JavaScript des navigateurs: certains serveurs JavaScript proposent une implémentation du DOM, ce qui offre une couche d'abstraction supplémentaire du navigateur et une souplesse de développement.
    • Optimisation du temps de développement: une des utilités de JavaScript est la vérification des données côté client. Or, en général, et pour des raisons de sécurité, de cohérence et d'intégrité des données, ces tests sont vérifiés une deuxième fois côté serveur. Les vérifications sont donc ré-implémentées en langage serveur (java, .net...). Avec JavaScript côté serveur, il n'est plus nécessaire de redéfinir ces tests, il suffit d'exécuter le même code JavaScript, ce qui permet d'augmenter la productivité.
    • Minimisation des coûts: JavaScript est omniprésent dans presque toutes les applications web. Ainsi, le développement d'une application web nécessite une double compétence: JavaScript/langage serveur. Cette double compétence a son coût (soit en termes de connaissances, soit en termes du nombre de développeurs).
  • Côté technique
    • Rapidité des tests: JavaScript côté serveur permet d'accélérer les phases de tests. D'une part, il est plus facile d'utiliser les objets mock en JavaScript. D'autre part, pour tester le fonctionnement d'une application on n'a pas besoin d'une phase de compilation et redéploiement, comme en java par exemple. Il suffit d'interpréter directement le code écrit, ce qui permet d'améliorer la productivité.
    • Moins de code à écrire: Avec son son paradigme de prototypage, JavaScript permet de développer les mêmes fonctionnalités que d'autres langages de développement mais avec moins de code (jusqu'à un dixième de code).
    • Plus d'API de développement: toutes les limites du langage JavaScript imposées par les restrictions de sécurité ne sont plus appliquées côté serveur.

Les principales alternatives et solutions JavaScript côté serveur sont:

5 commentaires

  1. Il y a quand même plusieurs points qui me gènent dans cet article. Il est super orienté et a charge.
    Le premier point qui me perturbe, c’est que dans la vrai vie, une application Web utilise de nombreuses librairies Java ou .Net qui décharge le développeur de plusieurs choses :
    _ JUnit : peut tres difficilement etre remplace par JsUnit a mon sens
    _ Struts ou équivalent : Avec quelle lib Js allez vous gérer le workflow de l’appli ?
    _ Hibernate : Jaxer c est sympa mais comme mapping BD ou DTO ou a fait mieux
    _ les commons : digester et logging par exemple. Il existe quoi en JS ?
    _ JfreeChart
    _ POI : comment exporter en excel par exemple pour une appli bancaire

    J’en passe et des meilleurs comme l’identification par LDAP ou autre par exemple. En gros je trouve que c’est bien beau de faire du Js coté serveur mais que l’on s’assoit sur un paquet de service rendu par Java ou .Net et que la liste des inconvénient me semble plus longue que les avantages.
    Si maintenant on revient a faire du js de facon ciblée, comme le controle de saisie (et encore il existe quand même struts validator mais bon), on perd un des argument phare de n’utiliser qu’un seul langage.
    Si le besoin est d’utiliser un seul langage on pourrait aussi analyser l’idée de n’utiliser que du java via des tag Jsp aussi et du coup ne plus avoir a écrire de Javascript. Je pense que le marché et les clients vont plutôt dans ce sens. Ce à quoi s’ajoute le nombre de devers Java sur le marché en comparaison du nombre de dever Javascript.

    Pour le fait d’écrire un mock plus rapidement en Javascript qu’en Java, la encore c’ets un point de vue. En Java on déclare les champs, on génère autmomatiquement en deux clic les getters/setters et on utilise une lib comme easyMock par exemple pour générer des données. Je ne trouve pas que cela soit particulièrement difficile.

    Pour la phase de compil/déploiement, en phase de dev, quand on est sous Eclipse/Tomcat, le développeur n’a rien à faire, cela est automatique et quand même très rapide, donc pas tres impactant.

    Pour le « moins de code a ecrire » : je ne trouve pas que la syntaxe d’héritage ou d’utilsation du ‘super’ en javascript soit triviale et surtout connue de tous. Du coup soit on se limite sur l’héritage ou le super, soit on doit former les dévers.

    En résumé, soit on remet en cause l’architecture en 3 tiers, et dans ce cas pourquoi ne pas simplement faire du php qui a le mérite de faire la part belle a Js tout en fournissant un grand nombre de service au développeur, soit l’utilisation du Js coté serveur me semble très limité et discutable dans la vrai vie d’un projet client.

  2. Le débat n’est sans doute pas de remplacer java par javascript. Java a effectivement de très nombreuses librairies existantes et qu’il ne servirait à rien de réécrire.
    Javascript a cependant l’avantage d’être le seul langage nativement utilisable sur tous les navigateurs et capable de déclencher des modifications dynamiques dans les pages web. Il est vrai que cela n’impose pas à tous les développeurs d’être experts javascript : de nombreux frameworks tendent en effet à amener des couches abstraites de programmation. Certaines couches (comme Sweetdev-RIA) facilitent le développement des pages en utilisant des taglibs, d’autres comme GWT sont sensées rendre javascript invisible.
    Du côté poste client, certains considèrent qu’on peut utiliser Jquery sans connaître javascript…

    Le choix du langage d’implantation côté serveur (langages dynamiques/statiques, typés/pas typés, fonctionnels, orientés classe/instance ou prototype ou pas) est une affaire de goût (ou de choix client !) mais développer des applications web en ne connaissant que le langage serveur sans connaître javascript semble maintenant dépassé.
    Après, l’évolution d’ECMAScript vers une surcouche avec classe et typage (comme c’est le cas dans l’ActionScript d’Adobe Flex) permet sans doute de réconcilier les développeurs Java avec Javascript).

    En terme de développement côté serveur, l’idée me semble plus d’utiliser javascript là où il y a une réelle valeur ajoutée, c’est à dire :
    1) pour les traitements qui ne peuvent pas être réalisés par une couche d’abstraction du type « tag » (l’omniprésence actuelle de Java EL dans les pages JSP est une preuve de cette limite), par exemple pour l’implantation de validations nécessitant de l’évaluation de code. Javascript joue alors un rôle identique à celui d’OCL pour UML et a l’avantage de tourner à la fois sur le client et sur le serveur

    2) pour l’assemblage dynamique de composants et services préexistants (en java par exemple) lorsque le paramétrage atteint ses limites. L’utilisation de javascript pour le test est alors une opportunité complémentaire (et n’a pas pour objectif de remplacer les démarches et outils habituellement utilisés côté java, mais juste de pouvoir )

    3) plus généralement, toute utilisation en tant que langage de script, quand l’utilisation de langages compilés n’est plus appropriée

  3. Je reste perplexe sur le coté javascript coté serveur :S
    Est-ce qu’on va retrouver le problème d’interpretation du javascript suivant l’interpréteur du serveur qu’on a déjà avec les navigateurs ?

    Et puis je préfère java pour faire les traitements lourds(exemple mathématiques).
    Personne n’a eu des problèmes d’arrondi avec javascript ?
    ^_^

    En ce qui concerne le coté technique:
    –> rapidité des tests : … j’en suis pas très sur. Quelqu’un a testé du code javascript qui utilise un framework javascript (ex: Ext JS)?
    –> moins de code : tu peux t’orienter vers groovy ^_^.
    –> plus d’API développement ? là je comprends pas trop …

    Bref, javascript c’est bien pour faire des appels vers le serveur et des contrôles de surface(donc légers). Je trouve que coté navigateur avec les frameworks javascript ça devient très lourd sur le poste client. Je ne pense pas qu’on puisse faire tout ce qu’on fait en java avec du javascript ^_^.

    Sinon, il y a DWR qui permet de faire du reverse AJAX et générer du javascript coté client pour être appelé par le serveur et vice versa ^_^

    Enfin, on verra bien ce que ça donne avec Java 7 qui devrait avoir un moteur javascript(Rhino surement).

  4. Je pensais avoir déjà répondu à un certain nombre de ces points 🙂

    En fait je préfère renvoyer sur un article de Sun « scripting for java platform » qui expliquera la vision de Sun concernant l’avantage du scripting http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/ (cet article date de 2006 : rhino est déjà intégré dans java 6).

    Par ailleurs, les implantations javascript côté serveur devraient avoir des comportements beaucoup plus identiques que ceux sur les browsers : en fait, sur les navigateurs, même s’ils restent des disparités – rares – vis à vis de la norme ECMAScript, c’est surtout le support du DOM et des CSS qui peut donner l’impression que le comportement de javascript est différent. L’interpréteur lui même est rarement en cause.

  5. En ce qui concerne le javascript coté client, mes applications fonctionnent sans effort dans tous les principaux navigateurs sauf IE, le respect des standards et l’interopérabilité n’entrant pas dans la politique commerciale de Microsoft, si vous ne le saviez pas déjà.

    Concernant la lourdeur des certains dinosaures comme extjs que je ne remettrai pas en question, avec javascript coté serveur il devient possible de décharger le client (je pense aux smartphones) en exécutant un maximum de code coté serveur.

    D’un autre coté les smartphones et tablettes devenant plus smart (plus fun) et plus performantes, il est déjà possible d’installer NodeJS sur iOS et Android pour développer des applications javascript natives.

    NodeJS semble vouloir s’imposer comme « interpréteur » javascript (en fait le code est compilé dynamiquement) coté serveur comme coté client. Il est basé sur le moteur V8 de Google.

    Ok suivant ce qu’on va lui demander les rapport seront différents, mais pour une suite de Fibonnaci, V8 est à peine 1.5x moins rapide que le C et 20x plus rapide que PHP.

    Microsoft soutient le développement de NodeJS. eBay, linkedIn et Yahoo on craqué pour lui, tout comme moi.

    Très souple et modulaire, c’est un plaisir de développer avec NodeJS. Il suffit d’énumérer les classes/méthodes/propriétés qu’on souhaite exporter pour créer un module.

    Bien des choses restent à faire (bindings pour APIs en C, etc) mais la communauté est très active et rien ne vous empêche de mettre la main à la pâte et de publier vos modules (publics ou privés) avec npm qui permet de les déployer facilement et/ou en faire profiter la communauté.

    Pour des applications desktop multi-plateformes en HTML5/CSS3 basées sur NodeJS, placer le serveur coté client et utiliser le Chromium Embeeded Framework en lieu et place d’un navigateur est une idée dans l’air qui pourrait faire l’affaire (http://code.google.com/p/chromiumembedded/).

    A suivre..

    http://www.nodejs.org

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.