Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Enerian

38PARTAGES

10  0 
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
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 : Sélectionner tout
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de nouknouk
Modérateur https://www.developpez.com
Le 20/02/2013 à 23:01
Je plussoie sur l'intérêt du Javascript pour deux raisons principales:

1) la production de code dans un projet où la plus grande partie du 'business' est basée sur la gestion d'événements (typiquement, un projet avec des problématiques réseau ou de l'IHM).

La programmation en asynchrone est évidemment la règle, et dans ce domaine, Javascript apporte un énorme avantage: non pas l'asynchrone en lui-même (qui est effectivement possible avec tout langage), mais les closures. C'est la capacité de capturer un contexte au moment où on définit la callback qu'on va pouvoir réutiliser quand cette dernière sera appelée, plus tard. Et c'est primordial puisque quand une callback nous approte la 'réponse' à notre 'demande', on va vouloir la traiter en fonction du contexte qui était celui quand on a fait ladite demande:
Code : Sélectionner tout
1
2
3
4
5
 
var myCurrentValue = 123; 
p.requestRemoteData( /* onDone*/ function(data) { 
   debug("the data is "+data+" ; when i requested it, myCurrentValue was "+myCurrentValue); 
});
2) la souplesse du code et l'introspection 'naturelle': il ne faut pas oublier que beaucoup de règles qu'on s'impose quand on écrit dans un lagange 'strict' sont avant tout là pour éviter au développeur de faire n'importe quoi (en plus de raisons d'optimisation au compile-time). Mais passé une certaine expérience, on a complètement intégré ces 'bonnes pratiques', et on les applique plus parce qu'on y est obligé, mais parce qu'on a compris leur intérêt. Dans ce cadre, la souplesse permet à la fois d'éviter de perdre du temps à taper du code verbeux juste pour être 'compliant' avec les 'gardes fous', et d'autre part permet de retrouver de la liberté de 'transgresser' ces règles quand on estime qu'on a intérêt à le faire.

Un exemple: le pattern observer, en Javascript, c'est trivial, il n'y a rien de spécial à faire du côté des observateurs (myObj1, myObj2), si ce n'est définir le callback qui nous intéresse, avec pour seule convention, son nom:

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
 
var observers = [ ]; 
 
// register observers 
observers.push(myObj1, myObj2); 
 
// emit myEvent(myEventValue) in my observable 
for (var i=0; i
Autre chose: l'introspection. Faire une classe de 'debug' qui va prendre une instance d'objet quelconque et 'wrapper' toutes ses méthodes pour ajouter par exemple un debug("telle fonction est appellée avec les paramètres (a,b,c)"), c'est une boucle 'for' et 10 lignes de code qu'on peut ensuite appliquer sur n'importe quel objet à n'importe quel moment.

Autre chose: l'évaluation dynamique du code: perso, dans mon projet, le code est au chaud sur mon serveur ; quand un client lance mon programme, il lance une sorte de bootstrap qui va récupérer la dernière version du code sur le serveur ; si je veux changer un bout de code, je le publie sur le serveur, le déploiement est instantané et ne nécessite aucune action supplémentaire.

Vous l'aurez compris, plus les choses avancent, plus je ne veux plus faire du JS dès que c'est possible (et ça ne l'est pas toujours, ou pour l'ensemble du projet), tellement l'efficience est grande pour écrire du code.

Je rejoins néanmoins une critique à demi formulée ci-dessus: dans le contexte d'un projet perso où on est leur seul à développer, avec ses habitudes, ses conventions, ses 'bonnes pratiques', et donc avec un code totalement cohérent du début à la fin, c'est parfait.
Mais dans le cadre d'un projet plus ambitieux, avec de nombreux codeurs, qui vont et viennent, avec une expérience et une rigueur hétérogènes, ça demande une rigueur et un formalisme qu'il me paraît de plus en plus difficile à atteindre au fur et à mesure que l'équipe grossit.

Autre critique, qui dépend plus du 'business model' du projet: faire du 'closed source' avec du JS, grosso modo on peut oublier ; c'est pas avec la piètre obfuscation que permet un tel langage interprété qu'on peut espérer ralentir ou décourager longtemps celui qui voudra faire du reverse engineering ou vous piquer votre code pour le réutiliser dans son projet.

Bref, le Javascript, ça peut vraiment être super productif, mais pour le développeur chevronné, qui a déjà pas mal de bouteille et beaucoup d'expérience passée dans plusieurs langages 'plus stricts'. Sinon, c'est le bouillon assuré, car la frontière est mince entre un beau code efficient et un gros plat de spaghettis bourré de bugs et in-maintenable.

My 2 cents.
9  1 
Avatar de jason42
Membre régulier https://www.developpez.com
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)
8  2 
Avatar de Bovino
Rédacteur https://www.developpez.com
Le 21/02/2013 à 18:06
Citation Envoyé par marts
je crois que c'est l'ignorance ou l'incompréhension de ce concept qui fait que beaucoup de développeurs critiquent le JS.
C'est sûr que si on essaie de faire du Java-like en JS, on rencontre de nombreux problèmes. Parce que ce n'est tout simplement pas fait pour ça.
Citation Envoyé par magnus2005
Oui mais quand je dis POO "partielle" c'est pour indiquer les problèmes du type this qui est peut être égal à null dans le cours d'une méthode (surtout avec les callback) et les lacunes dans la gestion de l'encapsulation. Sans son prototypage le Javascript serait une techno vraiment trop limitée.
Désolé, mais j'ai l'impression que tu rentres exactement dans ce que décris marts...
D'une part, this ne peut pas valoir null. Si tu fais un alert(this) dans la console du navigateur, ça t'affiche [object Window], si tu fais un console.log(this) dans Node, tu obtiens {}.
Ensuite, si tu connais un peu le fonctionnement d'un callback et le mécanisme asynchrone de JavaScript, tu es sensé pouvoir savoir à quoi correspond this quand tu l'utilises, mais il faut surtout comprendre que cette valeur n'a pas le même comportement que dans d'autres langages.
Pour ce qui est de l'encapsulation, là aussi, elle est faisable (et facilement même) en JavaScript :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
var a = 'toto';
var MonConstructeur = function(){
    var a = 'foo';
    this.a = 'bar';
    this.getA = function(){
        return a;
    }
};
var my = new MonConstructeur();
console.log(a);
console.log (my.a);
console.log (my.getA());
Bref, quand on connait le fonctionnement de JavaScript, il n'y a pas de surprises.
6  0 
Avatar de nouknouk
Modérateur https://www.developpez.com
Le 22/02/2013 à 13:05
Citation Envoyé par magnus2005 Voir le message
J'ai fait du C++ et utilisé des callbacks mais le souci est que manifestement la grande majorité des développeurs qui n'ont pas travaillé avec ce type de techno ne sont pas très au fait de type subtilité dans le modèle mémoire.
Tu te trompes de cible, le JavaScript n'est pas en cause, c'est le manque de connaissance des développeurs dans ton exemple.
Un marteau n'est pas un mauvais outil en soi bien qu'on puisse s'en servir pour tuer quelqu'un. Même principe ici.

Pour ce qui est de l'encapsulation
A nouveau, c'est une mauvaise utilisation du langage, pas un défaut du langage en lui-même.
Ce serait un défaut du lanage si JS ne permettait pas de définir des variables avec des portées distinctes, mais ce n'est absolument pas le cas: il suffit de savoir qu'une variable, en Javascript, ça se déclare avec "var maVariable", et JS propose l'ensemble des notions de portée qu'il faut.

Impossible de protéger (private) un attribut même avec le mot clef.
Ca rejoins ce que je disais avant: le JS est très permissif ; ce n'est pas le langage qui interdit les mauvaises pratiques, c'est le développeur qui doit savoir lui-même coder avec un peu plus de rigueur.
Pour rappel, un attribut private ou public ça n'a pas de sens au niveau du code exécuté ; un attribut est un attribut, point barre. Ca n'a de sens que comme garde fou imposé par le compilo d'un langage qui propose ce genre de 'feature' pour empêcher le codeur peu rigoureux de faire n'importe quoi.
6  0 
Avatar de marts
Membre averti https://www.developpez.com
Le 21/02/2013 à 14:11
Citation Envoyé par magnus2005 Voir le message

mais en JavaScript avec le POO "partielle" ça donne ce genre de chose
Citation Envoyé par jason42 Voir le message

Effectivement JS n'est pas totalement orientee objet
Citation Envoyé par magnus2005 Voir le message

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.
On ne fait pas de la POO "partielle" avec Javascript mais de la POO par prototypage.
C'est très différent, et je crois que c'est l'ignorance ou l'incompréhension de ce concept qui fait que beaucoup de développeurs critiquent le JS.
C'est sûr que si on essaie de faire du Java-like en JS, on rencontre de nombreux problèmes. Parce que ce n'est tout simplement pas fait pour ça.
5  1 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 19/02/2013 à 0:39
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.
3  0 
Avatar de camus3
Membre éprouvé https://www.developpez.com
Le 19/02/2013 à 6:52
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.
4  1 
Avatar de jason42
Membre régulier https://www.developpez.com
Le 19/02/2013 à 9:03
@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 : Sélectionner tout
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 : Sélectionner tout
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
5  2 
Avatar de nouknouk
Modérateur https://www.developpez.com
Le 21/02/2013 à 10:00
Citation Envoyé par parrot Voir le message
Que propose Node.js pour la sécurité?
Le Javascript permet intrinsèquement moins d'attaques, car il offre déjà une surcouche d'abstraction par rapport au système qui l'exécute en dessous.
Un exemple comme un autre, tu ne risques pas de faire de buffer overflow avec du JS.

Pour le reste, j'aurais tendance à penser que la sécurité dépend pour beaucoup de l'API exposée par le soft qui embarque l'interpréteur JS. Il faut comprendre que JS est un univers totalement clos par défaut ; les seules ouvertures qu'on autorise vers l'extérieur sont celles qui ont été délibérément ajoutées dans l'API.

Un exemple concret: JS a été choisi pour Elixir, le 'SDK' proposé par free au 'grand public' pour développer des applications sur l'ancienne freebox (HD) ; la raison première était justement que ça minimisait les risques de hack de leur box.

Que se passe-t-il en cas d'exception? S'il n'y a qu'un thread et qu'il plante, on se trouve devant un DoS.
Si une exception est levée, soit elle est catchée par une partie du code JS, soit elle va remonter jusqu'au serveur qui va (à priori) simplement la logger ... et attendre le prochain événément à traiter.

N'oublions pas qu'on est dans de l'événementiel: saborder la pile d'exécution en cours de traitement n'empêchera pas d'être toujours là pour répondre à l'événement suivant.
3  0 
Avatar de xarkam
Membre confirmé https://www.developpez.com
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
2  0