javascript - soljson - solidity español
¿Hay otros lenguajes aparte de Objective-J que se "compilan" a JavaScript en el navegador? (4)
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?
Aquí hay un ejemplo que compila un ruby like language para javascript, y la compilación se puede hacer en el navegador.
El compilador CoffeeScript 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 puede compilarse en ECMAScript, todo lo que necesita es un compilador. Y, como cualquier lenguaje puede compilarse en ECMAScript, cualquier compilador puede compilarse en ECMAScript, todo lo que necesita es un compilador para el lenguaje en el que está escrito el compilador.
Esto conduce a una explosión combinatoria de posibilidades para compilar idiomas dentro del navegador.
Por ejemplo, está este tipo que escribe compiladores de C que se dirigen a los lenguajes de alto nivel para divertirse. É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 a ECMAScript. Y la mayoría de los lenguajes tienen algún compilador en alguna parte que está escrito en C.
Clue está escrito en C. Clue compila C con 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 divertido: node.js está escrito en C. Hmm ...)
En una nota más seria: generalmente hay tres razones para compilar en ECMAScript:
- reutilizar
- la seguridad
- expresividad
Si simplemente desea reutilizar el código existente escrito en un idioma diferente (o conocimiento existente en un idioma diferente), la compilación / interpretación en el cliente no tiene mucho sentido. El código o el codificador no espera poder utilizar elementos <script> todos modos. Esta categoría incluye cosas como GWT o Volta .
Si su objetivo es (escribir) seguridad, entonces la compilación / interpretación en el cliente simplemente no funciona: ¿cómo puede garantizar la seguridad si no controla el compilador? Es por eso que Ur / Web , Links , Flapjax , haXe , Caja y otros 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 quiero decir que el backend, el frontend y la aplicación están estrechamente conectados, por ejemplo, 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 para 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:
- Nuevos idiomas
- Mejoras de JavaScript
- Puertos (Java, C, Ruby, etc.)
y más