Pourquoi JavaScript plutôt qu’une machine virtuelle de navigateur standard?

Ne serait-il pas logique de prendre en charge un ensemble de langages (Java, Python, Ruby, etc.) au moyen d’une machine virtuelle standardisée hébergée dans le navigateur plutôt que d’utiliser un langage spécialisé – en réalité, un paradigme spécialisé – pour le script client uniquement?

Pour clarifier la suggestion, une page Web contiendrait du code d’octet au lieu de tout langage de niveau supérieur tel que JavaScript.

Je comprends la réalité pragmatique selon laquelle JavaScript est simplement ce que nous devons travailler maintenant pour des raisons d’évolution, mais je pense davantage au long terme. En ce qui concerne la rétrocompatibilité, il n’ya aucune raison de ne pas pouvoir prendre en charge simultanément JavaScript en ligne et, bien sûr, JavaScript peut être l’une des langues sockets en charge par la machine virtuelle de navigateur.

Hé bien oui. Certes, si nous avions une machine à remonter le temps, revenir en arrière et faire en sorte que de nombreuses fonctionnalités Javascript soient conçues différemment constituerait un passe-temps majeur (et garantirait que les personnes qui ont conçu le moteur CSS d’IE ne sont jamais entrées dans l’informatique). Mais ça n’arrivera pas, et nous sums coincés avec ça maintenant.

Je suppose que, avec le temps, il deviendra le “langage machine” pour le web, avec d’autres langages et API mieux conçus (et répondant aux différentes faiblesses des moteurs d’exécution).

Je ne pense pas, cependant, que l’un de ces “langages mieux conçus” sera Java, Python ou Ruby. Javascript est, malgré la capacité d’être utilisé ailleurs, un langage de script d’application Web. Étant donné ce cas d’utilisation, nous pouvons faire mieux que n’importe laquelle de ces langues.

Je pense que JavaScript est un bon langage, mais j’aimerais bien avoir le choix lors du développement d’applications Web côté client. Pour des raisons d’inheritance, nous sums bloqués avec JavaScript, mais certains projets et idées cherchent à modifier ce scénario:

  1. Google Native Client : technologie permettant d’exécuter du code natif dans le navigateur.
  2. Emscripten : compilateur bytecode LLVM pour javascript. Permet aux langues LLVM de s’exécuter dans le navigateur.
  3. Idée: .NET CLI dans le navigateur, par le créateur de Mono: http://tirania.org/blog/archive/2010/May-03.html

Je pense que nous aurons JavaScript depuis longtemps, mais cela changera tôt ou tard. Il y a tellement de développeurs prêts à utiliser d’autres langues dans le navigateur.

Répondre à la question – Non, cela n’aurait aucun sens.

Actuellement, les objects les plus proches d’une machine virtuelle multilingue sont la JVM et le CLR. Ce ne sont pas exactement des bêtes légères, et cela n’aurait aucun sens d’essayer d’intégrer quelque chose de cette taille et de cette complexité dans un navigateur.

Examinons l’idée que vous pourriez écrire une nouvelle machine virtuelle multilingue qui serait meilleure que la solution existante.

  • Vous êtes en retard sur la stabilité.
  • Vous êtes en retard sur la complexité (bien sûr, vous essayez de généraliser sur plusieurs langues)
  • Vous êtes en retard sur l’adoption

Donc, non, ça n’a pas de sens.

Rappelez-vous que pour prendre en charge ces langages, vous devez supprimer leurs API de manière féroce, en supprimant toutes les parties qui n’ont pas de sens dans le contexte d’un script de navigateur. Il y a un grand nombre de décisions de conception à prendre ici, et une énorme possibilité d’erreur.

En termes de fonctionnalité, nous ne travaillons probablement que sur le DOM, donc c’est vraiment une question de syntaxe et de langage, à quel point il est logique de demander: “Est-ce que ça vaut vraiment le coup?”

En gardant à l’esprit, la seule chose dont nous parlons est le script côté client, car les scripts côté serveur sont déjà disponibles dans la langue de votre choix. Il s’agit d’un domaine de programmation relativement restreint et l’avantage d’apporter plusieurs langues est donc discutable.

Quelles langues serait-il judicieux d’intégrer? (Attention, le matériel subjectif suit)

Introduire un langage comme C n’a aucun sens car il est fait pour travailler avec du métal, et dans un navigateur, il n’y a pas beaucoup de métal réellement disponible.

Faire appel à un langage comme Java n’a pas de sens, car les API sont tout de même la meilleure solution.

Faire appel à un langage comme Ruby ou Lisp n’a aucun sens, car JavaScript est un langage dynamic très proche de Scheme.

Enfin, quel créateur de navigateur souhaite vraiment prendre en charge l’intégration DOM pour plusieurs langues? Chaque implémentation aura ses propres bogues spécifiques. Nous avons déjà passé en revue les différences entre MS Javascript et Mozilla Javascript, et nous voulons maintenant multiplier cette douleur par cinq ou six?

Cela n’a pas de sens.

Sous Windows, vous pouvez enregistrer d’autres langues sur l’hôte de script et les mettre à la disposition d’IE. Par exemple, VBScript est supporté par défaut (bien qu’il n’ait jamais été très populaire car il est encore pire que JavaScript pour la plupart des applications).

Les extensions Python win32 permettaient d’append Python à IE assez facilement, mais ce n’était pas vraiment une bonne idée car Python est assez difficile à classer: de nombreuses fonctionnalités de langage exposent suffisamment de crochets d’implémentation pour permettre à une application supposée restreinte de sortir. .

En règle générale, plus vous ajoutez de complexité à une application orientée réseau telle que le navigateur, plus la probabilité de problèmes de sécurité est grande. Un certain nombre de nouveaux langages correspondraient certainement à cette description, et ces nouveaux langages se développent encore rapidement.

JavaScript est un langage laid, mais grâce à l’utilisation judicieuse d’un sous-ensemble sélectif de fonctionnalités et à la prise en charge de bibliothèques d’objects appropriées, il est généralement possible de le rendre assez tolérable. Cela semble incrémentiel, les ajouts pratiques à JavaScript sont la seule façon dont les scripts Web vont évoluer.

J’accueillerais certainement une VM indépendante de la langue standard dans les navigateurs (je préférerais coder dans un langage typé statiquement).

(Techniquement) C’est tout à fait faisable progressivement: le premier navigateur principal le supporte et le serveur a la possibilité soit d’envoyer du bytecode si la requête actuelle provient d’un navigateur compatible, soit de traduire le code en JavaScript et d’envoyer du JavaScript en texte brut.

Il existe déjà des langages expérimentaux qui comstacknt en JavaScript, mais avoir une machine virtuelle définie permettrait (peut-être) d’améliorer les performances.

J’avoue que la partie “standard” serait assez délicate, cependant. Il y aurait aussi des conflits entre les caractéristiques de la langue (par exemple, typage statique ou dynamic) concernant la bibliothèque (en supposant que la nouvelle chose utiliserait la même bibliothèque). Je ne pense donc pas que ça va arriver (bientôt).

Si vous avez l’impression de vous salir les mains, vous avez soit subi un lavage de cerveau, soit vous ressentez toujours les séquelles des “années DHTML”. JavaScript est très puissant et convient parfaitement à son objective, qui est de créer un script côté client interactif. C’est pourquoi JavaScript 2.0 a eu un si mauvais rap. Je veux dire, pourquoi les paquets, les interfaces, les classes, etc., quand ce sont clairement des aspects des langages côté serveur. JavaScript est parfait en tant que langage basé sur un prototype, sans être orienté object.

Si vos applications manquent de transparence, car le côté serveur et le côté client ne communiquent pas bien, vous voudrez peut-être reconsidérer la façon dont vous architecturez vos applications. J’ai travaillé avec des sites Web et des applications Web extrêmement robustes, et je n’ai jamais dit une fois: «Hmm, j’aimerais vraiment que JavaScript fonctionne (xyz)». Si cela était possible, alors ce ne serait pas JavaScript – ce serait ActionScript ou AIR ou Silverlight. Je n’ai pas besoin de ça et la plupart des développeurs ne le font pas non plus. Ce sont de belles technologies, mais elles essaient de résoudre un problème avec une technologie, pas une … une solution.

Bien que Javascript soit le seul langage de script bien pris en charge sur lequel vous pouvez contrôler directement la page, Flash offre de très bonnes fonctionnalités pour les programmes plus volumineux. Dernièrement, il possède un JIT et peut également générer du bytecode à la volée (consultez l’ évaluation des expressions d’exécution pour un exemple d’utilisation de Flash pour comstackr des expressions mathématiques entrées par l’utilisateur jusqu’au binary natif). Le langage Haxe vous offre un typage statique avec inférence et avec les capacités de génération de bytecode, vous pouvez implémenter presque tous les systèmes d’exécution de votre choix.

