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

Ne serait-il pas judicieux 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 de nécessiter l'utilisation d'un langage spécialisé - vraiment, 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 comme JavaScript.

Je comprends la réalité pragmatique que JavaScript est simplement ce avec quoi nous devons travailler maintenant pour des raisons évolutives, mais je pense davantage au long terme. En ce qui concerne la compatibilité descendante, il n'y a aucune raison pour que JavaScript en ligne ne puisse pas être pris en charge simultanément pendant un certain temps et, bien sûr, JavaScript pourrait être l'un des langages pris en charge par la machine virtuelle du navigateur.

Hé bien oui. Certes, si nous avions une machine à remonter le temps, revenir en arrière et s'assurer que beaucoup de fonctionnalités Javascript ont été conçues différemment serait un passe-temps majeur (cela, et s'assurer que les personnes qui ont conçu le moteur CSS d'IE ne se sont jamais lancées dans l'informatique). Mais cela n'arrivera pas, et nous sommes coincés avec cela maintenant.

Je soupçonne qu'avec le temps, il deviendra le "langage machine" pour le Web, avec d'autres langages et API mieux conçus qui s'y compileront (et répondront aux différentes faiblesses du moteur d'exécution).

Je ne pense cependant pas qu'aucun de ces "langages mieux conçus" sera Java, Python ou Ruby. Javascript est, malgré la possibilité d'être utilisé ailleurs, un langage de script d'application Web. Compte tenu de ce cas d'utilisation, nous pouvons faire mieux que n'importe lequel de ces langages.

Je pense que JavaScript est un bon langage, mais j'aimerais avoir le choix lors du développement d'applications Web côté client. Pour des raisons héritées, nous sommes bloqués avec JavaScript, mais il y a des projets et des idées qui cherchent à changer ce scénario:

1. Google Native Client : technologie pour exécuter du code natif dans le navigateur.
2. Emscripten : compilateur de bytecode LLVM en 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 pendant 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 éléments les plus proches d'une machine virtuelle multilingue sont la JVM et le CLR. Ce ne sont pas vraiment des bêtes légères et il ne serait pas logique 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é (chemin, chemin, derrière parce que vous essayez de généraliser sur plusieurs langues)
• Vous êtes en retard sur l'adoption

Donc, non, cela n'a pas de sens.

N'oubliez pas que pour prendre en charge ces langages, vous devrez supprimer quelque chose de féroce leurs API, 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 vraiment qu'avec le DOM de toute façon, donc c'est vraiment un problème de syntaxe et d'idom de langage, à quel point il est logique de demander: "Cela en vaut-il vraiment la peine?"

Gardant à l'esprit, le seule chose dont nous parlons est le script côté client, car le script côté serveur est déjà disponible dans la langue de votre choix. C'est une arène de programmation relativement petite et donc l'avantage d'intégrer plusieurs langues est discutable.

Quelles langues serait-il judicieux de faire intervenir? (Attention, le matériel subjectif suit)

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

Apporter un langage comme Java n'a pas de sens car la meilleure chose à ce sujet est de toute façon les API.

Apporter un langage comme Ruby ou Lisp n'a pas de sens car JavaScript est un langage dynamique puissant très proche de Scheme.

Enfin, quel fabricant 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à parcouru le feu traitant des 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 auprès de l'hôte de script et les mettre à disposition d'IE. Par exemple, VBScript est pris en charge immédiatement (bien qu'il n'ait jamais gagné beaucoup de popularité car il est pour la plupart des cas encore pire que JavaScript).

Les extensions Python win32 permettaient d'ajouter Python à IE comme ça assez facilement, mais ce n'était pas vraiment une bonne idée car Python est assez difficile à sandbox: de nombreuses fonctionnalités du langage exposent suffisamment de hooks d'implémentation pour permettre à une application supposée restreinte de sortir .

