Pourrai-je jamais coder le code du navigateur côté client dans la langue de mon choix? [fermé]

15

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement les réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 6 ans .

Je serai brutalement honnête: je déteste écrire du code côté client en JavaScript. Je ne suis pas fan de cette langue, c'est le moins qu'on puisse dire.

Il me semble stupide que les navigateurs prennent en charge un langage de programmation , plutôt qu'une machine virtuelle intermédiaire (comme CIL ou JVM). Ce dernier permettrait aux programmeurs d'écrire dans une langue de leur choix (dans une certaine mesure), plutôt que dans une langue fixe prédéfinie. Ce langage pourrait évoluer plus rapidement, car seules les modifications apportées à CIL / JVM / tout ce qui nécessiterait la mise à niveau de chaque navigateur principal. Les fonctionnalités linguistiques peuvent être ajoutées sans affecter l'ancienne expérience du navigateur.

Les économies massives d'efforts que les langages intermédiaires entraînent sont bien connues . Existe-t-il des initiatives pour promouvoir le "scripting" du navigateur dans autre chose que JavaScript, et en particulier dans une machine virtuelle déjà conçue, développée et optimisée? Ont-ils un élan?

programming-languages browser

— Roman Starkov
source

voir aussi: Pourquoi n'y a-t-il pas d'autres langages de script côté client pour les sites Web?

— moucheron

11

Pour répondre à votre question, oui, des efforts sont faits pour déprécier Javascript au profit d'un langage plus cohérent pour les scripts web. Google a mis beaucoup d'effort derrière son langage Dart . Dart a sa propre machine virtuelle qui est déjà intégrée à Chrome, mais je ne sais pas si les autres navigateurs l'ont déjà adoptée. Il existe également un langage assez prometteur appelé CoffeeScript .

Il y a aussi un projet très ambitieux appelé HaXe qui vise à unifier toute une série de plateformes de développement avec un seul langage.

Croyez-moi, vous n'êtes pas le seul à ne pas aimer Javascript, mais je crains que cela ne se produise pas bientôt - en fait, il semble gagner beaucoup d'élan avec les applications HTML5 / JS de Windows 8, etc., mais des alternatives comme celles que je mentionnés commencent à apparaître :)

— MattDavey
source

9

Unifier tout en une seule langue est exactement le contraire de ce qui est souhaité. Cela ne vous laisse que dans la même situation que maintenant, juste avec une langue différente au lieu de JavaScript. Le fait est que les efforts existants doivent être renforcés: IL / CLR est bien établi, possède déjà des JITters très performants pour la plupart des plates-formes, et plusieurs compilateurs compilent déjà plusieurs langues dans celui-ci. Pour faire entrer le Web dans le 21e siècle, les navigateurs doivent s'en servir, au lieu d'essayer constamment de préparer leurs propres nouveaux trucs et de recommencer à zéro.

— Timwi

3

@Timwi, CIL est trop lourd et contient trop de bureaucratie. Il ne serait pas logique de joindre un fichier de bytecode complet et gonflé avec une classe dédiée et toutes les métadonnées volumineuses à chaque onSomethinggestionnaire d'événements - l'analyse et l'interprétation de 10 à 20 caractères d'un langage de script simple est beaucoup plus efficace.

— SK-logic

1

@ SK-logic: Vous semblez avoir une image complètement fausse du CIL et du bytecode en général. Je n'ai aucune idée de ce qui pourrait vous faire penser que les métadonnées binaires sont «volumineuses» par rapport à une syntaxe de haut niveau comme JavaScript. Surtout, je ne sais pas pourquoi le «chaque gestionnaire d'événements onSomething». Les programmes C # ne se compilent clairement pas en plusieurs assemblys pour chaque gestionnaire d'événements.

— Timwi

1