Je ne pense pas qu’une VM Web standard soit aussi inconcevable. Il y a plusieurs façons d’introduire un nouveau standard de machine virtuelle Web avec une prise en charge héritée complète, à condition de vous assurer que tout format de bytecode de machine virtuelle utilisé peut être rapidement décomposé en javascript et que la sortie obtenue est raisonnablement efficace ( J’irais même jusqu’à deviner qu’un décompilateur intelligent générerait probablement un meilleur javascript que tout javascript qu’un être humain pourrait produire lui-même.

Avec cette propriété, tout format de machine virtuelle Web peut être facilement décompilé sur le serveur (rapide), sur le client (lent mais possible dans les cas où le contrôle du serveur est limité) ou peut être pré-généré et chargé dynamicment par soit le client, soit le serveur (le plus rapide) pour les navigateurs qui ne supportent pas nativement le nouveau standard.

Les navigateurs qui supportent nativement la nouvelle norme bénéficieraient d’une vitesse d’exécution accrue pour les applications basées sur le Web vm. En plus de cela, si les navigateurs basent leurs moteurs javascript hérités sur le standard web vm (par exemple, parsingr le javascript dans le standard web vm puis l’exécuter), ils n’ont pas à gérer deux runtimes, mais cela dépend du navigateur. .

Mise à jour rapide sur cette ancienne question.

Toute personne ayant affirmé qu’une “page Web contiendrait du code octet au lieu de tout langage de niveau supérieur tel que JavaScript” “ne se produira pas”.

Juin 2015, le W3C a annoncé WebAssembly qui est

un nouveau format portable, de taille et de temps de chargement adapté à la compilation sur le Web.

Ceci est encore expérimental, mais il existe déjà une implémentation prototype dans Firefox nightly et Chrome Canary et il y a déjà des démonstrations qui fonctionnent .

Actuellement, WebAssembly est principalement conçu pour être produit à partir de C / C ++.

WebAssembly évoluant, il supportera plus de langages que C / C ++, et nous espérons que d’autres compilateurs le supporteront également .

Je vous laisse regarder de plus près la page officielle du projet, c’est vraiment excitant!

cette question refait surface régulièrement. ma position à ce sujet est la suivante:

A) ne se produira pas et B) est déjà là.

pardon, quoi? laisse-moi expliquer:

ad A

une VM n’est pas une sorte de périphérique magique universel. la plupart des machines virtuelles sont optimisées pour un certain langage et certaines fonctionnalités linguistiques. Prenez JRE / Java (ou LLVM): optimisé pour le typage statique, et il y a certainement des problèmes et des inconvénients lors de la mise en œuvre du typage dynamic ou d’autres choses que java n’a pas supscopes en premier lieu.

Ainsi, la “VM polyvalente générale” qui prend en charge de nombreuses fonctionnalités de langage (optimisation des appels de queue, typage statique & dynamic, foo bar boo, …) serait colossale, difficile à implémenter et probablement plus difficile à optimiser. il. mais je ne suis pas un créateur de langage ou un gourou de la VM, peut-être que je me trompe: c’est en fait assez facile, mais personne n’a encore eu l’idée? hrm, hrm.

ad B

déjà ici: il n’y a peut-être pas de compilateur de code octet / vm, mais vous n’en avez pas réellement besoin. afaik javascript est terminé, il devrait donc être possible de:

  1. créer un traducteur de la langue X au javascript (par exemple, coffeescript)
  2. créer un interpréteur en javascript qui interprète le langage X (ex. brainfuck ). oui, la performance serait catastrophique, mais bon, vous ne pouvez pas tout avoir.

ad C

quelle? il n’y avait pas un point C en premier lieu? parce qu’il n’y en a pas encore. google NACL. si quelqu’un peut le faire, c’est google. dès que google le fait fonctionner, vos problèmes sont résolus. seulement, ça peut ne jamais marcher, je ne sais pas. La dernière fois que j’ai lu à ce sujet, il y avait des problèmes de sécurité non résolus du type très délicat.


