Discussion :

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

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

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

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 - Visualiser dans une fenêtre à part

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 :

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

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

Ceci va donner ce genre de code

Code :

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

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

[jason42]

Effectivement le code de l'exemple n'est pas bon, mais c'est pour montrer les capacites reflexive du langage, et la simplicite de json.

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

oui je suis d'accord seulement je ne pense pas que v8 soit la seule raison, d'ailleurs j'ai retrouver un document sur nodejs.org dans lequel, ils expliquaient, entre autres:

Javascript designed specifically to be
used with an event loop:

-Anonymous functions, closures.
-Only one callback at a time.
-I/O through DOM event callbacks.
-The culture of Javascript is already
geared towards evented
programming.

Et a propos de la structure interne

-V8 (Google)
-libev event loop library (Marc Lehmann)
-libeio thread pool library (Marc Lehmann)
-http-parser a ragel HTTP parser (Me)
-evcom stream socket library on top of libev
(Me)
-udns non-blocking DNS resolver (Michael
Tokarev)

source:
http://nodejs.org/about/
il s'agit du fichier jsconf2009. (lien direct: http://s3.amazonaws.com/four.livejou...117/jsconf.pdf)
tout ça pour dire que javascript avait son importance lors du choix du langage, apparemment la loop-event utilisé n'est pas dans v8.
De plus les loop-event performantes existent dans tous les principaux langages. les frameworks mvc sont bases sur une loop event, Qt par exemple,
donc Ils ont quand meme fait un choix, un vrai concernant le langage.
D'ailleurs ils utilisent de plus en plus de JS dans le code de node.js. ça ne m’étonnerait pas qu'il y en ait même plus car il y a 3 ans il y avait 11000 lignes de C++, 6000 lignes de JS, et ils avaient déclare qu'il y aurait de plus en plus de javascript.

Pour conclure, JAVASCRIPT a quand même quelques avantages et Ces avantages ont pesé dans le choix du langage (plus que V8, qui n'a rien d'exceptionnel, si ce n'est qu'il est rapide).

[nouknouk]

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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<observers.length; ++i) {
    var obs = observers[i];
    if (obs.myEvent) 
        obs.myEvent(myEventValue);
}

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.

[parrot]

Que propose Node.js pour la sécurité?

Autant que je sache, il n'y a pas de gestion de session, ni d'authentification! 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.

[nouknouk]

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.

[singman]

Vous expliquez vos choix avec des arguments techniques, mais je vais apporter un coté plus de principe :

Utiliser Javascript à la fois coté serveur et coté client est une erreur, car cela apporte de la confusion dans les rôles de chaque scripts. Surtout que, je vous le rappelle, les scripts client sont stockés sur le serveur eux aussi...

Bref, chacun chez soit serais je tenté de dire.

[nouknouk]

Pour l'aspect "de principe", il est facile de vous répondre qu'au contraire, cela apporte une vraie bonne cohérence entre ce qui est exécuté du côté client et ce qui l'est du côté serveur.

Les deux vont être amenés à échanger des données (et donc à la sérialiser/désérialiser), à faire des vérifications et des traitements identiques, etc... Il paraît donc beaucoup, beaucoup plus efficient de n'avoir qu'un lanage unique et surtout un seul et même code commun à maintenir pour la partie 'business' de l'application, code qui sera réutilisé des deux côtés.

[marts]

mais en JavaScript avec le POO "partielle" ça donne ce genre de chose

Effectivement JS n'est pas totalement orientee objet

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.

[MikePombal]

Utiliser Javascript à la fois coté serveur et coté client est une erreur, car cela apporte de la confusion dans les rôles de chaque scripts.

Une erreur??? Bien au contraire avoir un client, un serveur et une base de données (e.g. MongoDB) écrit avec le même langage (Javascript) et parlant la même langue (JSON) ne peut être que bénéfique. Ça signifie n'avoir qu'à maîtriser une seule technologie donc c'est loin d’être un défaut pour moi.

Surtout que, je vous le rappelle, les scripts client sont stockés sur le serveur eux aussi....

De la même manière que l'on télécharge une application bureau de n'importe quel serveur, il est normal que les scripts viennent de quelque parts. Le fait est que le serveur ne fait que les stocker et ne fait rien d'autre à part les fournir aux navigateurs qui les demandent. On pourrai même utiliser un serveur externe pour cette tache (e.g. Amazon).

[magnus2005]

On ne fait pas de la POO "partielle" avec Javascript mais de la POO par prototypage.

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.

Ça signifie n'avoir qu'à maîtriser une seule technologie donc c'est loin d’être un défaut pour moi.

Bien des boites on essayé et finalement en 60 ans l'un des seul grands gagnant a été le COBOL en terme de très large adoption. Dernière tentative en Date Java. Est ce que la Javascript suivra la voix du COBOL ou non. Je pense que nous devrions faire appel au grand Prolix

[jason42]

@p3ga5e

Pour cela je me suis, déjà, amusé a encrypter le code source JavaScript et a l’inclure en ressources embarqués lors de l’édition de lien de l’interpréteur. Donc des solutions existent

Tu m'intéresses, je me suis toujours dit que du moment que ton code est interprété (comme le JS), et qu'il s’exécute dans le navigateur, ce dernier a forcement accès au code source, et si le navigateur y a accès, un petit filou aussi. Mon raisonnement ne tiens pas la route ?
Comment fais tu pour "encrypter" du code cote client ?
(Je n'ai jamais été confronté à ce genre de chose car moi je fais la plupart du temps des webservices (API REST) ou web-socket.)

[p3ga5e]

Tu m'intéresses, je me suis toujours dit que du moment que ton code est interprété (comme le JS), et qu'il s’exécute dans le navigateur, ce dernier a forcement accès au code source, et si le navigateur y a accès, un petit filou aussi. Mon raisonnement ne tiens pas la route ?
Comment fais tu pour "encrypter" du code cote client ?
(Je n'ai jamais été confronté à ce genre de chose car moi je fais la plupart du temps des webservices (API REST) ou web-socket.)

Je parlai, ici, d’écrire une application standalone en JavaScript. Je n’ai jamais mentionné de navigateur ou de développement web.

Désolé de t'avoir créé une fausse joie

[enneite2]

Et dire qu'il y a encore des applications tournant sur IWS / SSJS
IWS : iplanet web server (Netscape)
SSJS : server side javascript (Netscape)
j'aimais bien l'iterfacage avec JAVA avec les objets LiveConnect

[ouldfella]

pour moi il est null ce node.js
y a pas documentation solide
ça fait 3 semaine que j'essaye d'afficher une varible coté brwzer j'ai rien trouvé.
puisque il est coté serveur, peut être je devais payer à tous mes client des billets d'avions et les envoyer chez mon hébergeur pour voir le résultat

[Marco46]

Garde ton argent pour ton neurologue, tu en auras besoin.

[fredoche]

c'est pas pour dire mais le "hello world" c'est juste l'exemple basique donné par toutes les docs au monde.
de là à remplacer un hello world par la variable que tu veux... https://nodejs.org/en/docs/guides/ge...started-guide/

Il y a vraiment des gens payés 3 semaines à chercher des trucs comme ça ?