La place de JavaScript côté serveur [Débat]

[magnus2005]

Envoyé par jason42

pas de compilation en javascript.

Je répondrai par une citation d'un groupe de développeur sans doute underground

V8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs.

Source https://developers.google.com/v8/intro

Envoyé par jason42

Tout ce qui manque a JS en POO il le "rattrape" en fonctionnelle.

Les défaut majeurs du Javascript sont facilement corrigeable (et déjà corrigé par Dart) tout en gardant ses avantages.

[nouknouk]

Envoyé par magnus2005

Je répondrai par une citation d'un groupe de développeur sans doute underground

Tu mélanges compilation 'classique' et compilation en 'just in time', qui représente donc une compilation pendant l'exécution même du programme (et de certaines parties seulement, ou même pas du tout, ceci étant décidé de façon totalement arbitraire par l'interpréteur JS sous-jacent).

Or dans le cadre de ce que tu avançais quand aux bienfaits de la compilation pour la 'robustesse du code' et la détection d'erreurs, c'est totalement inapplicable au cas du 'just in time'.

[magnus2005]

Envoyé par nouknouk

Or dans le cadre de ce que tu avançais quand aux bienfaits de la compilation pour la 'robustesse du code' et la détection d'erreurs, c'est totalement inapplicable au cas du 'just in time'

Il me ne semble pas que ce soit inapplicable au cas du 'just in time'.
Il peut faire un minimum de verif par rapport à la définition du langage comme savoir si un attribut est accessible ou si une variable est définie. Le souci c'est qu'avec JavaScript (1.9) le moteur de compil n'a quasiment rien dans le code pour l'aider (Même problème dans les IDE) ce qui n'est pas le cas pour C# et Java ou Dart.

Several modern runtime environments, such as Microsoft's .NET Framework and most implementations of Java, rely on JIT compilation for high-speed code execution.

Source http://en.wikipedia.org/wiki/Just-in-time_compilation

Envoyé par nouknouk

Tu mélanges compilation 'classique' et compilation en 'just in time'

Je n'en ai pas parlé et sur le fond ça reste de la compilation.
Ici le topic c'est Javascript coté serveur sur une Article sur Node.js qui utilise V8 qui compile le Javascript.

Un compilateur est un programme informatique qui transforme un code source écrit dans un langage de programmation (le langage source) en un autre langage informatique (le langage cible).

quand je parle de compilation c'est cela surtout cela que j'ai l'esprit.

[jason42]

Envoyé par magnus2005

Les défaut majeurs du Javascript sont facilement corrigeable (et déjà corrigé par Dart) tout en gardant ses avantages.

facilement corrigeable, surement. mais tout en etant retro-compatible? c'est moins certain.

Envoyé par magnus2005

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.