@ Timwi, je mange de l'ECMA-335 pour le petit-déjeuner, donc je sais trop bien à quel point le CIL est volumineux. Les nœuds DOM sont souvent générés dynamiquement. Il n'y a aucun moyen d'ajouter quelque chose à un module existant dans CIL - vous devez définir un nouveau module. Et vous ne pouvez pas ajouter à une classe - vous devez définir une nouvelle classe (avec les métadonnées volumineuses attachées). Et comparez simplement le coût de lecture, de JIT et d'exécution de CIL à l'analyse, l'exécution et l'élimination immédiate d'une toute petite chaîne de texte. Il existe de nombreux cas où une interprétation ad hoc est beaucoup plus efficace que tout type de compilation.

— SK-logic

2

@Timwi, vous proposez d'utiliser le bytecode comme dénominateur commun et format de communication, non? Mon point est que la spécification actuelle du CIL est à peu près inutile. ExpandoObject n'est pas pertinent. Et votre vision de l'analyse de la complexité est obscurcie. Le module CIL contient sa propre table de référence d'assembly, sa table de jetons de métadonnées et uniquement les classes et méthodes. Comparez l'effort requis pour lire et JIT tous ces trucs volumineux avec l'interprétation d'une chaîne d'un langage trivial de haut niveau. Le coût d'analyse est presque nul ici. Essayez simplement les deux approches et comparez-vous.

— SK-logic

5

Javascript lui-même peut être considéré comme un langage intermédiaire, définissant une machine virtuelle dans laquelle d'autres langues peuvent être compilées. Dans des projets comme GWT, cette notion prend déjà son envol. Ce n'est peut-être pas ce que vous concevez à partir de zéro, mais cela devient déjà une réalité que vous pouvez compiler "votre langue préférée" en Javascript.

— John Snelson
source

5

Essentiellement, non. Vous êtes à peu près coincé avec Javascript.

Cela dit, il y a eu des efforts dans le passé pour intégrer d'autres langues (applets java, vbscript, etc.). Chacune d'elles n'a jamais vraiment gagné la traction que javascript a parce que javascript est intégré .

La seule façon de construire ce à quoi vous faites référence serait de créer un langage de script qui s'exécute sur une machine virtuelle, côté client compilé, puis exécuté. Ensuite, chaque navigateur devrait implémenter la machine virtuelle dans sa propre base de code afin que tout le code s'exécute sur tous les navigateurs. Ensuite, vous devez vous assurer d'avoir une sorte de normes pour que tous les navigateurs exécutent les commandes de la même manière. Bien sûr, les navigateurs étant créés indépendamment, il y aurait probablement des bizarreries que les développeurs devraient garder à l'esprit.

Mais maintenant, nous venons de décrire Javascript.

Donc au final, vos choix sont:

s'habituer à Javascript
essayez d'utiliser un langage qui se compile en Javascript. (Gardez à l'esprit que vous voudrez toujours vérifier le Javascript, ce qui ramène à l'option 1.)
utiliser un langage qui existe en tant que plug-in pour le navigateur, tel que actionscript (Flash), ActiveX, applet java, .Net (SilverLight). Cela évite le problème avec plusieurs fournisseurs / implémentations de la langue, mais ne pas intégrer la langue.

Essentiellement, si vous voulez un langage intégré, vous êtes coincé avec Javascript.

— Richard
source

2

Un autre choix serait d'utiliser un langage qui se compile en javascript et de l'utiliser.

— Jetti

@Jetti Pensez-vous à CoffeeScript ? C'est la devise - c'est "la règle d'or" comme ils l'appellent - c'est "c'est juste Javascript" . Mais si vous écrivez quelque chose qui est essentiellement Javascript, n'écrivez-vous pas vraiment Javascript? C'est comme faire valoir que jQuery n'est pas javascript car il est plus propre et plus facile à utiliser.

— Richard

2

jetez un oeil à cette liste de langues qui se compilent en javascript

— Jetti

@Jetti Peut-être qu'ils travailleraient bien. Mais avec la bizarrerie de la prise en charge de plusieurs navigateurs, je serais nerveux à l'idée de recommander l'un de ceux-ci et de ne pas vérifier le javascript généré.

— Richard

1

