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
Tags
Réseaux sociaux


 Discussion forum

Le , par Enerian, Membre émérite
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 :




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 ?


 Poster une réponse

Avatar de xarkam xarkam
http://www.developpez.com
Membre confirmé
le 18/02/2013 17:49
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
Avatar de Alshten Alshten
http://www.developpez.com
Membre confirmé
le 18/02/2013 18:31
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.
Avatar de camus3 camus3
http://www.developpez.com
Membre Expert
le 18/02/2013 18:46
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.
Avatar de coolspot coolspot
http://www.developpez.com
Membre confirmé
le 18/02/2013 20:24
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 ?
Avatar de Farid63 Farid63
http://www.developpez.com
Membre émérite
le 18/02/2013 20:41
Citation Envoyé par coolspot  Voir le message
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.
Avatar de Mr_Glopinous Mr_Glopinous
http://www.developpez.com
Membre régulier
le 18/02/2013 20:56
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 )
Avatar de magnus2005 magnus2005
http://www.developpez.com
Membre confirmé
le 18/02/2013 21:21
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.
Avatar de magnus2005 magnus2005
http://www.developpez.com
Membre confirmé
le 18/02/2013 21:40
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.
Avatar de magnus2005 magnus2005
http://www.developpez.com
Membre confirmé
le 18/02/2013 21:59
[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]
Avatar de jason42 jason42
http://www.developpez.com
Membre du Club
le 18/02/2013 22:27
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 ^^)
(en anglais mais sous titre en français)
Offres d'emploi IT
Développeur mobile (H/F)
CDI Mission
CDS SOFT - Ile de France - Paris (75008)
Parue le 01/07/2014
Conception et développement Knowl
Stage
Société Générale France - Ile de France - Paris (75000)
Parue le 09/07/2014
Consultant confirmé SAP BI BW/IP (h/f)
CDI
Atos Intégration - Ile de France - Bezons (95870)
Parue le 01/07/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula