Pourquoi n'y a-t-il pas d'autres langages de script côté client pour les sites Web? [fermé]

35

Pourquoi ne prend-on en charge que JavaScript et certains VBScript dans les navigateurs actuels? Je sais que JavaScript est bon et tout, mais la possibilité d'utiliser un autre langage de programmation ne permettrait-elle pas de promouvoir différents styles de développement?

web-development javascript browser

— Eric Packwood
source

1

Voir cette question sur Stack Overflow: stackoverflow.com/questions/2872037/…

— Corey

1

Votre question est précisément pourquoi Google a créé GWT .

— route le

1

Je crois que l'objectif de l'API DOM était de prendre en charge plusieurs langues. En fait, JS est vraiment bien adapté au défi. Il se normalise comme si personne ne le faisait et les fonctions de première classe sont énormes dans un paradigme fortement axé sur les événements. En fin de compte, personne n’a voulu laisser MS prendre cette décision et personne n’en a proposé une meilleure que JS. En outre, les applets Java étaient vraiment, vraiment boiteux.

— Erik Reppen

33

Il n'est pas nécessaire d'ajouter suport pour plusieurs langues, une solution consisterait à normaliser un bytecode générique pouvant être utilisé par les développeurs de langage. Mais il n'y a actuellement aucun plan pour cela (cela a été suggéré).

Les langages peuvent également être implémentés sur Javascript. Javascript est suffisant pour permettre à d’autres langages de s’implémenter. Et il existe déjà de nombreux exemples de cela.

— Nkassis
source

3

+1 - Pour souligner que JavaScript est un langage puissant qui peut être utilisé comme une abstraction pour d'autres langues. Ce serait un projet intéressant d’écrire une extension Firefox exécutant C ++ ou Java côté client! <script type="text/cpp" src="test.cpp"></script>.

— jmort253

2

@ jmort253, jetez un coup d'œil au client natif.

— dan_waterworth

Le client natif est définitivement intéressant, mais à moins que Mozilla ne l’adopte aussi, il n’y aura aucune traction. La dernière fois que j'ai vérifié, ils n'étaient pas encore prêts à le prendre.

— nkassis

1

J'ai trouvé Gestalt ~ il y a quelques années: gestalt.codeplex.com c'est un bon exemple de la construction d'autres langages de script en plus de Javascript.

— Jim Schubert

2

Autre exemple: Google Web Toolkit ? Java est compilé en JavaScript

— MarkJ

21

JavaScript est la norme de facto depuis 1996. Être une norme simplement parce qu'il n'y a pas de concurrence n'est pas tout à fait juste, mais je n'ai pas beaucoup entendu se plaindre de la raison pour laquelle aucune autre langue n'est incluse.

Ajouter un autre langage "standard" favorise toutes sortes de petits problèmes amusants.

Comment vont-ils travailler avec d'autres langues?
Le DOM sera-t-il partagé?
Est-ce que les scripts écrits dans les deux fonctionnent toujours?
Portage de bibliothèques à la fois

— Josh K
source

8

En fait, j'estime que JavaScript est la langue utilisée dans Gecko de Mozilla. Dans IE, nous avons JScript. La plupart des autres navigateurs utilisent quelque chose qui suit plus ou moins les spécifications ECMAScript. Toutes les langues sont appelées «JavaScript» pour plus de simplicité, bien qu'elles diffèrent en réalité.

— Mchl

1

Vous pouvez avoir plusieurs langues qui génèrent le même bytecode. Regardez JVM - Groovy, Java, Scala, Clojure, jRuby peuvent être directement compilés en bytecode JVM. De cette façon, ils partageront le même api DOM et pourront être rendus interopérables. Bien qu'il soit exponentiellement plus difficile à implémenter avec une machine virtuelle JavaScript car elle est interprétée.

— David Sergey

21