Le problème en général est que plus vous ajoutez de complexité à une application faisant face au net comme le navigateur, plus il y a de risques de problèmes de sécurité. Un tas de nouveaux langages correspondrait certainement à cette description, et ce sont de nouveaux langages qui se développent encore rapidement.

JavaScript est un langage laid, mais grâce à l'utilisation prudente d'un sous-ensemble sélectif de fonctionnalités et à la prise en charge de bibliothèques d'objets appropriées, il peut généralement être rendu assez tolérable. Il semble que des ajouts incrémentiels et pratiques à JavaScript soient la seule façon dont les scripts Web sont susceptibles de progresser.

J'accueillerais sans aucun doute une VM indépendante du langage standard dans les navigateurs (je préférerais coder dans un langage typé statiquement).

(Techniquement) C'est assez faisable progressivement: un premier navigateur majeur le prend en charge et le serveur a la possibilité d'envoyer du bytecode si la demande actuelle provient d'un navigateur compatible ou de traduire le code en JavaScript et d'envoyer du JavaScript en texte brut.

Il existe déjà des langages expérimentaux qui se compilent en JavaScript, mais avoir une VM définie permettrait (peut-être) de meilleures performances.

J'avoue que la partie "standard" serait cependant assez délicate. Il y aurait également des conflits entre les fonctionnalités du langage (par exemple, typage statique ou dynamique) concernant la bibliothèque (en supposant que la nouvelle chose utilise la même bibliothèque). Donc je ne pense pas que ça va arriver (bientôt).

Si vous avez l'impression de vous salir les mains, c'est que vous avez subi un lavage de cerveau ou que vous ressentez toujours les effets secondaires des «années DHTML». JavaScript est très puissant et convient bien à son objectif, qui est de scénariser l'interactivité côté client. C'est pourquoi JavaScript 2.0 a une si mauvaise réputation. Je veux dire, pourquoi les packages, les interfaces, les classes et autres, alors que ce sont clairement des aspects des langages côté serveur. JavaScript est très bien en tant que langage basé sur un prototype, sans être orienté objet à part entière.

S'il y a un manque de transparence dans vos applications parce que les côtés serveur et client ne communiquent pas correctement, vous voudrez peut-être reconsidérer la manière dont vous concevez vos applications. J'ai travaillé avec des sites Web et des applications Web extrêmement robustes, et je n'ai jamais dit une seule fois: "Hmm, j'aimerais vraiment que JavaScript puisse faire (xyz)." S'il pouvait le faire, alors ce ne serait pas JavaScript - ce serait ActionScript, AIR ou Silverlight. Je n'en ai pas besoin, et la plupart des développeurs non plus. Ce sont de belles technologies, mais elles essaient de résoudre un problème avec une technologie, pas une ... eh bien, une solution.

Je ne pense pas qu'une VM Web standard soit aussi inconcevable. Il existe un certain nombre de façons d'introduire une nouvelle norme de machine virtuelle Web de manière élégante et avec une prise en charge complète de l'héritage, à condition de vous assurer que tout format de bytecode de machine virtuelle que vous utilisez peut être rapidement décompilé en javascript et que la sortie résultante sera raisonnablement efficace ( J'irais même jusqu'à supposer qu'un décompilateur intelligent générerait probablement un meilleur javascript que n'importe quel javascript qu'un humain pourrait produire lui-même).

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

Les navigateurs qui prennent en charge nativement la nouvelle norme bénéficieraient d'une vitesse d'exécution accrue pour les applications Web VM. En plus de cela, si les navigateurs basent leurs moteurs javascript hérités sur le standard web vm (c'est-à-dire analysant javascript dans le standard web vm puis l'exécutant), ils n'ont pas à gérer deux environnements d'exécution, mais c'est au fournisseur du navigateur. .

