Objective-J est compilé/transformé en JavaScript directement sur le navigateur. (Cela contraste avec le fait de faire cela sur le serveur, comme le fait GWT pour Java.) Est-ce que cette approche a été implémentée pour n'importe quelle langue, autre que Objective-J?Existe-t-il d'autres langages que Objective-J qui sont "compilés" en JavaScript dans le navigateur?
Voici un exemple qui compile un langage similaire à ruby en javascript - et la compilation peut être effectuée dans le navigateur.
Le compilateur CoffeeScript compile CoffeeScript dans ECMAScript. Puisque le compilateur CoffeeScript est lui-même écrit dans CoffeeScript, il peut se compiler lui-même dans ECMAScript et ainsi s'exécuter dans le navigateur. Les éléments nécessaires à la prise en charge des éléments <script type='text/coffeescript'> sont déjà inclus dans le compilateur standard CoffeeScript.
En général, n'importe quel langage peut être compilé à ECMAScript, tout ce dont vous avez besoin est un compilateur. Et, étant donné que toute langue peut être compilé pour ECMAScript, tout compilateur peut être compilé pour ECMAScript, tout ce que vous avez besoin est un compilateur pour le langage que le compilateur est écrit dans.
Cela conduit à une explosion combinatoire des possibilités de compilation des langues dans le navigateur.
Par exemple, il y a ce type qui écrit C compilers which target high-level languages pour le plaisir. Il a un compilateur qui compile C en Java, Perl, Common Lisp, Lua ou ECMAScript. Ainsi, vous pouvez utiliser ce compilateur pour compiler tout autre compilateur écrit en C vers ECMAScript. Et la plupart des langages ont un compilateur quelque part qui est écrit en C.
Clue est écrit en C. Clue compile C en ECMAScript. Ergo, vous pouvez utiliser Clue pour compiler Clue à ECMAScript. Ensuite, vous pouvez exécuter Clue dans le navigateur pour compiler C vers ECMAScript à la volée. <script type='text/c'>, quelqu'un? (Pensée Fun: Node.js est écrit en C. Hmm & hellip;)
Sur une note plus grave: il y a généralement trois raisons pour la compilation de ECMAScript:
Si vous voulez simplement réutiliser du code existant écrit dans une langue différente (ou savoir existant dans une autre langue), puis compiler/interpréter sur le clie Cela n'a pas beaucoup de sens. Le code ou le codeur ne s'attend pas à pouvoir utiliser les éléments <script> de toute façon. Cette catégorie comprend des choses comme GWT ou Volta.
Si la sécurité (type-) est votre but, alors la compilation/interprétation sur le client ne fonctionne tout simplement pas: comment pouvez-vous garantir la sécurité si vous ne contrôlez pas le compilateur? C'est pourquoi Ur/Web, Links, Flapjax, haXe, Caja et de tels compiler le code sur le serveur. Ils garantissent la sécurité soit par typage statique ou intégration étroite ou les deux. (Par une intégration étroite, je veux dire que le backend, l'interface et l'application sont étroitement connectés, par ex.spécifier les structures de données une fois puis générer les formulaires SQL, ECMAScript et HTML correspondants à partir de cette source unique pour s'assurer qu'ils correspondent tous. Ceux qui se concentrent sur l'expressivité, cependant, s'attendent à être utilisés en remplacement d'ECMAScript, c'est-à-dire à l'intérieur des éléments <script>, et donc ils viennent souvent avec des interprètes et/ou ou des compilateurs qui fonctionnent sur le client. CoffeeScript, Objective-J et Clamato entrent dans cette catégorie.
En plus de ces listes il y a un indice ici: http://altjs.org/ qui a:
et plus
Wow, c'était ... intéressant. Pops deux Tylenol. – UnkwnTech
Très bonne réponse! Et je vais devoir essayer un peu de CoffeeScript. –