Pourquoi nécessitent JavaScript plutôt que de soutenir une machine virtuelle de navigateur standard ?

Question

Ne serait-il pas logique de soutenir un ensemble de langages (Java, Python, Ruby, etc.) par normalisée de la machine virtuelle hébergée dans le navigateur plutôt que d'exiger l'utilisation d'un langage spécialisé -- vraiment, spécialisé paradigme -- pour le client de script?

Afin de clarifier la suggestion, une page web serait de contenir de code octet au lieu de tout langage de niveau plus élevé comme le JavaScript.

Je comprends la réalité pragmatique que JavaScript est simplement ce que nous avons à travailler avec maintenant, grâce à l'évolution des raisons, mais je pense plus sur le long terme. Quant aux raisons de compatibilité ascendante, il n'y a pas de raison pour que le JavaScript en ligne ne pouvait pas être simultanément pris en charge pour une période de temps et, bien sûr JavaScript pourrait être l'une des langues prises en charge par le navigateur de la machine virtuelle.

Answer 1

Eh bien, oui. Certes, si nous avions une machine de temps, de revenir et de s'assurer beaucoup de fonctions Javascript ont été conçus différemment serait un passe-temps majeur (qui, et de garantir les gens qui ont conçu IE CSS du moteur n'est jamais allé en ELLE). Mais il ne va pas arriver, et nous sommes coincés avec elle maintenant.

Je soupçonne que, dans le temps, il deviendra le "langage Machine" pour le web, avec d'autres mieux conçu langues et les Api de compiler vers le bas (et répondre aux différents moteur d'exécution de faiblesses).

Je ne pense pas, cependant, aucun de ces "mieux conçu langues" sera Java, Python ou Ruby. Javascript est, en dépit de la capacité à être utilisé ailleurs, une application Web langage de script. Étant donné que les cas d'utilisation, nous pouvons faire mieux que l'une de ces langues.

Answer 2

Je pense que le JavaScript est un langage de qualité, mais j'aimerais avoir un choix lors du développement d'applications web côté client. Pour des raisons d'héritage, nous sommes coincés avec du JavaScript, mais il y a des projets et des idées à la recherche pour le changement de scénario:

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

Je pense que nous allons avoir JavaScript pour une longue période de temps, mais que va changer tôt ou tard. Il ya tellement de nombreux développeurs désireux d'utiliser d'autres langues dans le navigateur.

Answer 3

Répondre à la question - Non, cela n'aurait aucun sens.

Actuellement, le plus proche que nous avons à un langage multi-VM sont la JVM et le CLR. Ce ne sont pas exactement léger bêtes, et il ne serait pas logique d'essayer et d'intégrer quelque chose de cette taille et de la complexité dans un navigateur.

Intéressons-nous à l'idée que l'on peut écrire une nouvelle, multilingue VM ce serait mieux que la solution existante.

• Vous êtes en retard sur la stabilité.
• Vous êtes en retard sur la complexité (chemin, voie, derrière parce que 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, à l'appui de ces langues, vous allez avoir à démonter leurs Api quelque chose de féroce, les découper toutes les pièces qui n'ont aucun sens dans le contexte d'un navigateur de script. Il existe un grand nombre de décisions de conception à faire ici, et une énorme opportunité pour l'erreur.

En termes de fonctionnalité, nous sommes probablement la seule vraiment travailler avec les DOM toute façon, donc c'est vraiment une question de langage et de la syntaxe idom, à quel point il est logique de demander, "Est-ce vraiment la peine?"

En gardant à l'esprit, la seule chose que nous parlons, c'est le script côté client, en raison des scripts côté serveur est déjà disponible dans la langue que vous souhaitez. C'est une relativement petite de la programmation de l'arène et donc l'avantage de rassembler de nombreuses langues est discutable.

Quelles sont les langues qu'il est logique de mettre en? (Attention, subjective matériel suit)

Mettre dans un langage tel que le C n'a pas de sens parce qu'il est fait pour travailler avec le métal, et dans un navigateur, il n'y a pas beaucoup de métal vraiment disponible.

Mettre dans un langage tel que Java n'a pas de sens parce que la meilleure chose, c'est l'Api de toute façon.

Mettre dans un langage comme le Rubis ou le Lisp ne fait pas de sens parce que le JavaScript est un puissant langage de programmation dynamique très proche du Régime.

Enfin, ce navigateur maker veut vraiment soutenir DOM l'intégration de plusieurs langues? Chaque application a ses propres bugs. Nous avons déjà passé par le feu face aux différences entre MS Javascript et Javascript de Mozilla et maintenant, nous voulons multiplier les douleurs cinq ou six fois?

Il ne fait pas de sens.

Answer 4

Sur Windows, vous pouvez enregistrer d'autres langues avec l'Hôte de Script et elles seront disponibles à IE. Par exemple VBScript est pris en charge hors de la boîte (bien qu'il n'a jamais gagné beaucoup de popularité car il est pour la plupart des fins, même pire que JavaScript).

Le Python win32 extensions permettent d'ajouter Python-à-dire comme ceci assez facilement, mais ce n'était pas vraiment une bonne idée que Python est assez difficile de sandbox: de nombreuses fonctionnalités de langage exposer assez de la mise en œuvre des crochets pour permettre à un soi-disant-application restreinte de sortir.

C'est un problème en général, que le plus de complexité que vous ajoutez à un net-face applications comme le navigateur, la plus grande probabilité de problèmes de sécurité. Un tas de nouvelles langues serait certainement correspondent à cette description, et ce sont de nouvelles langues sont également toujours en développement rapide.

JavaScript est un truand de la langue, mais par le biais de l'utilisation prudente d'un sélectif sous-ensemble de fonctionnalités et le soutien de l'objet approprié bibliothèques, il peut généralement être fait assez tolérable. Il semble progressive, la pratique des ajouts de JavaScript sont le seul moyen de script web est susceptible de se déplacer sur.

Answer 5

Je serait certainement la bienvenue à une norme indépendante de la langue de VM dans les navigateurs (je préfère de code dans un langage statiquement typé).

(Techniquement), Il est tout à fait faisable progressivement: d'abord l'un des principaux navigateur prend en charge et le serveur a la possibilité d'envoyer bytecode si la requête courante est de navigateur compatible ou traduire le code JavaScript et l'envoyer en texte clair en JavaScript.

Il existe déjà certaines expérimentales langues que les compiler en JavaScript, mais d'avoir une VM définie seraient (peut-être) pour de meilleures performances.

J'avoue que le "standard" de la partie allait être très difficile, cependant. Aussi, il y aura des conflits entre les fonctions du langage (par exemple. statique vs dynamique de la frappe) concernant la bibliothèque (en supposant que la nouvelle chose serait d'utiliser la même bibliothèque). Donc je ne pense pas que cela va se produire (bientôt).