Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Je répondrai par une citation d'un groupe de développeur sans doute undergroundEnvoyé par jason42
Source https://developers.google.com/v8/introV8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs.
Les défaut majeurs du Javascript sont facilement corrigeable (et déjà corrigé par Dart) tout en gardant ses avantages.
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).
Je répondrai par une citation d'un groupe de développeur sans doute underground
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.
Source http://en.wikipedia.org/wiki/Just-in-time_compilationSeveral modern runtime environments, such as Microsoft's .NET Framework and most implementations of Java, rely on JIT compilation for high-speed code execution.
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.
quand je parle de compilation c'est cela surtout cela que j'ai l'esprit.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).
facilement corrigeable, surement. mais tout en etant retro-compatible? c'est moins certain.
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).
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)).
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.
C'est sur qu'entre l'API js et la C++ je penche pour la js aussi.
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.
N'oublions pas le contexte
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 ?)
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.
encore d'accord, comme tous les langages et toutes les technos.
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...).
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.
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
"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 ?)
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"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.
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/
C'est a priori un bug du plugin slideshare du forum, les slides sont visibles en cliquant sur le titre
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
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
Garde ton argent pour ton neurologue, tu en auras besoin.
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 ?
Répondre avec citation
Partager