Pensez aux incohérences entre les navigateurs pour leur prise en charge de JavaScript uniquement. Maintenant, réfléchissez à ce que ce serait s'il y avait plus de langues.

— Michael Brown
source

5

Yay, il est déjà là, VBScript côté client ... uugh, frisson.

— octobre

1

+1 Je pense que nos têtes s’exploseraient si nous avions un sous-ensemble d’autres langues à mémoriser pour chacun des principaux navigateurs et leurs versions. Bonne réponse.

— Jmort253

4

C’est peut-être une mauvaise idée, mais le support de JavaScript [ECMAScript] par les navigateurs est en réalité très cohérent depuis le début. Ce qui a été incohérent est leur implémentation du DOM (et des méthodes associées). D'un point de vue pratique (et historique), il est difficile de séparer les deux, car la seule utilisation réelle de JS a été de manipuler le DOM dans un navigateur, mais avec l'essor de JS côté serveur (des choses comme NodeJS), cela devient en réalité une distinction assez importante.

— Josh3736

allais écrire à peu près exactement cela comme une réponse, Internet a suffisamment de normes qui ne sont pas suivies ou prises en charge. le fait que le désordre mélangé que nous avons fonctionne à moitié aussi bien qu’il n’est rien de moins qu’un miracle.

— Ryathal

1

Josh a raison. C’est là que l’on se connecte à l’idée démentie du navigateur individuel de la façon dont les choses sont censées être rendues et que JS y accède; ces choses-là sont devenues horribles, mais IE est enfin au moins en train d’assister à des problèmes de longue date avec les API propriétaires (même à la traîne par rapport à la dernière en date à peu près tout en raison de la décision fatidique de MS de lier leur navigateur à leur navigateur de fichiers - jackasses).

— Erik Reppen

6

Les navigateurs doivent être standardisés pour que ce que vous développez fonctionne partout, sur tous les navigateurs.

Si vous avez plusieurs langues en jeu, vous devez vous assurer qu'elles fonctionnent toutes de manière très similaire. Si vous êtes un développeur Web et que vous avez le choix entre plusieurs langues, celles-ci pouvant ou non être prises en charge dans certains pays, il s'agit d'un casse-tête supplémentaire.

Javascript est un langage très flexible, il est impératif, il est fonctionnel, il peut être OOP (à la manière avec des prototypes), et il est interprété. Maintenant, avec des moteurs décents comme dans Chrome, il est raisonnablement capable de faire de bonnes choses. Des langues supplémentaires ne feraient que ramener les choses ici, regarder VBScript, IE uniquement, et ainsi tout ce qui y est écrit est lié à un navigateur et à une plate-forme particuliers, le cauchemar.

— Orbite
source

2

Le point important ici est "avec des moteurs décents comme dans Chrome". Faire quelque chose, même légèrement pénible, fait que même IE8 commence à boiter comme s'il avait une jambe cassée, alors que les versions récentes de Firefox et de Chrome depuis que je l'utilise depuis toujours (c'est la raison pour laquelle j'ai basculé en fait) sautent sans perdre un battement.

— Matthew Scharley

1

@ Matthew Scharley: IE est généralement lent, en effet, il semble empirer avec chaque version. Ils doivent améliorer leur jeu, sinon ils s'en sortiront. La seule raison pour laquelle IE a quelque chose à retenir, c'est à cause de l'inclusion du système d'exploitation. Ils doivent maintenant placer un sélecteur lors de la première utilisation, ce qui a beaucoup chuté.

— Orbling

« il peut être OOP » ... Il est OOP! L'héritage n'est pas ce qui définit la programmation orientée objet. Les objets sont.

— KaptajnKold

@KaptajnKold: C'est un sujet de débat dans les cercles universitaires, de manière surprenante. Je conviens que JS est capable de POO, dans la mesure où il a des objets, mais ils ne sont pas toujours trop utilisés par certains. Le système de prototype est également très différent de la variante de programmation orientée objet habituelle, ce qui le supprime davantage de la définition standard du "langage de programmation orientée objet". Comme dans la plupart des langues, cela dépend de la façon dont vous l'utilisez - lorsque je l'utilise, c'est de la programmation orientée objet.