mis à part cela:

  • javascript existe depuis ~ 1995 = 15 ans. Cependant, les implémentations de navigateurs diffèrent aujourd’hui (bien qu’au moins ce ne soit plus insupportable). donc, si vous démarrez quelque chose de nouveau, vous pourriez avoir une version fonctionnant sur plusieurs navigateurs vers 2035. au moins un sous-ensemble fonctionnel. cela ne diffère que subtilement. et nécessite des bibliothèques et des couches de compatibilité. inutile de ne pas essayer d’améliorer les choses.

  • aussi, qu’en est-il du code source lisible? Je sais que de nombreuses entresockets préféreraient ne pas utiliser leur code en tant que source ouverte “du genre”. Personnellement, je suis plutôt content de pouvoir lire la source si je soupçonne quelque chose de louche ou si je veux en tirer des leçons. Hourra pour le code source!

Effectivement. Silverlight est justement cela – une machine virtuelle .Net côté client.

Il y a des erreurs dans votre raisonnement.

  1. Une machine virtuelle standard dans un navigateur standard ne sera jamais standard. Nous avons 4 navigateurs et IE a des intérêts contradictoires en ce qui concerne la norme. Les trois autres évoluent rapidement mais le taux d’adoption des nouvelles technologies est lent. Qu’en est-il des navigateurs sur les téléphones, les petits appareils, …

  2. L’intégration de JS dans les différents navigateurs et son passé vous amène à sous-estimer la puissance de JS. Vous engagez une norme, mais désapprouvez JS parce que la norme n’a pas fonctionné dans les premières années.

  3. Comme d’autres l’ont dit, JS n’est pas la même chose qu’AIR / .NET / … et autres. JS dans son incarnation actuelle correspond parfaitement à ses objectives.

À long terme, Perl et Ruby pourraient bien remplacer le javascript. Pourtant, l’adoption de ces langages est lente et on sait qu’ils ne prendront jamais le contrôle de JS.

Comment définissez-vous le mieux? Idéal pour le navigateur ou le meilleur pour le développeur? (Plus ECMAScript est différent de Javascript, mais c’est une technicité.)

Je trouve que JavaScript peut être puissant et élégant en même temps. Malheureusement, la plupart des développeurs que j’ai rencontrés le considèrent comme un mal nécessaire au lieu d’un véritable langage de programmation.

Certaines des fonctionnalités que j’apprécie sont:

  • traiter les fonctions comme des citoyens de première classe
  • être capable d’append et de supprimer des fonctions à n’importe quel object à n’importe quel moment
  • c’est un langage dynamic.

C’est amusant à gérer et c’est établi. Profitez-en pendant qu’il est là car bien que ce ne soit pas le “meilleur” pour le script client, il est certainement agréable.

Je suis d’accord pour dire qu’il est frustrant de créer des pages dynamics en raison d’incompatibilités de navigateur, mais cela peut être atténué par les bibliothèques de l’interface utilisateur. Cela ne devrait pas être tenu contre JavaScript lui-même plus que Swing devrait être détenu contre Java.

JavaScript est la machine virtuelle standard du navigateur. Par exemple, OCaml et Haskell ont maintenant tous deux des compilateurs capables de générer du code JavaScript. La limitation n’est pas le langage JavaScript, la limitation concerne les objects de navigateur accessibles via JavaScript et le modèle de contrôle d’access utilisé pour garantir que vous pouvez exécuter JavaScript en toute sécurité sans compromettre votre ordinateur. Les contrôles d’access actuels sont tellement médiocres que JavaScript ne permet qu’un access très limité aux objects du navigateur pour des raisons de sécurité. Le projet Harmony cherche à résoudre ce problème.

C’est une bonne idée. Pourquoi ne pas aller plus loin?

  • Ecrire l’parsingur HTML et le moteur de présentation (tous les bits compliqués du navigateur, vraiment) dans le même langage VM
  • Publier le moteur sur le web
  • Servir la page avec une déclaration de quel moteur de mise en page utiliser et son URL

Ensuite, nous pouvons append des fonctionnalités aux navigateurs sans avoir à pousser de nouveaux navigateurs vers chaque client – les nouveaux bits pertinents seraient chargés dynamicment à partir du Web. Nous pourrions également publier de nouvelles versions de HTML sans la complexité ridicule de maintenir la rétrocompatibilité avec tout ce qui a déjà fonctionné dans un navigateur – la compatibilité est la responsabilité de l’auteur de la page. Nous pouvons également expérimenter des langages de balisage autres que HTML. Et, bien sûr, nous pouvons écrire des compilateurs JIT sophistiqués dans les moteurs, de sorte que vous puissiez écrire vos pages Web dans la langue de votre choix.

