Discussion :

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

[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

[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

[p3ga5e]

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)

Sur ce point je suis d’accord avec toi, l’utilisation du terme this est une erreur du langage JavaScript qui porte confusion à la lisibilité du code.

Sinon je rejoins les avis de jason42 et nouknouk sur les qualités de JavaScript

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.

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

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

[Bovino]

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.

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

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.

[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

[magnus2005]

A propos de this

mais il faut surtout comprendre que cette valeur n'a pas le même comportement que dans d'autres langages.

C'est bien ça que je lui reproche.

si tu connais un peu le fonctionnement d'un callback et le mécanisme asynchrone de JavaScript

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. La plupart n'ont même pas idée qu'il manipule des pointeurs. Je ne juge pas le fait qu'il soit nécessaire de comprendre le pointeur ou non pour faire du bon code mais par contre il me semble nécessaire que le langage propose des implémentation cohérente et les plus proches possibles des canons de qualité et des réels enjeux des métiers.

Voir l'explication dans le code ci-dessous pour éclairer mes postes précédents.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Test</title>
<script
	src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
</head>
<body>
	<script type="text/javascript">
	    function MyClass() {};
	    var instanceClass = new MyClass();
 
		MyClass.prototype.log = function(msg) {
			console.log("mon message de debug " + msg);
		}
		// En fait ceci est un méthode statique puisque qu'elle traitera le callback
		// mais comment le savoir ??? ici il n'y a que 20 lignes de code est c'est deja pas tres clair
	    // Ici le compilateur/Interpréteur devrait faire son boulot
	    // et interdire l'usage de this dans un contexte méthode statique
	    // ça fait au moins 20 ans que les moteurs de compile le font
	    //
		MyClass.prototype.donequiplante = function(data) {
			console.log("DATA reçu  :" +data);
			//si appel depuis le callback
			//TypeError: this.log is not a function
			this.log(data);
		};
		//Pour retrouver l'objet appelant j'utilise une globale
		MyClass.prototype.donequifonctionne = function(data) {
			console.log("DATA reçu  :" +data);
			//bouh c'est bien moche mais ça fonctionne
			instanceClass.log(data);
		};
		//Pour faire un exemple de type lieu commun j'utilise Jquery
		MyClass.prototype.call = function() {
			$.ajax({
				url : "data.txt",
				context : document.body
			//}).done(this.donequifonctionne);
			//La contrairement à ce qu'on pourrait croire pour un language moderne
			//ici je passe un pointeur sur une fonction
			// et l'execution sera MyClass.donequiplante(data)
			// et non pas instanceClass.donequiplante(data)
		    }).done(this.donequiplante);
		};
		//la ça fonctionne
		instanceClass.donequiplante("test OK");
		//la ça ne fonctionne pas
		instanceClass.call();
	</script>
</body>
</html>

Pour ce qui est de l'encapsulation

Code :

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

1
2
3
4
5
6
7
8
9
 
//Ceci est du mauvais code
var MonConstructeurA = function(){
    a = 'fooA';
};
//futur infâme bug  de conflit de variable
var MonConstructeurB = function(){
    a = 'fooB';
};

Le souci est que c'est une erreur que je retrouve systématiquement dans l’intégration de code externe (et je ne suis pas le seul) et qu'il suffirait simplement que par défaut les variables Javascript ne soit pas global et utilisé un global si nécessaire. Par conséquent quand un le développeur veut utiliser une globale il en prend sciemment la responsabilité.

Du coup beaucoup de traitement sur la qualité et le traitement des bug qui sont implémentes dans les habituels moteur de compil ne sont pas présent et par conséquent ils doivent être fait manuellement la plupart du temps ce qui est une source de bug.

Autre source de BUG la pseudo encapsulation du js
Impossible de protéger (private) un attribut même avec le mot clef. Source de bug à foison.

[nouknouk]

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.

[magnus2005]

Un marteau n'est pas un mauvais outil en soi bien qu'on puisse s'en servir pour tuer quelqu'un.

Disons que pour planter des clous en plastique c'est mieux avec un marteau en plastique et comme ça tous le monde peut avoir un marteau plastique.

• moins de personne blessé
• élargissement du nombre de bricoleur
• cout de fabrication moindre

Avec le C/C++ on fait des OS , des moteurs 3D ... les possibilité quasi infini offerte peuvent être un gain pour le performance (passage par ref ou par copie, gestion de la parallélisation, Multi Threading, Modèle de compilation spécialiser ,surcharge d’opérateur... ) avec aussi tout un lot d'emmerde qui va avec (Surtout avec le modèle de compilation spécialiser et la surcharge d’opérateur).

avec le Javascript on manipule surtout d'autre API (souvent en C++) on est toujours en bout de chaine. Je trouve cela très regrettable de ne pas inclure le minimum de qualité attendu de la part du compilateur. Il y a qu'a voir Dart ou AS 3 (ou plus éloigné C#, Java, PHP). C'est la seule voie retenue par les leaders de l'industrie est celle la http://fr.wikipedia.org/wiki/Classe_%28informatique%29. Il est tellement plus rationnel de gérer les un maximum de problème via le compilateur plutôt que de le laisser au développeur. C'est le pourtant les développeurs qui devrait être le plus outillé avec des outils informatiques qui les aide à produire.

Tous les "grands" pousse pour ce modèle pour les ECMAScript http://fr.wikipedia.org/wiki/ECMAScript
mais bon ils poussent pas tous exactement vers la même direction.

L'ultra permissivité du Javascript n'est pas une feature mais la conséquence d'un héritage malheureux.
Elle n'apporte rien d'autre que des soucis.
Après ça ne fait que 14 ans que je bosse avec c'est pas peut être pour ça que je vois encore des défauts.

[jason42]

Javascript a ses defauts, comme tous les langages.
tu reproches a javascript son manque d'evolutivité, d'autres y verraient de la stabilité. c'est plus facile de forker le javascript, si on veut le corriger, sinon on risque fort (surtout les exemples que t'avais cité a propos de this) de ne pas être retro-compatible; c'est pourquoi il est preferable de passer par des modules tiers, ou autres. Comme Coffeescript (qui corrige une bonne partie de ce que tu reproches, mais qui introduit une etape de compilation)

Il est tellement plus rationnel de gérer les un maximum de problème via le compilateur plutôt que de le laisser au développeur.

pas de compilation en javascript.

par exemple en C++, depuis combien de temps parle t-on de remplacer include (qui provoque un temps de compilation enorme), ce n'est pas aisé (ni standardisé il me semble) de faire de la reflexivité/introspection en C++.
en Java j'aimerais pouvoir capturer l'environnement lorsque je fait une innerClass (principe des closures en JS).
Tous ces langages n'ont pas les avantages des langages fonctionnelle, comme Ocaml (qui est français cocorico ) etc
Tout ce qui manque a JS en POO il le "rattrape" en fonctionnelle.

[p3ga5e]

Avec le C/C++ on fait des OS , des moteurs 3D ... les possibilité quasi infini offerte peuvent être un gain pour le performance (passage par ref ou par copie, gestion de la parallélisation, Multi Threading, Modèle de compilation spécialiser ,surcharge d’opérateur... ) avec aussi tout un lot d'emmerde qui va avec (Surtout avec le modèle de compilation spécialiser et la surcharge d’opérateur).

Le projet Node.js a été lancé suite au constat suivant : les applications mono-threadés basé sur un system d’event loop sont plus performantes que les applications multi-threadés.
A cela j’ajoute que les applications multi-threadés génèrent nombre de bug de type "deadlocking", la correction de ces bugs accéléraient le transit intestinal du plus constipé des développeurs.
Bref étant un deadlockingphobe , travailler sous Node est quasi thérapeutique , ça m’a même été prescrit par mon médecin traitant

Plus sérieusement, j’ai, avec mes collègues développeurs, récemment convaincu ma direction de migrer du Framework .Net de Microsoft à Node.js.
La démonstration a été faite en réécrivant totalement une application, sous Node en moins de 4 jours, d’un code en C# multi-threadé en cours de débogage depuis plus 2 ans, cette application pilote une connerie de capteur laser qui répond dans le désordre et de manière totalement aléatoire a la série de commande qu’on lui assigne, générant ainsi de nombreux bugs de deadlocking en C#. Certe il y a eu, dans le premier temps de bug sous Node, mais ils ont tous été identifier et corriger en moins de 10 minutes contrairement à l’implémentation C#.

Bien que mon entreprise n’a rien avoir avec les "grands" de ce monde, cette migration concerne des applications critique, du tracking sur signal RADAR, thermique et vidéo , Cela nécessite un autre point que tu as soulevé : le parallelisme
Sur ce point Node.js est un poil en avance sur les navigateurs car il dispose d’une implémentation WebGL (dispo, également sur le navigateurs, sauf IE ) mais également d’une implémentation de WebCL , que j’espère être rapidement implémenter sur les navigateurs

Concernant, la surcharge d’opérateur, tu as pointé du doigt l’énorme lacune du langage JavaScript, avec la surcharge d’opérateur ou du moins l’implémentation arithmétique matricielles cela me permettrais d’utiliser des scripts matlab directement en JavaScript … le pied ^^

Personnellement, j’ai misé gros sur la place du JavaScript coté traitement, si je me trompe je serai rapidement au chômage … mais je suis plutôt confiant …

[nouknouk]

Le projet Node.js a été lancé suite au constat suivant : les applications mono-threadés basé sur un system d’event loop sont plus performantes que les applications multi-threadés.

Attention à ne pas exagérer tout de même: le contexte de nodeJS au départ c'est celui d'un type bien particulier d'applications, celles qui font un usage intensif d'un mode de fonctionnement événementiel où chaque événement demande un traitement court et régulièrement interrompu par des appels (synchrones) pour accéder à des ressources externes.

Et s'ils ont raison dans ce cadre là (typiquement celui d'un serveur web, voir d'un serveur tout court), le monde de l'informatique n'est pas composé QUE de ce type de besoin, loin de là.