Bien que Javascript soit le seul langage de script bien pris en charge à partir duquel vous pouvez contrôler la page directement, Flash a quelques fonctionnalités très intéressantes pour les programmes plus volumineux. Dernièrement, il a un JIT et peut également générer du bytecode à la volée (consultez l' évaluation des expressions d'exécution pour un exemple où ils utilisent flash pour compiler des expressions mathématiques entrées par l'utilisateur jusqu'au binaire natif). Le langage Haxe vous donne un typage statique avec inférence et avec les capacités de génération de bytecode, vous pouvez implémenter presque n'importe quel système d'exécution de votre choix.

Mise à jour rapide sur cette ancienne question.

Tous ceux qui ont affirmé qu'une "page Web contiendrait du code d'octet au lieu d'un langage de niveau supérieur comme JavaScript" "ne se produiront pas".

Juin 2015, le W3C a annoncé WebAssembly qui est

un nouveau format portable, efficace en termes 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 prototypique dans Firefox tous les soirs et Chrome Canary et il y a déjà une démonstration qui fonctionne .

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

à mesure que WebAssembly évoluera, il supportera plus de langages que C / C ++, et nous espérons que d'autres compilateurs le prendront également en charge .

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

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

A) n'arrivera pas et B) est déjà là.

pardon, quoi? laisse-moi expliquer:

annonce A

une VM n'est pas simplement une sorte d'appareil magique universel. la plupart des machines virtuelles sont optimisées pour une certaine langue et certaines fonctionnalités linguistiques. prenez le JRE / Java (ou LLVM): optimisé pour le typage statique, et il y a certainement des problèmes et des inconvénients lors de l'implémentation du typage dynamique ou d'autres choses que java ne supportait pas 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 et dynamique, foo bar boo, ...) serait colossale, difficile à implémenter et probablement plus difficile à optimiser pour obtenir de bonnes performances il. mais je ne suis pas un concepteur de langage ou un gourou de la vm, peut-être que je me trompe: c'est en fait assez facile, personne n'en avait encore l'idée? hrm, hrm.

annonce B

déjà ici: il n'y a peut-être pas de compilateur de bytecode / 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 vers javascript (par exemple coffeescript)
2. créer un interpréteur en javascript qui interprète le langage X (ex: brainfuck ). oui, la performance serait épouvantable, mais bon, on ne peut pas tout avoir.

annonce C

quoi? il n'y avait pas de point C en premier lieu !? car 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, euh, ça ne marchera peut-être jamais, 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 genre vraiment délicat.

mis à part cela:

• javascript est là depuis ~ 1995 = 15 ans. Pourtant, les implémentations de navigateur diffèrent aujourd'hui (même si au moins ce n'est plus insupportable). donc, si vous démarrez encore quelque chose de nouveau, vous pourriez avoir une version fonctionnant dans un navigateur croisé vers 2035. au moins un sous-ensemble fonctionnel. cela ne diffère que subtilement. et a besoin de bibliothèques et de 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 beaucoup d'entreprises préféreraient ne pas servir leur code comme une "sorte de" source ouverte. personnellement, je suis assez heureux 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!

En effet. Silverlight est précisément cela: une VM basée sur .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 «standard». Les trois autres évoluent rapidement mais le taux d'adoption des nouvelles technologies est lent. Qu'en est-il des navigateurs sur téléphones, petits appareils, ...

2. L'intégration de JS dans les différents navigateurs et son histoire passée vous conduit à sous-estimer la puissance de JS. Vous promettez 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 le même que AIR / .NET / ... et autres. JS dans son incarnation actuelle correspond parfaitement à ses objectifs.

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

Comment définissez-vous le mieux? Le meilleur pour le navigateur ou le meilleur pour le développeur? (De plus, ECMAScript est différent de Javascript, mais c'est une technicité.)

Je trouve que JavaScript peut être puissant et élégant à la fois. Malheureusement, la plupart des développeurs que j'ai rencontrés le traitent comme un mal nécessaire au lieu d'un vrai langage de programmation.

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

• traiter les fonctions comme des citoyens de première classe
• pouvoir ajouter et supprimer des fonctions à n'importe quel objet à tout moment (pas très utile mais époustouflant quand c'est le cas)
• c'est un langage dynamique.