J’accueillerais toute langue en dehors du javascript comme langage de script possible.

Ce qui serait cool, c’est d’utiliser d’autres langages que Javascript. Java ne serait probablement pas un bon ajustement entre le tag mais les langages comme Haskell, Clojure, Scala, Ruby, Groovy seraient bénéfiques.

Il y a quelque temps, je suis venu avec un Rubyscript croisé … http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby et http://code.google.com/p/ruby- dans le navigateur/
Toujours expérimental et en cours, mais semble prometteur.
Pour .Net, je viens de trouver: http://www.silverlight.net/learn/dynamic-languages/ Je viens de trouver le site, mais ça a l’air intéressant aussi. Fonctionne même depuis mon Apple Mac .

Je ne sais pas à quel point le travail ci-dessus permet de fournir une alternative à Javascript, mais à première vue, il est plutôt cool. Potentiellement, cela permettrait d’utiliser n’importe quel framework Java ou .Net de manière native depuis le navigateur – dans le sandbox du navigateur.

En ce qui concerne la sécurité, si la langue s’exécute à l’intérieur de la JVM (ou du moteur .Net), la VM se chargera de la sécurité afin que nous n’ayons pas à nous en préoccuper. à l’intérieur du navigateur.

Probablement, mais pour ce faire, il faudrait que les principaux navigateurs les prennent en charge. Le support IE serait le plus difficile à obtenir. JavaScript est utilisé car c’est la seule chose sur laquelle vous pouvez compter pour être disponible.

La grande majorité des développeurs à qui j’ai parlé d’ECMAScript et. Al. finissent par admettre que le problème n’est pas le langage de script, c’est le ridicule HTML DOM qu’il expose. Le conflit entre le DOM et le langage de script est une source commune de douleur et de frustration concernant ECMAScript. De plus, n’oubliez pas qu’IIS peut utiliser JScript pour les scripts côté serveur, et des choses comme Rhino vous permettent de créer des applications autonomes dans ECMAScript. Essayez de travailler dans l’un de ces environnements avec ECMAScript pendant un certain temps et voyez si votre opinion change.

Ce genre de désespoir existe depuis un certain temps. Je vous suggère de modifier ceci pour inclure ou republier des problèmes spécifiques. Vous pouvez être agréablement surpris par le soulagement que vous ressentez.

Un ancien site, mais toujours un bon endroit pour commencer: le site de Douglas Crockford .

Eh bien, nous avons déjà VBScript, n’est-ce pas? Attendez, seul IE le supporte!
Même chose pour votre belle idée de VM. Que se passe-t-il si je script ma page en utilisant Lua, et que votre navigateur n’a pas l’parsingur pour le convertir en bytecode? Bien sûr, nous pourrions imaginer une balise de script acceptant un fichier de bytecode, qui serait même très efficace.
Mais l’expérience montre qu’il est difficile d’introduire quelque chose de nouveau sur le Web: il faudrait des années pour adopter un nouveau changement radical comme celui-ci. Combien de navigateurs prennent en charge SVG ou CSS3?

À côté, je ne vois pas ce que vous trouvez “sale” dans JS. Elle peut être moche si elle est codée par des amateurs, propageant les mauvaises pratiques copiées ailleurs, mais les maîtres ont montré que cela pouvait aussi être un langage élégant. Un peu comme Perl: ressemble souvent à un langage obscur, mais peut être rendu parfaitement lisible.

Vérifiez ceci http://www.visitmix.com/Labs/Gestalt/ – vous permet d’utiliser python ou ruby, tant que l’utilisateur a installé Silverlight.

C’est une très bonne question.

Ce n’est pas le problème que dans JS, car il n’y a pas de bons IDE gratuits pour développer de plus grands programmes dans JS. Je n’en connais qu’un qui soit gratuit: Eclipse. L’autre bon est Visual Studio de Microsoft, mais pas gratuit.

Pourquoi serait-ce gratuit? Si les fournisseurs de navigateurs Web veulent remplacer les applications de bureau par des applications en ligne (et ils le souhaitent), ils doivent nous donner, à nous les programmeurs, de bons outils de développement. Vous ne pouvez pas créer 50 000 lignes de JavaScript à l’aide d’un simple éditeur de texte, de JSLint et d’un débogueur Google Chrome intégré. À moins d’être un macohiste.

