Discussion :

[Invité]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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 ?

[FaridM]

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.

[leto42]

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

Merci d'avoir mentionné Wakanda, je trouvait également que ça manquait

Pour ceux que ça interesserait, j'ai fait un certain nombre de présentation sur JavaScript côté serveur dont les slides sont disponibles:

State of the art - server side JavaScript - web-5 2012

NoSQL and JavaScript: a love story

End to-end W3C - JS.everywhere(2012) Europe

[fredoche]

"This document has either been removed or made private by its owner"

Voici ce que l'on voit de tes slides pour l'instant leto (duc ou empereur ?)

[leto42]

"This document has either been removed or made private by its owner"
Voici ce que l'on voit de tes slides pour l'instant leto

C'est a priori un bug du plugin slideshare du forum, les slides sont visibles en cliquant sur le titre

(duc ou empereur ?)

empereur

même si son choix peut être considéré comme inhumain ou detestable, je n'ai pu m'empêcher d'être impressionné par le sacrifice qu'il a fait pour sauver l'humanité, un personage qui laisse perplexe

[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.

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

[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]

[javan00b]

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.

[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.

[swirtel]

Et Erlang ?

Distribuable, concurrent, mpi et simplement multicore.