— Orbling

3

Au lieu de les intégrer dans les navigateurs, les éditeurs préfèrent créer des plug-ins de navigateur encombrants - Java, Flash, Silverlight, etc. Cela garantit la cohérence entre plates-formes.

— Kirk Broadhurst
source

Il ne s’agit pas tant de garantir la cohérence entre les plates-formes que de garantir le contrôle. Comme dans vous contrôlez le plugin et vous n'avez pas à répondre à quelqu'un d'autre.

— Jhocking

Comparés à la difficulté d’exécuter javascript sale rapidement, les plug-ins "clunky" sont bien meilleurs. J'avais l'habitude de ressentir négativement tout le téléchargement de plug-in de navigateur, mais il est nettement plus ouvert que le "javascript implémenté de manière universelle".

— Milind R

2

L’une des raisons est qu’il est pratiquement impossible pour différents éditeurs de navigateurs de s’entendre même sur une implémentation Javascript standard et que javascript est utilisé depuis toujours, du moins du point de vue du langage Web. La plupart des gens pensent donc à juste titre qu'il est pratiquement impossible d'intégrer un autre langage client dans l'écosystème et de faire en sorte que tous les fournisseurs le supportent. La plupart des personnes qui pourraient le réaliser sont déjà impliquées dans les problèmes de standardisation Javascript, ce qui, à mon avis, est bien meilleur. utiliser leur temps.

— davidk01
source

À peu près ce que j'allais dire. La différence importante (dans cette discussion) entre les langages côté client et côté serveur est que les navigateurs doivent implémenter le langage côté client.

— Jhocking

2

Plusieurs réponses prétendent que la prise en charge de plusieurs langues rendrait très odieux pour les constructeurs de navigateurs Web de s’assurer qu’ils sont compatibles avec toutes les langues. Pour moi cela semble incorrect.

Java, par exemple, est un standard extrêmement bien défini. Pour l'essentiel, tout ce que vous avez à faire est d'exposer le DOM du navigateur en tant qu'API Java et d'exécuter la machine virtuelle Java (JVM) dans votre navigateur Web. Vous pouvez spécifier que le code de script doit être fourni sous forme de fichiers JAR compilés et signés, ou sous forme de code source JavaScript. Si le navigateur rencontre du code JavaScript, il peut l'exécuter via un interpréteur dédié (comme aujourd'hui) ou via Rhino au-dessus de la machine virtuelle. S'il rencontre des fichiers jar, il crée un nouveau chargeur de classes et un sandbox de sécurité, charge le bytecode java en mémoire et l'exécute. Cela serait totalement compatible avec les pages Web existantes et permettrait au navigateur, en un seul geste, de prendre en charge les dizaines de langues exécutées sur la machine virtuelle.

Autres avantages:

La JVM a bénéficié d’une décennie d’amélioration des performances. Il est maintenant très rapide, stable et mature. Je parie que vous constaterez une nette amélioration des performances par rapport à javascript interprété.
À mesure que les applications côté client deviennent plus grandes et plus complexes, les avantages des langages structurés et typés, tels que Java et Scala, augmentent.
Vous auriez accès à de véritables multi-threads et à Scala, une bibliothèque de collections optimisée pour l'informatique multicœur.
Vous pouvez utiliser l’un des milliers de bibliothèques Java open source du navigateur.
Par le biais de bibliothèques telles que openGL, le navigateur pourrait fournir un accès à des capacités informatiques avancées de graphisme et de cartes graphiques.
Si vous exécutiez Java sur les côtés client et serveur, vous pourriez également tirer parti des communications client-serveur via une sérialisation extrêmement comprimée et graphe-objet binaire = chargement et exécution plus rapides des pages Web.

