La place de JavaScript côté serveur [Débat]

[Enerian]

Bonjour à tous,

Comme on peut le voir depuis quelques temps, le langage JavaScript est en plein essor.
Ce langage a la réputation d'être le « langage qui s'exécute dans le browser ». Et pourtant, lors de sa création pour Netscape en 1995, le langage (alors dénommé LiveScript) a été destiné par son auteur, Brendan Eich, à une utilisation côté serveur. Le langage a été renommé JavaScript un peu avant sa sortie pour des raisons marketing (Sun et Netscape étaient partenaires et la JVM très populaire). Ce n'est qu'en 1996 que Netscape écrit une implémentation cliente de JavaScript pour son navigateur. C'est le succès dudit navigateur qui déclenche l'adoption massive du langage côté client.
Ces informations proviennent de Wikipedia, que je vous invite à consulter pour en savoir plus.

Aujourd'hui, et contrairement aux croyances courantes, JavaScript est loin de n'être utilisé que dans les navigateurs. Pour citer quelques exemples :

• Qt encourage l'utilisation de JavaScript avec son module QtQuick (source) ;
• GNOME encourage l'utilisation de JavaScript pour créer des applications dans son environnement (source) ;
• Adobe propose ExtendScript, une implémentation JavaScript respectant la norme ECMAScript et ajoutant des fonctionnalités, pour scripter beaucoup de ses applications (source) ;
• MongoDB, un système de bases de données NoSQL orienté document et stockant les données en JSON, permet dans sa console des traitements JavaScript.

JavaScript côté serveur

Comme on a pu le voir dans le paragraphe précédent, JavaScript a été conçu à l'origine pour être un langage exécuté côté serveur. Depuis, plusieurs projets d'utilisation server side du langage ont vu le jour. Pour en citer quelques-uns :

• Node.js, le cas le plus connu, né en 2009 des mains de Ryan Dahl, travaillant pour Joyent. Je détaille ce cas ci-après ;
• APE pour Ajax Push Engine, composé d'un framework JS client et d'un serveur Comet (Comet est une méthode permettant de paralyser le plus longtemps possible une requête HTTP côté serveur afin de permettre des PUSH) ;
• vert.x permet la création d'applications réseaux asynchrones dans plusieurs langages tels que JavaScript, Ruby ou Python. La plateforme en elle-même est codée en Java.

Le cas Node.js

Le cas le plus courant d'utilisation de JavaScript côté serveur est Node.js. Il s'agit d'une plateforme permettant de développer des applications réseaux asynchrones rapidement et simplement. Ces applications monothreadées peuvent prendre en charge une quantité très élevée de requêtes simultanément. Cette technologie a acquis rapidement une grande popularité et de nombreux modules sont maintenant disponibles (cf. NPM). Il est à noter que Node.js fournit nativement plusieurs API asynchrones listées ici.

Voici un exemple type de code Node.js, tiré du site officiel :

Code JavaScript :

1
2
3
4
5
6
var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

Ce code permet de créer un serveur Web écoutant en local sur le port 1337 et qui renvoie Hello World pour chaque requête.

De nombreuses entreprises adoptent Node.js pour répondre à leurs besoins ou pour répondre aux besoins de leurs utilisateurs. Parmi les plus connues, on peut citer :

• LinkedIn : son utilisation de Node.js a permis de diviser par 10 le nombre de serveurs utilisés ;
• Yahoo : projet Cocktails ;
• eBay : projet ql.io ;
• Microsoft : participation au portage de Node.js sur Windows.

Réactions

Cette utilisation de plus en plus massive de JavaScript côté serveur soulève des réactions très diverses, allant de l'enthousiasme au scepticisme en passant par le dégoût.
Certains considèrent que sa puissance et sa souplesse font de lui une solution idéale pour résoudre certaines problématiques modernes. Pour d'autres, JavaScript est un langage mal conçu et son utilisation massive n'est pas de bonne augure pour l'avenir du développement. JavaScript a aussi auprès de nombreux développeurs une réputation de langage simpliste pour amateurs et bidouilleurs.