Sauf que javascript est un langage intermédiaire tout à fait horrible, et très difficile à exécuter de manière cohérente.

— Milind R

4

En fait, vous ne détestez pas le javascript, comme décrit dans les normes Ecma, mais vous détestez la terrible implémentation sur divers navigateurs , avec leurs bizarreries, bogues et wtfs. Le Javascript côté serveur est en fait assez agréable. Le modèle DOM est également à l'origine de 80% de la douleur du javascript côté client.

Si vous souhaitez toujours utiliser un autre langage, vous pouvez utiliser GWT , qui vous permet essentiellement d'écrire Java, puis de le compiler en (laid) javascript, ou CoffeeScript , qui est un sucre syntaxique sur JS, qui se compile en JS.

— Clement Herreman
source

9

Je ne peux pas parler pour romkyns, mais je déteste JavaScript lui-même ( en plus des problèmes que vous avez mentionnés). Il n'est pas orienté objet, n'a pas de typage statique, pas de gestion d'erreurs utile et pas de cadre utile de fonctionnalités modernes. Il est également incohérent et peu maniable. Et en passant, la caractéristique la plus détestée de JS, l'insertion de points-virgules, se trouve dans la norme ECMA.

— Timwi

1

@Timwi, il est basé sur les fonctions et vous pouvez écrire du code OO si vous le souhaitez. La frappe statique est agréable, mais si votre code est bien écrit (petites fonctions, portée appropriée), c'est rarement un problème. Quant à l'insertion de points-virgules, je trouve que c'est une légère gêne. Cela ne m'a jamais mordu qu'une seule fois, car j'ai eu le retour et l'ouverture {d'un objet sur différentes lignes. Quel "cadre de fonctionnalités modernes" manque-t-il?

— CaffGeek

2

JavaScript lui-même n'est pas le meilleur langage (pour le dire poliment). Je ne me soucie pas des choses orientées objet (le moins - le mieux), de son système de type dynamique (il est vraiment nécessaire pour un langage de script de ce type, malheureusement), mais de la présence de déclarations et du manque de listes et tuples est ennuyeux. À la fois pour écrire en JavaScript et pour implémenter des compilateurs qui ciblent JavaScript.

— SK-logic

2

@Timwi: vous voyez que le fait de ne pas être orienté objet est une mauvaise chose, alors que ce n'est pas toujours le cas. Veuillez ne pas voir la POO comme la solution miracle des paradigmes de développement. L'approche fonctionnelle, comme JS ou Scala, est également excellente. Vous pouvez avoir la POO dans JS, mais la principale différence est qu'il s'agit d'une programmation basée sur un prototype, au lieu d'une programmation basée sur une classe. OOP est un nom large et ne se limite pas à Java / C #. Basé sur un prototype est différent de basé sur une classe et bien utilisé, il est aussi puissant que basé sur une classe.

— Clement Herreman

2

@ClementHerreman: JavaScript n'est pas limité au côté client, mais cette discussion concerne le côté client. JavaScript est limité aux prototypes, ce qui est un inconvénient par rapport à IL qui vous permettrait d'utiliser à peu près n'importe quel langage.

— Timwi

2

Cette question revient de temps en temps.

Pourquoi n'avons-nous pas d'autres langues dans les balises de script au lieu de simplement Javascript

À l'époque, IE a introduit VB comme alternative à Javascript. Je pense que vous pouvez déjà voir comment cela conduirait à l'enfer des normes si cela se propageait ...

Alors pourquoi pas un langage intermédiaire standard commun alors?

Il y a un vieux podcast de Brendan Eich expliquant pourquoi il ne voit pas de langage de bytecode intermédiaire dans un avenir proche:

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

Le problème de base est que tandis que le langage intermédiaire (comme CIL et les bytecodes JVM) essaie d'être générique, la plupart du temps, il s'avère qu'ils sont de niveau trop bas et trop liés aux langages de haut niveau d'origine qui les ont compilés. Par exemple, vous ne pouvez pas vraiment implémenter des fonctions récursives de queue dans la JVM - quelles autres fonctionnalités de langage ou choix d'implémentation serons-nous incapables d'implémenter si nous nous couplons à une abstraction de bytecode de bas niveau trop tôt?