— Patrick Arnesen
source

1

Vous pouvez déjà exécuter du code JVM. C'est ce qu'on appelle une applet java

— Raynos

1

Je crois que JavaScript va gagner encore plus de terrain en tant que langage standard pour le Web. Nous assistons à une augmentation du code JavaScript côté serveur. Voici quelques exemples d'implémentations de ce langage puissant sur le serveur:

Serveur Web POW SJS - JavaScript côté serveur pour le serveur Web POW, qui s'exécute en tant qu'extension Firefox ou en tant qu'application XULRunner. SJS joue un rôle similaire à celui de PHP dans Apache en ce sens qu'il peut se connecter à des bases de données et générer du contenu côté client.
NodeJS - JavaScript côté serveur qui utilise un modèle basé sur des événements. Il est construit à l'aide du moteur JavaScript V8 de Google . NodeJS est présenté comme un outil de création de programmes réseau évolutifs. Un serveur Web "Hello World" peut être écrit en seulement 6 lignes courtes!
Jaxer - Un serveur JavaScript qui interprète tous les blocs de script en runat="server"tant que JavaScript côté serveur. Des applications Web entières peuvent être écrites en JavaScript.
Rhino - JavaScript pour Java - Mozilla a créé cette implémentation JavaScript côté serveur qui s'exécute sur Java. Il s'agit essentiellement d'un concept similaire à Querces PHP pour Java , Jython, JRuby et de nombreuses autres abstractions d'autres langages exécutés sur la JVM. Rhino est généralement utilisé pour incorporer JavaScript dans Java afin de fournir des outils de script aux utilisateurs finaux, mais il peut également être utilisé pour déplacer le code côté client sur le serveur sans avoir à réécrire la logique métier dans un autre langage!
JQuery Claypool - Infrastructure JavaScript côté serveur utilisant la puissance de JQuery sur le serveur. Très sympa! Il est développé à l'aide de la mise en œuvre JavaScript d'un navigateur par EnvJs côté serveur.
EnvJs - Un navigateur sans tête construit sur Rhino.

Nombre de ces implémentations et de ces infrastructures démontrent que JavaScript devient une force si puissante dans le développement Web que les leaders de la communauté ont déjà commencé à transférer JavaScript sur le serveur. JavaScript est un langage de programmation fonctionnel extrêmement puissant, et avec le temps, je pense que nous le verrons évoluer.

En résumé, il semble être une contradiction de porter les autres langues sur le navigateur, alors que nous pouvons transférer ce langage unique sur le serveur et combler cette lacune de manière plus unifiée.

— jmort253
source

+1 pour avoir signalé que JavaScript n'est pas limité au navigateur

— Gary Rowe le

1

Il existe plusieurs exemples d’outils permettant de compiler d’autres langages en javascript, notamment Haskel, Lisp et Python (probablement d’autres). Donc, si vous voulez travailler dans l'une de ces langues, vous pouvez le faire.

Et je pense qu'un de mes professeurs d'université a écrit une implémentation de schéma en Javascript. Donc, si vous aimez les régimes, vous pouvez le faire aussi.

— Zachary K
source

0

Les gens ont pallié le manque de variété intégrée de deux manières: en utilisant des plugins tels que des applets flash ou java et en construisant des couches utilisant en quelque sorte le javascript comme "code machine", comme jquery ou le toolkit Web Google. Si un nouveau style de développement était assez populaire, les gens trouveraient un moyen de le faire entrer.

Sachez simplement que si vous créez un runtime .net en javascript et que cela devient de plus en plus populaire, certains cercles maudiront votre nom sur Internet à tout jamais.

— Karl Bielefeldt
source

Blâmez les formulaires Web et IE. Vous auriez moins chié que les développeurs d’UI Web en les piquant avec de gros badges. Pas bon pour l'association de marque.

— Erik Reppen