C'est amusant à gérer et c'est établi. Profitez-en pendant qu'il est là, car même si ce n'est peut-être pas le «meilleur» pour le script client, c'est certainement agréable.

Je conviens que c'est frustrant lors de la création de pages dynamiques en raison des incompatibilités du navigateur, mais cela peut être atténué par les bibliothèques d'interface utilisateur. Cela ne devrait plus être retenu contre JavaScript lui-même que Swing ne devrait l'être 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 JavaScript. La limitation n'est pas le langage JavaScript, la limitation concerne les objets du navigateur accessibles via JavaScript et le modèle de contrôle d'accès utilisé pour vous assurer que vous pouvez exécuter JavaScript en toute sécurité sans compromettre votre machine. Les contrôles d'accès actuels sont si médiocres que JavaScript n'a qu'un accès très limité aux objets 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?

• Écrivez l'analyseur HTML et le moteur de mise en page (tous les bits compliqués du navigateur, vraiment) dans le même langage de machine virtuelle
• Publier le moteur sur le Web
• Servir la page avec une déclaration du moteur de mise en page à utiliser et son URL

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

J'accueillerais favorablement n'importe quelle langue en plus de javascript comme langage de script possible.

Ce qui serait cool, c'est d'utiliser d'autres langages que Javascript. Java ne conviendrait probablement pas parfaitement à la balise, mais des langages comme Haskell, Clojure, Scala, Ruby, Groovy seraient bénéfiques.

Je suis venu un cross Rubyscript il y a quelque temps ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby et http://code.google.com/p/ruby- in-browser /
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 ce qui précède fonctionne pour fournir une alternative à Javascript, mais cela semble plutôt cool à première vue. Potentiellement, cela permettrait d'utiliser n'importe quel framework Java ou .Net nativement à partir du navigateur - dans le bac à sable du navigateur.