Pendant ce temps, Javascript est un langage flexible de haut niveau avec une sémantique établie et des implémentations multiples, différentes et efficaces. Ce que nous pourrions voir à l'avenir, c'est Javascript lui-même en tant que langage intermédiaire - Malheureusement, c'est un peu immature et peu de langues se compilent en JS à ce jour.

— hugomg
source

Mais cet argument s'applique à JavaScript tout autant qu'à JVM et CIL, n'est-ce pas? :) La seule chose qui va avec JavaScript est qu'il est déjà pris en charge par tous les navigateurs.

— Roman Starkov

Le point est plus subtil - Javascript est décrit à un niveau plus élevé que la plupart des langages intermédiaires, de sorte que les implémentations ont plus d'espace pour les jambes dans le choix de ce qu'il faut faire. (Bien sûr, ce n'est pas tout une mer de roses - je voulais juste souligner que nous ne sommes pas les premiers à penser à un IL pour le web et que ce n'est pas si simple)

— hugomg

1

Oui. Vous pouvez déjà compiler Dart, Coffeescript et Java en Javascript. Vous avez Emscripten, qui est un backend de compilateur pour LLVM pour générer du bytecode Javascript (et LLVM gère pas mal de langues, je crois).

Mais à part la compilation en JS, pas dans un court laps de temps. IE6 a 10 ans et continue de donner des coups de pied. J'espère que les navigateurs actuels (qui ne prennent pas en charge d'autres langues) ne survivront pas aussi longtemps, mais ils resteront en place pendant quelques années, provoquant le cycle mordant de la queue "nous devons encore prendre en charge les navigateurs qui ne prennent en charge que Javascript, nous devons donc utiliser Javascript ", d'une manière beaucoup plus difficile que de dire CSS3 - votre site pourrait fonctionner sans CSS3, mais essayez de le faire fonctionner sans script côté client.

— alex
source

0

Vous pourriez avoir de la chance. Voici le premier paragraphe d'une soumission sur le forum webkit-dev:

De nombreuses langues se compilent aujourd'hui en JavaScript pour fonctionner sur le Web. Comme alternative, nous avons expérimenté avec l'activation de différentes exécutions de langue dans WebKit pour s'exécuter dans des pages Web avec JavaScript ...

Vous pouvez voir le reste du message ici .

— pgfearo
source

0

JavaScript est l'âme même des navigateurs, c'est pourquoi la majorité des nouvelles tentatives génèrent du JavaScript (CoffeeScript en est un exemple clair).
Dans GWT, vous codez votre logique côté client dans le langage de programmation Java et la boîte à outils avec génère JavaScript.

ClojureScript est un projet intéressant si vous êtes en codage Lisp.

Donc, quoi qu'il en soit, JavaScript est là pour rester. (COBOL du web peut-être?).

— Chiron
source

0

"Tout client peut faire peindre une voiture de la couleur de son choix tant qu'elle est noire." -- Henry Ford

Il existe déjà un certain nombre de compilateurs qui ciblent le javascript, et vous pouvez choisir n'importe quelle langue qui se compile en javascript.

Votre lien traitant de la valeur des langages intermédiaires en parle dans le contexte de l'implémentation d'une suite de compilateurs, et non dans la fourniture de code qui sera expédié sur un réseau et exécuté sur une machine cliente. Javascript n'est peut-être pas le meilleur format pour cela, mais quoi qu'il en soit, il ne ressemblera pas beaucoup aux bytecodes CIL ou java.

Si vous détestez le javascript, je vous suggère de vous déplacer dans l'espace de développement intégré, scientifique ou de jeu, où C, Fortran et C ++ régissent le perchoir. Les applications métier évoluent sur le Web, ce qui signifie plus de Javascript, pas moins.

— Sean McMillan
source