Objective-J se compila/transforma en JavaScript directamente en el navegador. (Esto contrasta con hacer esto en el servidor, como GWT lo hace con Java). ¿Se ha implementado este enfoque para cualquier idioma, aparte de Objective-J?¿Hay otros lenguajes distintos de Objective-J que se "compilan" a JavaScript en el navegador?
Heres un ejemplo que compila un ruby like language para javascript - y la compilación se puede hacer en el navegador.
El CoffeeScript compilador compila CoffeeScript en ECMAScript. Como el compilador CoffeeScript está escrito en CoffeeScript, puede compilarse en ECMAScript y ejecutarse en el navegador. Los bits y piezas necesarios para admitir los elementos <script type='text/coffeescript'> ya están incluidos en el compilador CoffeeScript estándar.
En general, cualquier lenguaje se puede compilar en ECMAScript, todo lo que necesita es un compilador. Y, puesto que cualquier idioma puede ser compilado para ECMAScript, cualquier compilador puede ser compilado para ECMAScript, todo lo que necesita es un compilador para el lenguaje que compilador está escrito en.
Esto conduce a una explosión combinatoria de posibilidades para compilar idiomas dentro del navegador.
Por ejemplo, hay un tipo que escribe C compilers which target high-level languages por diversión. Él tiene un compilador que compila C a Java, Perl, Common Lisp, Lua o ECMAScript. Entonces, puede usar ese compilador para compilar cualquier otro compilador escrito en C en ECMAScript. Y la mayoría de los lenguajes tienen algún compilador en algún lugar que está escrito en C.
La pista está escrita en C. Clue compila C en ECMAScript. Ergo, puede usar Clue para compilar Clue en ECMAScript. Luego, puede ejecutar Clue en el navegador para compilar C a ECMAScript sobre la marcha. <script type='text/c'>, alguien? (Pensamiento Diversión: Node.js está escrito en C Hmm y hellip;)
En un tono más serio: en general, hay tres razones para la compilación de ECMAScript:
Si simplemente desea reutilizar el código existente escrito en un idioma diferente (o conocimiento existente en un idioma diferente), entonces compilar/interpretar en el clie no tiene mucho sentido. El código o el codificador no esperan poder usar los elementos <script> de todos modos. Esta categoría incluye cosas como GWT o Volta.
Si (tipo) la seguridad es su objetivo, la compilación/interpretación en el cliente simplemente no funciona: ¿cómo se puede garantizar la seguridad si no se controla el compilador? Es por eso que Ur/Web, Links, Flapjax, haXe, Caja y compilan el código en el servidor. Garantizan la seguridad ya sea mediante tipado estático o integración ajustada o ambos. (Por integración estrecha me refiero a que el backend, el frontend y la aplicación están estrechamente conectados, por ej.especificando las estructuras de datos una vez y luego generando los formularios SQL, ECMAScript y HTML correspondientes de esa única fuente para asegurarse de que todos coincidan. Debería ser obvio por qué esto requiere procesamiento en el servidor.)
Los que se centran en la expresividad, sin embargo, esperan ser utilizados como un reemplazo de ECMAScript, es decir, dentro de los elementos <script>, y por lo tanto, a menudo vienen con intérpretes y/o compiladores que se ejecutan en el cliente. CoffeeScript, Objective-J y Clamato entran en esta categoría.
Además de estas listas hay un índice aquí: http://altjs.org/ que tiene:
y más
Guau, eso fue ... interesante. Aparece dos Tylenol. – UnkwnTech
Muy buena respuesta! Y tendré que probar CoffeeScript. –