Par ailleurs, cet essor de JavaScript a vu naitre plusieurs projets visant à le remplacer (Dart, par Google), à l'étendre (TypeScript, par Microsoft) ou à l'améliorer (CoffeeScript). Pour exemple, voici ce que donne le code donné ci-dessus en CoffeeScript :

Code CoffeeScript :

1
2
3
4
5
6
http = require 'http'
http.createServer (req, res) ->
  res.writeHead 200, 'Content-Type': 'text/plain'
  res.end 'Hello World\n'
.listen 1337, '127.0.0.1'
console.log 'Server running at http://127.0.0.1:1337/'

Remarque : en CoffeeScript, les parenthèses sont optionnelles mais supportées. CoffeeScript apporte surtout du « sucre syntaxique », mais également le support des classes et de l'héritage, tout en gardant l'esprit JavaScript. Un code CoffeeScript est compilé en un code JavaScript lisible.


Débat

Le but de ce sujet est de créer un débat argumenté autour de l'utilisation de JavaScript côté serveur : qu'en pensez-vous et surtout pourquoi ?

[xarkam]

On a eu la mode Js coté client pour alléger les serveurs. Maintenant c'est l'inverse.

Je code une appli web en C# (pas en asp.net). J'ai été aussi confronté à l'utilisation de Js côté serveur pour le traitement des données, mais est-ce bien utile? C# est un langage très complet, alors quelle est la plus value apportée ?

A la base, je voulais utiliser handlebars côté serveur, mais je me suis tourné vers stringtemplate.

Je trouve qu'il faut un bon équilibre entre ce que fait le client et le serveur. d'ailleurs html5 vas dans le sens de moins de traitement sur le serveur non ?

ps: petite coquille: Ajoud'hui -> Aujourd'hui

[Alshten]

Ca dépend de l'utilisation. Quand il s'agit de générer des pages web ou bien faire une API Rest qui gère une base de données, Node va être super rapide que ce soit à développer ou à exécuter, quand on utilise les bons outils.

Par contre s'il s'agit de faire du gros traitement de données ou de l'analyse complexe de données sur de grosses bases de données, je suis pas sûr que l'utilisation de Node soit approprié.

Dans tous les cas l'utilisation de CoffeeScript est à mon gout indispensable.

[camus3]

Node est un choix , il n'est pas imposé , et ne souffre pas des défauts de javascript coté client ( système de modules , pas de contraintes de compatibilité ou d'API non supportés, donc évolution rapide , pas de DOM ... ) .

Bref , les devs font ce qu'ils veulent coté serveur , c'est leur problème. Mon problème c'est javascript coté client...

Zavez oublié wakanda coté serveur , et couchdb qui permet de créer des applications javascript juste avec une base de donnée.

[coolspot]

Je vais peut etre poser une question bête mais c'est quoi l'interet de js cote server ?

Il y a une valeur ajoutes par rapport a des langages comme java ou .net ?

[Farid63]

Envoyé par coolspot

Je vais peut etre poser une question bête mais c'est quoi l'interet de js cote server ?

Il y a une valeur ajoutes par rapport a des langages comme java ou .net ?

Peut-être la possibilité de faire du PUSH ?
Si vous avez une idée de comment faire ça en Java, je prends.

[Mr_Glopinous]

De ce que j'en sais (non testé) il existe cometd (atmosphere comme framework pour aider toujours si j'ai bien compris et non tester non plus )

[magnus2005]

La javascript est un mal extrêmement nécessaire coté client pour le moment car c'est le seul langage de programmation disponible sur les browsers. Si Dart ou Typescript et Actionscript existe c'est bien le preuve que les grands de l'industrie ont bien conscience du problème mais je suis atterré que des concepteurs d'outils l'utilise encore du coté serveur.

JavaScript est un langage mal conçu et son utilisation massive n'est pas de bonne augure pour l'avenir du développement.

Si il demeure dans l'état c'est pas bon signe. mais après tout PHP 3 et 4 n’était pas génial, Java 1 non plus et les 1er .NET pas terribles mais il ont largement évolué depuis, peut être qu'un jour cela arrivera.(Comme par exemple l'actionscript qui n'a que des avantage par rapport au javascript car il corrige la plupart de problèmes )