Lorsque Borland a réalisé un IDE pour Turbo Pascal 4.0 en 1987, ce fut une révolution dans la programmation. 24 ans ont passé depuis. Honteusement, en 2011, de nombreux programmeurs n’utilisent toujours pas le code, la vérification de la syntaxe et les débogueurs appropriés. Probablement parce qu’il y a si peu de bons IDE.

Il est dans l’intérêt des fournisseurs de navigateurs Web de créer des outils appropriés (GRATUITS) pour les programmeurs s’ils veulent que nous construisions des applications avec lesquelles ils peuvent combattre Windows, Linux, MacOS, iOS, Symbian, etc.

De manière réaliste, le javascript est le seul langage que les navigateurs utiliseront pendant une longue période, alors même s’il serait très intéressant d’utiliser d’autres langues, je ne le vois pas.

Cette “VM standardisée” dont vous parlez serait très volumineuse et devrait être adoptée par tous les principaux navigateurs, et la plupart des sites continueraient simplement à utiliser Javascript car il est plus adapté aux sites Web que de nombreux autres navigateurs.

Vous devrez mettre en sandbox chaque langage de programmation de cette machine virtuelle et réduire la quantité d’access de chaque langue au système, ce qui nécessitera beaucoup de changements dans les langues et la suppression ou la réimplémentation de nombreuses fonctionnalités. Alors que Javascript a déjà ceci en tête, et le fait depuis longtemps.

Peut-être cherchez-vous le client natif de Google?

En un sens, avoir un langage plus expressif comme Javascript dans le navigateur au lieu de quelque chose de plus général comme le bytecode Java a signifié un Web plus ouvert.

Je pense que ce n’est pas si facile . On peut dire que nous sums coincés avec JS, mais est-ce vraiment si mal avec jQuery, Prototype, scriptaculous, MooTools, et toutes les bibliothèques fantastiques?

Rappelez-vous que JS est léger , encore plus avec V8, TraceMonkey, SquirrelFish – les nouveaux moteurs Javascript utilisés dans les navigateurs modernes.

Il est également prouvé – oui, nous soaps que cela a des problèmes, mais nous avons beaucoup de problèmes à résoudre, comme les premiers problèmes de sécurité. Imagerie permettant à votre navigateur d’exécuter du code Ruby ou autre. Le bac à sable de sécurité devrait être fait pour rien. Et tu sais quoi? Les python ont déjà échoué à deux resockets.

Je pense que le Javascript va être revu et amélioré avec le temps, tout comme HTML et CSS. Le processus peut être long, mais tout n’est pas possible dans ce monde.

Je ne pense pas que vous “compreniez le problème pragmatique avec lequel JavaScript est simplement ce que nous devons travailler maintenant”. En fait, c’est un langage très puissant. Vous avez votre applet Java dans le navigateur depuis des années et où est-il maintenant?

Quoi qu’il en soit, vous n’avez pas besoin de “vous salir” pour travailler sur un client. Par exemple, essayez GWT.

… vous voulez dire…

Java et Java applet Flash et Adobe AIR etc.

En général, tout framework RIA peut répondre à vos besoins; mais pour tout le monde, il y a un prix à payer pour l’utiliser (ej. runtime disponible sur navigateur et / ou propre et / ou moins d’options que le pure desktop) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Pour développer Web avec n’importe quelle langue non-web, vous avez GWT: développer Java, comstackr en Javascript

Parce qu’ils ont tous des VM avec des interprètes de bytecode, et que le bytecode est également différent. {Chakra (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Carakan).

Désolé, je pense que Chrome (V8) comstack jusqu’à IA32 code machine.

IMO, JavaScript, le langage n’est pas le problème. JavaScript est en fait un langage très expressif et puissant. Je pense que ça donne un mauvais rep, car il n’a pas de fonctions classiques d’OO, mais pour moi, plus je préfère le groove prototype, plus je l’aime.

Le problème, à mon avis, est la mise en œuvre incohérente et incohérente des nombreux navigateurs que nous sums obligés de prendre en charge sur le Web. Les bibliothèques JavaScript comme jQuery consortingbuent grandement à atténuer ce sentiment de sale.

JavaScript est votre seule option standard native disponible. Si vous voulez beaucoup de puissance, prenez jQuery, mais si vous avez besoin d’en faire plus, envisagez d’écrire un addon pour Firefox? ou similaire pour IE etc.