oui mais une compilation au runtime ne peux pas gérer de problèmes, vu qu'il n'y a pas d’étape intermédiaire (comme en c++ par exemple, ou le compilateur peut émettre des erreurs et des warnings); la compilation au runtime n'a qu'un rôle d'optimisation.
le JavaScript est quand même un langage de script...
je ne connais pas assez bien Dart, mais si il a tous les avantages de javascript, et qu'il en corrige ses défauts, j'imagine que Node.js pourra etre porté (avec l'aide de google) sur Dart. je m'y mettrais volontiers, mais actuellement Node.js en JavaScript est le top (pour faire des API REST, des serveurs WEBs etc).

[magnus2005]

Envoyé par jason42

facilement corrigeable, surement. mais tout en etant retro-compatible? c'est moins certain.

Pour moi c'est même une certitude que si on vers un Javascript "2" cela passera par des problèmes de rétro comptabilité et que la solution d'un transition en douceur serait d'avoir les 2 moteurs de rendu (1 et 2) et que dans le tag <script> on indique si on souhaite utilise le moteur V2. (un peu comme IE qui plusieur moteur de rendu (comme moteur "quirks" de IE 6 le tout buggé qui est toujours dans IE 10)).

Envoyé par jason42

le JavaScript est quand même un langage de script...

Je suis d'accord qu'il ne faut attendre de miracle mais comparé à d'autre langage de script il reste assez loin (Dart, AS3, PHP). Je prend l'exemple de PHP superbe rétro comptabilité + ajout de plein permanent de nouveau concept pour se rapprocher de Java et C# tout en gardant ses points forts.

Envoyé par jason42

mais actuellement Node.js en JavaScript est le top

C'est sur qu'entre l'API js et la C++ je penche pour la js aussi.

Envoyé par jason42

je ne connais pas assez bien Dart, mais si il a tous les avantages de javascript, et qu'il en corrige ses défauts

2*Oui mais après bien des années de métier et au vue de l'histoire des langage je pense que la lutte sera encore longue. Je prend l'exemple de l'AS3 (2006) qui est très similaire à Dart et qui aussi un EcmaScript comme le JS et il n'a pas remplacé le JavaScript voir il risque de mourir. Dart est quand mieux partie avec plus gros sponsor et est réellement intégré dans un navigateur largement répandu.
[Mode bisounours]
Si les Webkit, Gecko et Trident se mettent d'accord le remplacement du Javascript peut être fait en quelques mois.
[/Mode bisounours]

Wait and see.

[heaven31]

Il ne m'a pas sembler voir beaucoup de réponse prenant en compte le contexte d'utilisation du langage.
Javascript n'est pas un mauvais langage, il a beaucoup de qualité

Ce qui m'embête à l'heure actuelle, c'est le manque d'outils et d'industrialisation du langage. Les outils de tests, de qualification, la qualité de code...l'intégration continue...toutes ces choses sont importantes dans les projets.

De même, autant certains développeurs auront bien appris à manipuler les paradigmes d'un langage par prototype, autant on voit beaucoup (une majorité ?) de développeur, jeune ou moins jeune, qui ne connaissent bien ce type de langage et pour qui l'utilisation de JS est plus casse-gueule car sans barrière...

Tout ces éléments me font penser que, oui, JS est sans doute un langage d'avenir, mais pas dans sa forme et ses outils actuelles et certainement pas dans n'importe quel situation !

N'oublions pas aussi que dans la cadre d'applications web, c'est très jolie de vouloir une application stateless, event-aware, etc...mais in-fine, le besoin d'asynchronisme, de gestion évènementielle n'est pas non plus une généralité sur toutes les couches (IHM, oui, mais sur le serveur ? pour la back ?)

[jason42]

Envoyé par heaven31

Il ne m'a pas sembler voir beaucoup de réponse prenant en compte le contexte d'utilisation du langage.
Javascript n'est pas un mauvais langage, il a beaucoup de qualité
Ce qui m'embête à leur actuel, c'est le manque d'outils et d'industrialisation du langage. Les outils de tests, de qualification, la qualité de code...l'intégration continue...toutes ces choses sont importante dans les gros projets.

totalement d'accord, mais ça c'est comme toujours, plus la communauté sera grande (je parle de la communauté autour du JS coté serveur), plus il y aura d'outils.

Envoyé par heaven31

Tout ces éléments me font penser que, oui, JS est sans doute un langage d'avenir, mais pas dans sa forme et ses outils actuelles et certainement pas dans n'importe quel situation !

encore d'accord, comme tous les langages et toutes les technos.

Envoyé par heaven31

N'oublions pas aussi que dans la cadre d'applications web, c'est très jolie de vouloir une application stateless, event-aware, etc...mais in-fine, le besoin d'asynchronisme, de gestion évènementielle n'est pas non plus une généralité sur toutes les couches (IHM, oui, mais sur le serveur ? pour la back ?)

ben si justement, surtout pour le serveur. avec Apache par exemple on a voulu simplifier la vie du develloppeur en faisant grosso-modo un thread par client qui se connecte, au depit de la performance. dans ce contexte la gestion evenementielle est tres adaptée! d'ailleurs ce ce que propose Node.JS.
Globalement, la gestion évènementielle est adaptée pour tout ce qui est gestion d'effet de bord (écriture dans un fichier, sur le réseau, relation avec une Base de données...).

[ymoreau]

Envoyé par heaven31

De même, autant certains développeurs auront bien appris à manipuler les paradigmes d'un langage par prototype, autant on voit beaucoup (une majorité ?) de développeur, jeune ou moins jeune, qui ne connaissent bien ce type de langage et pour qui l'utilisation de JS est plus casse-gueule car sans barrière...

C'est certain, le paradigme est déroutant car la majorité des développeurs (moi y compris) ont appris l'objet et peuvent transposer leurs acquis à pas mal de langages. On a donc l'habitude de rapidement piger une nouvelle techno.
Cela dit, sur le principe JS est juste autre chose et je trouve totalement injuste de lui reprocher cette différence. Tout comme certains développeurs "crachent" sur l'objet car ils ont toujours fonctionné avec du procédural et n'ont pas pris (pas voulu prendre) cette logique POO. JS est juste une techno différente, et cela s'apprend.
Le reproche qu'on pourrait faire serait plutôt qu'il y a trop de gens qui veulent s'en servir sans apprendre à s'en servir, tout comme le PHP a produit des choses bien sales de par sa popularité chez les néophytes.

Pour en revenir au sujet, je ne saurais pas dire dans l'absolu si le JS est plus adapté que du Java/C# ou bien du Python/Ruby. Comme tout, cela dépend du contexte et du besoin ! Mais en attendant ça fonctionne, et même très bien. Et je ne trouve pas ce langage plus "mal foutu" que peut l'être le PHP à la base (perso je dirais beaucoup moins), ce qui fait la différence c'est les frameworks qui "encadrent" proprement ou non le développement d'un projet.

[leto42]

Envoyé par camus3

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

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

NoSQL and JavaScript: a love story

NoSQL and JavaScript: a love story

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

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]

Envoyé par magnus2005

Je répondrai par une citation d'un groupe de développeur sans doute underground

Citation:

V8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs.

Je preciserai qu'aujourd'hui les moteurs JavaScript de Microsoft (Chackra), Mozilla (spidermonkey), et Apple (JavaScriptCode/SquirrelFish/Nitro) ont tous eux aussi un voire plusieurs excellents "Just-In-Time compiler"

Dans les dernière versions de Firefox, si un code JS est très utilisé, il passe d'un mode compilé rapide (ex JaegerMonkey) a un mode compilé encore plus optimisé (ex IonMonkey)

article interessant:
https://blog.mozilla.org/javascript/...er-has-landed/

Et bien sur, c'est sans compter les optimisations apportées par asm.js:
http://ejohn.org/blog/asmjs-javascript-compile-target/

[leto42]

Envoyé par 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

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

Envoyé par fredoche

(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