La place de JavaScript côté serveur,

Le langage devrait-il être limité à des scripts côté client ?

Les rubriques (actu, forums, tutos) de Développez

Réseaux sociaux

Le 18/02/2013, par Enerian, Membre expérimenté

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 ?

12345678

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

La place de JavaScript côté serveur, Le langage devrait-il être limité à des scripts côté client ?

La place de JavaScript côté serveur,

Le langage devrait-il être limité à des scripts côté client ?