JavaScript a aussi auprès de nombreux développeurs une réputation de langage simpliste pour amateurs et bidouilleurs.

C'est que ces développeur ne connaisse pas le JavaScript. Certes il permet de faire d’infâme bidouille mais pour tout faire tourner de façon pérenne il faut beaucoup de sérieux du fait des nombreuses implémentations et des bugs de conception du JavaScript. Bidouilleur oui mais des pros.

Exemple :
En JavaScript
"Je pense donc je suis" ben en fait non.

Code :

1
2
3
4
5
6
7
8
 
//Je suis dans une méthode dans une classe enfin c'est ce que le développeur JavaScript fait croire
this.mavariable = 2 ;
//je fais de une requête en Ajax ...
alert(this.mavariable); //vieux message d'erreur car this est null; 
//ce qui n'a aucun sens dans la POO sur la papier et dans tous les autres langages que je connais
// mais en JavaScript avec le POO "partielle" ça donne ce genre de chose alors pour expliquer
// à un développeur qui n'a pas fait de C/C++ ce n'est pas gagné.

Variable par défaut globale = Mine de bug intarissable (déjà que les global c'est pas terrible et terme de bug)

pas de typage pour les variables = Mine de bug intarissable.

Type et contexte très volatile ce qui donne des effets bien bizarres = Mine de bug intarissable.

C#, Java et même PHP et surtout l'ActionScript (et bien d'autres) sont tellement plus complet et mieux gérer que le JavaScript que je ne vois pas l’intérêt de le choisir coté serveur.
C'est toujours malheureux que de bon outils se fourvoie sur leur langage d'exploitation (Node.js avec javascript, Oracle DB avec le PL/SQL) et après ce sont les malheureux développeur qui passe après qui doivent s'en servir.

[magnus2005]

Node est un choix , il n'est pas imposé , et ne souffre pas des défauts de javascript coté client

Il tourne avec le V8 engine qui est celui de chrome et donc à les mêmes propriétés que sa version cliente dans chrome.

A la question pourquoi du js dans node :
[Mode apposition des mains sur ma G500]
A mon avis cela doit venir de V8 plus que du Js en lui même.
[/Mode apposition des mains sur ma G500]

Après voici une explication qui est dans wikipedia english

http://en.wikipedia.org/wiki/Nodejs

After trying solutions in several other programming languages he chose JavaScript because of the lack of an existing I/O API. This allowed him to define a convention of non-blocking, event-driven I/O.

ceci me semble très léger comme justification.

[magnus2005]

[Mode apposition des mains sur ma G500]
Je pense qu'en utilisant V8, les concepteurs ont pris une base bien maintenu et qui en C++ comme le reste de Node.Js. Du coup c'est plus facilement intégrable et les wrapping sont natif entre Javascript et le C++ via V8 (un peu comme JNI pour Java ou les modules en C pour le PHP). Ceci n'est que mon avis et tient un peu mieux la route que la justification de l'article wikipedia
[/Mode apposition des mains sur ma G500]

[jason42]

Qu'apporte js cote serveur?:

le mode asynchrone! et ça ça fait déjà une énorme différence!
grace aux traitements asynchrone, on a un gain de perf extraordinaire.
certes l'asynchronisme n'est pas réservée au javascript seulement il est natif dans javascript, et aujourd'hui ce qui se fait de mieux dans ce domaine est node.js
node.js est utilisée pour les jeux en réseau, les sites web, les webservices...
et concernant les webservice le celebrissime module socket.IO est PARFAIT (il permet de gérer extrêmement facilement les webSockets).
Donc faire du vrai push!
petite explication pour ceux qui ne savent pas:
avant html5 et les websockets on utilisait AJAX (pauvre de nous), AJAX n'est pas bidirectionnel (ce qui signifie que le serveur ne peut pas de son propre chef envoyer des infos au client, le serveur ne peut que répondre aux clients), et Donc lorsque le client a besoin par exemple d'avoir un flux a jour il est obliger de questionner le serveur toutes les X secondes. (ce qui est immonde, gaspillage de bande passante, de CPU etc). maintenant pour mettre a jour un flux on attend que le serveur nous envoie une donnee quand il le souhaite car Les WebSockets sont bidirectionnels! (et petit truc en plus qu'offre Socket.Io c'est qu'il peut faire fonctionner les websockets sur un vieux navigateur, en utilisant un peu le principe de cometd (qui simule le push en répondant le plus tard possible a la requête... c'etait la misère, et maintenant on node.js!).
@magnus2005
il existe plein de framework qui permettent de palier aux 'defauts' de js.
et JS est un meilleur choix car V8 est super puissant, multi plateformes et tres leger.
Java est lourdingue, pas orienter asynchrone, et s'execute dans une VM...
C# a peu pres la meme chose.

et aussi JSON, qui est le format natif de stockage de JS et qui est le meilleur dans son domaine.
Concernant le typage faible, ca permet un dynamisme enorme, est une réflexivité déconcertante, (faire de la reflexivite en java sans librairies est du masochisme pur et dur).
Bref on a souvent tendance a oublie les avantages de JS pour se concentrer sur ses défauts.
d'ailleurs je me souviens d'une video de douglas crawford qui parliat des bons cotes de javascript (il y en a quand meme ^^)
https://www.youtube.com/watch?v=_DKkVvOt6dk (en anglais mais sous titre en français)

[swirtel]

Et Erlang ?

Distribuable, concurrent, mpi et simplement multicore.

[javan00b]

La nature asynchrone de JS permet d'avoir un script qui ne bloque jamais durant l'execution, meme durant une requete, l'execution du script continue jusqua ce que l'information sois disponible et puis ensuite un callback est apellé.

Bien sur que pour des taches de calcul intensives ce n'est pas la technologie la plus adaptée, quoi qu'on peut parfois deleguer les calculs au client... tout depend de la sensibilité des données.

Mais pour des petits envoi de données brutes sans traitement, Il n'y aucune raison de ne pas utiliser NodeJS.

Il ne faut pas jouer au jeu des comparaisons avec les autres languages/framework serveur, JS/NodeJS excelle dans son domaine d'application.

[magnus2005]

Qu'apporte js cote serveur?:
le mode asynchrone!

jason42 peut tu développer en quoi le JavaScript est il un plus avec l’asynchrone ? La plupart des langages sont asynchrones à part certain pour de l'embarqué.

Pour autant que je sache les sockets sont implémentés dans la plupart des langages depuis bien longtemps. Dans Node.js c'est d'ailleurs fort probablement une API C++ qui fait le fait le job en back office via V8.

Effectivement Java et C# c'est relativement pareil.

Concernant le typage faible, ça permet un dynamisme énorme

Non en aucune façon tous pseudo avantage du non typage sont gérable plus proprement et plus simplement via Java ou C#. Sinon PHP est du même genre

est une réflexivité déconcertante,

Oui je n'appelle pas cela un avantage

V8 est super puissant, multi plateformes et très léger.

A mon avis c'est V8 qui fait bien pencher la balance. Ceci dit le Zend Engine est nettement plus répandu et rodée et le PHP possède bien plus de fonction serveur que le Javascript.

il existe plein de framework qui permettent de palier aux 'defauts' de js.

Ce que j’espère c'est les défaut soit corrigés dans le langage lui même comme celui a été fait dans l'ActionScript ou bien avec PHP en passant de 3 vers la version 5. Tous le monde connait les grosses tares de conceptions mais plus de boite ne gère le Javascript depuis longtemps et du coup pas d'évolution majeurs
[Mode Bisounours]
Si Ms, Google, Oracle , IBM et Mozilla se mettait d'accord) se serait fait en clin d’œil il connaissent tous comment faire un bon langage de programmation. Ou par exemple prendre Dart comme language remplacement du JS se serait déjà un gros plus pour le dev.
[/Mode Bisounours]

[SylvainPV]

Voyons, quels sont les sites les plus fréquentés aujourd'hui ? Réseaux sociaux, sites de streaming musical et vidéo, webmails et outils en ligne. Leur point commun, c'est que le modèle requête-réponse classique n'est plus adapté pour eux. On met du AJAX partout, et bientôt des Server Sent Events et des Web Sockets. Certains disent même que les "single page websites" pourraient devenir une nouvelle norme en web front.

Je fais du dev côté serveur en JavaEE et en Node.JS. Le premier est bien plus mature, fiable et complet en outils et frameworks. Mais je dois reconnaître que pour un service RESTful vite fait bien fait, Node.js est un petit bonheur. Après, la permissivité du langage, on aime ou on aime pas. Mais c'est pas tant le Javascript qui est important, c'est juste une conséquence logique de l'évolution des usages du Web.

[javan00b]

Envoyé par magnus2005

jason42 peut tu développer en quoi le JavaScript est il un plus avec l’asynchrone ? La plupart des langages sont asynchrones à part certain pour de l'embarqué.

Pour autant que je sache les sockets sont implémentés dans la plupart des langages depuis bien longtemps. Dans Node.js c'est d'ailleurs fort probablement une API C++ qui fait le fait le job en back office via V8.

Effectivement Java et C# c'est relativement pareil.
[/Mode Bisounours]

N'importe quel operations que ce sois sur une base de donnée ou un flux de donnée quelquonque, rien n'est bloquant, tout est asynchrone. Au lieu d'attendre que la base de donnée renvoie les donnés etc, le script continue son execution normal, quand les données sont recus, le callback s'execute... tout est fait pour ne pas gaspiller de cycles du CPU.

Il n'y a pas de gestion de threads, tout est geré a l'interne, on programme exactement comme s'il n'y avais qu'un fil d'execution.

[camus3]

Il tourne avec le V8 engine qui est celui de chrome et donc à les mêmes propriétés que sa version cliente dans chrome.

Je ne parle absolument pas de V8 , mais de tout l'aspect dévelopment DOM coté client. V8 est un moteur javascript , pas une implémentation du DOM et javascript coté serveur n'a rien à voir avec manipuler le DOM. Donc pas de problèmes d'incompatibilités , inconsistances et autres , le code n'a qu'a fonctionner sur l'executable coté serveur. Pourquoi tu me parles de V8 ? rien à voir avec mon message, je parle des API et le support de multiples navigateurs coté client , ce qui n'est pas le cas avec NodeJS.

[camus3]

Je vais peut etre poser une question bête mais c'est quoi l'interet de js cote server ?

NodeJS utilise l'event loop de v8 pour créer des applications asynchrones. et v8 est un moteur javascript , le but n'est pas d'utiliser javascript pour faire du javascript , mais d'utiliser l'event-loop de v8 pour faire des applications non-bloquantes niveau I/O.
L'avantage dans une application web , c'est que cela permet de créer des serveurs qui supportent une très grosse montée en charge et cela avec un seul thread.

[jason42]

@magnus2005 le plus de JavaScript est qu'il est mieux adapté pour faire ce dont parle javan00b:
- un programme en node.js est une succession de callbacks dans tous les sens, et faire ça en c++ est assez suicidaire (je ne parle pas de la nouvelle norme du c++ qui permettent les fonctions lambdas, mais a l'epoque ces normes n’étaient pas implémentés). D'ailleurs Qt par exemple a son propre c++ qui permet de gérer beaucoup mieux les callbacks tout en étant O.O (avec signal et slot). Qt est excellent mais pour y parvenir il a du creer des mots-cles qui n'existe pas en c++, le c++ n'est vraiment pas adapté pour ca.

-Effectivement JS n'est pas totalement orientee objet, mais ca lui permet d'etre plus souple, et plus en adequation avec node.
et surtout... require.js (qui permet de faire une sorte d'include, mais pas du tout la meme logique), sur lequel est basé en grande partie node.js est magique! (et je pèse mes mots ), rien a voir avec l'immonde include en c++ (qui, je le reconnais a ete corrigé dans java et c#). tu devrais vraiment jeter un oeil du cote de require.js, il gere les modules et abstrait la gestion des instances de module... enfin bref, magique.
et je tiens a dire que la POO n'est pas le saint graal, node.js est beaucoup plus orientée module si je puis dire qu'objet, au travers de node.js. d'ailleurs on utilise pas vraiment d'objet avec node. Je pense Vraiment que LE language le plus adapté dans cette situation est JS.
Concernant la réflexivité, j'ai eu a coder a Epitech, un moteur ORM (a la main), et c'est pas evident. en JS tout est sous forme d'une table de hash et modifiable a souhait, un exemple concret de ce qu'on fait en JS avec node:
J'ai un fichier conf.sql qui contient:

Code :

1
2
3
4
5
6
7
8
 
{
 "user": "root",
  "password" : "pass",
  "database" : "myBase",
  "host" : "localhost",
  "id" : 5
}

je veux creer un objet ayant ces proprietes (que je ne connais pas en avance), en java je passerais surement par des beans (corriger moi si je me trompe) et encore ce serait super compliqué.
en JS (avec node.JS), je fais.

Code :

1
2
3
 
var fs = require('fs');
var config = JSON.parse(fs.readFileSync('./config/conf.sql'));

et config est un objet qui contient des propriétés que je n'aurais déclaré nulle part; je peux donc modifier le fichier comme bon me semble, l'objet qui sera créé en aura toutes les propriétés.
c'est le genre de trucs très facilement faisable en JS que je n'essaierais même pas de faire en java ou autre.
Pour node JavaScript etait le meilleur choix, et chez Joyent ils s'y connaissent.
Je ne dis pas que JS est le meilleur langage, (dart n'existait pas à l’époque), mais pour faire des serveurs qui font des opérations simples et communique avec une DB ==> node.js

[magnus2005]

@camus

NodeJS utilise l'event loop de v8 pour créer des applications asynchrones. et v8 est un moteur JavaScript, le but n'est pas d'utiliser JavaScript pour faire du JavaScript, mais d'utiliser l'event-loop de v8 pour faire des applications non-bloquantes niveau I/O.

A mon avis cette justification me parait quand même nettement plus convaincante que les autres.

Effectivement JS n'est pas totalement orientee objet, mais ca lui permet d'etre plus souple

Pas du tout il n'y a qu'a voir avec PHP et Actionscript qui supporte la programmation procédurale et Objet à 100% avec toute la flexibilité des langages de script.

en JS tout est sous forme d'une table de hash et modifiable a souhait

Oui comme en PHP et c'est faisable en Java aussi et dans bien d'autre.
il est tout à fait possible de faire du code d'une qualité douteuse avec Java et à l'inverse faire du code à peu prés propre avec du Javascript.

Code :

1
2
 
var config = JSON.parse(fs.readFileSync('./config/conf.sql'));

Ceci va donner ce genre de code

Code :

1
2
 
var host = config["host"];

La on va retrouver certains désagréments juste avec une ligne de code

• Utilisation d'une littérale => ça va fatalement être difficile a détecté pour de future panne
• Un code hyper sensible au changement du fichier conf.sql => hyper dépendance => surcout de maintenance
• Problème pour connaitre quelles sont les propriétés disponibles dans la var config depuis le code cela nécessite de connaitre la définition de base du fichier pour travailler => future source de panne => futur haine de la part du développeur qui passera derrière.
• le responsable qualité va avoir les yeux qui saignent => surcout en soin médicaux
• Il faut être honnête aussi parfois des boss demandent de faire ce type de code pour augmenter les revenus sur la future TMA => prime

Ce type de code n'a sa place que dans un prototype jetable. Pour rendre pérenne il faut que tu construise une classe "Config" qui soit prédictible pour garantir son exploitation dans une application. Sinon sur le long terme les 5 minutes gagner à ne pas consolider ce code deviendra des dizaines de jours/homme gâchés. Surtout on ne sait jamais combien de temps va être exploité notre code autant le faire bien à peu prés proprement du 1er coup sachant que ça ne coute pas grand chose.
Ce type code je le rencontre souvent en PHP, Perl et Javascript. J'ai bossé sur le code de Mantis et Drupal et certaines parties en sont bourrés. Mais au fil du temps les partie de code plus récente s'améliore en qualité. Je prend l'exemple de la partie PHPUnit de Drupal qui est d'une qualité excellente.

Ceci dit les défaut du JavaScript en remette pas en cause le travail excellent qui est fait autour avec JQuery ou dans Node.js.

Pour info :
J'ai codé un ORM avec PHP en m'inspirant d'Hibernate que j'avais trouvé excellent cela a été simple (Merci Zend Framework et l'XP).