En ce qui concerne la sécurité, si le langage s'exécute à l'intérieur de la JVM (ou du moteur .Net d'ailleurs), la VM se chargera de la sécurité afin que nous n'ayons pas à nous en soucier - du moins pas plus que nous ne devrions pour tout ce qui fonctionne dans le navigateur.

Probablement, mais pour ce faire, nous aurions besoin des principaux navigateurs pour les prendre en charge. Le support IE serait le plus difficile à obtenir. JavaScript est utilisé car c'est la seule chose sur laquelle vous pouvez compter.

La grande majorité des développeurs auxquels 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 DOM HTML qu'il expose. La contradiction entre le DOM et le langage de script est une source courante de douleur et de frustration concernant ECMAScript. N'oubliez pas non plus qu'IIS peut utiliser JScript pour les scripts côté serveur, et des éléments 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 pourriez être agréablement surpris par une partie du soulagement que vous obtenez.

Un site ancien, mais toujours un bon point de départ: le site de Douglas Crockford .

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

A côté, je ne vois pas ce que vous trouvez "sale" dans JS. Il peut être moche s'il est codé par des amateurs, propageant de 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 obscurci, mais peut être rendu parfaitement lisible.

Vérifiez ceci sur 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 seulement le problème dans JS, car c'est le manque de bons IDE gratuits pour développer des programmes plus volumineux dans JS. Je n'en connais qu'un seul 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, aux programmeurs, de bons outils de développement. Vous ne pouvez pas créer 50000 lignes de JavaScript en utilisant un simple éditeur de texte, JSLint et un débogueur Google Chrome intégré. Sauf si vous êtes un macohiste.

Lorsque Borland a réalisé un IDE pour Turbo Pascal 4.0 en 1987, c'était une révolution dans la programmation. 24 ans se sont écoulés depuis. Honteusement, en 2011, de nombreux programmeurs n'utilisent toujours pas la complétion de 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 (GRATUITS) appropriés pour les programmeurs s'ils veulent que nous construisions des applications avec lesquelles ils peuvent lutter contre Windows, Linux, MacOS, iOS, Symbian, etc.

De manière réaliste, Javascript est le seul langage que tous les navigateurs utiliseront pendant longtemps, donc même s'il serait très agréable d'utiliser d'autres langues, je ne peux pas le voir se produire.

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 de toute façon à utiliser Javascript car il est plus adapté aux sites Web que de nombreux autres navigateurs.

Vous auriez à sandbox chaque langage de programmation dans cette machine virtuelle et à réduire la quantité d'accès de chaque langue au système, nécessitant de nombreux changements dans les langues et la suppression ou la réimplémentation de nombreuses fonctionnalités. Alors que Javascript a déjà cela à l'esprit, et en a fait depuis longtemps.

Vous recherchez peut-être le client natif de Google.

Dans 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 simple . Nous pouvons dire que nous sommes coincés avec JS, mais est-ce vraiment si mauvais avec jQuery, Prototype, scriptaculous, MooTools et toutes les bibliothèques fantastiques?

N'oubliez pas que JS est léger , encore plus avec V8, TraceMonkey, SquirrelFish - de nouveaux moteurs Javascript utilisés dans les navigateurs modernes.

Il est également prouvé - oui, nous savons qu'il y a des problèmes, mais nous en avons beaucoup résolus, comme les premiers problèmes de sécurité. Imagerie permettant à votre navigateur d'exécuter du code Ruby, ou toute autre chose. Le bac à sable de sécurité devrait être fait pour zéro. Et tu sais quoi? Les gens de Python ont déjà échoué deux fois.

Je pense que Javascript va être révisé et amélioré au fil du 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 «comprenez le problème pragmatique que JavaScript est simplement ce avec quoi nous devons travailler maintenant». En fait, c'est un langage très puissant. Vous aviez votre applet Java dans le navigateur pendant des années, et où est-il maintenant?

Quoi qu'il en soit, vous n'avez pas besoin de «vous salir» pour travailler sur le client. Par exemple, essayez GWT.

... vous voulez dire...

Applet Java et Java Flash et Adobe AIR etc.

En général, tout cadre RIA peut répondre à vos besoins; mais pour chacun, il y a un prix à payer pour l'utiliser (par exemple, runtime disponible sur le navigateur ou / et propriétaire ou / et moins d'options que le bureau pur) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Pour développer du Web avec n'importe quel langage non Web, vous avez GWT: développez Java, compilez en Javascript

Parce qu'ils ont tous déjà des machines virtuelles avec des interpréteurs 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) se compile en code machine IA32.

Eh bien, étant donné que tous les navigateurs utilisent déjà une VM, je ne pense pas qu'il sera si difficile de créer un langage de VM pour le Web.
Je pense que cela aiderait grandement pour plusieurs raisons:
1. puisque le serveur compile le code, la quantité de données envoyées est plus petite et le client ne perd pas de temps à compiler le code.
2. puisque le serveur peut compiler le code en préparation et le stocker, contrairement au client qui essaie de perdre aussi peu de temps à compiler rapidement le JS, il peut faire de meilleures optimisations de code.
3. compiler un langage en byte code est bien plus facile que le transpiler en JS.

en guise de note finale (comme quelqu'un l'a déjà dit dans un autre commentaire), HTML et CSS se compilent dans un langage plus simple, je ne sais pas si cela compte comme du code d'octet, mais vous pouvez également envoyer du code html et css compilé du serveur au client, ce qui réduire les temps d'analyse et de récupération

IMO, JavaScript, le langage, n'est pas le problème. JavaScript est en fait un langage assez expressif et puissant. Je pense que cela a une mauvaise réputation car il n'a pas de fonctionnalités OO classiques, mais pour moi, plus je suis avec le groove prototypique, plus je l'aime.

Le problème tel que je le vois, ce sont les implémentations irrégulières et incohérentes sur les nombreux navigateurs que nous sommes obligés de prendre en charge sur le Web. Les bibliothèques JavaScript telles que jQuery contribuent grandement à atténuer ce sentiment sale.