¿Podré alguna vez codificar el código del navegador del lado del cliente en un idioma de mi elección? [cerrado]

15

Cerrada . Esta pregunta está basada en la opinión . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que pueda ser respondida con hechos y citas editando esta publicación .

Cerrado hace 6 años .

Seré brutalmente honesto: odio escribir código del lado del cliente en JavaScript. No soy fanático de este lenguaje, por decir lo menos.

Me parece una tontería que los navegadores admitan un lenguaje de programación , en lugar de una máquina virtual intermedia (como CIL o JVM). Esto último permitiría a los programadores escribir en un idioma de su elección (hasta cierto punto), en lugar de hacerlo en un idioma fijo predeterminado. Este lenguaje podría evolucionar más rápidamente, porque solo los cambios en CIL / JVM / lo que sea necesario requerirían la actualización de todos los principales navegadores. Se pueden agregar funciones de idioma sin afectar la experiencia del navegador anterior.

Los ahorros masivos de esfuerzo que producen los idiomas intermedios son bien conocidos . ¿Existen iniciativas para promover el "script" del navegador en algo que no sea JavaScript, y especialmente en una máquina virtual ya diseñada, desarrollada y optimizada? ¿Tienen algún impulso?

programming-languages browser

— Roman Starkov
fuente

ver también: ¿Por qué no hay otros lenguajes de script del lado del cliente para los sitios web?

— mosquito

11

Para responder a su pregunta, sí, se están haciendo esfuerzos para desaprobar Javascript en favor de un lenguaje más coherente para las secuencias de comandos web. Google ha estado poniendo mucho impulso detrás de su lenguaje Dart . Dart tiene su propia máquina virtual que ya está incrustada en Chrome, pero no estoy seguro de si los otros navegadores lo han adoptado todavía. También hay un lenguaje bastante prometedor llamado CoffeeScript .

También hay un proyecto de aspecto muy ambicioso llamado HaXe que tiene como objetivo unificar una gran cantidad de plataformas de desarrollo con un solo idioma.

Créeme, no estás solo en que no te guste Javascript, pero me temo que no irá a ningún lado pronto; de hecho, parece estar ganando mucho impulso con las aplicaciones HTML5 / JS de Windows 8, etc., pero alternativas como las que yo uso mencionados están comenzando a surgir :)

— MattDavey
fuente

99

Unificar todo en un solo idioma es exactamente lo contrario de lo que se desea. Solo te deja en la misma situación que ahora, solo que con un idioma diferente en lugar de JavaScript. El punto es que los esfuerzos existentes deberían basarse en: IL / CLR está bien establecido, ya tiene JITters de alto rendimiento para la mayoría de las plataformas, y varios compiladores ya compilan varios idiomas en él. Para llevar la web al siglo XXI, los navegadores deben hacer uso de eso, en lugar de intentar constantemente hornear sus propias cosas nuevas y comenzar desde cero.

— Timwi

3

@Timwi, CIL es demasiado pesado y tiene demasiada burocracia. No tendría sentido adjuntar un archivo de bytecode completo e hinchado con una clase dedicada y todos los metadatos voluminosos a cada onSomethingcontrolador de eventos: analizar e interpretar 10-20 caracteres de un lenguaje de script simple es mucho más eficiente.

— SK-logic

1

@ SK-logic: Parece que tiene una imagen completamente incorrecta de CIL y del código de bytes en general. No tengo idea de qué te haría pensar que los metadatos binarios son "voluminosos" en comparación con una sintaxis de alto nivel como JavaScript. Sobre todo, no tengo idea de por qué "todos y cada uno de los controladores de eventos onSomething". Los programas de C # claramente no se compilan en múltiples ensamblajes para cada controlador de eventos.

— Timwi

1

@Timwi, estoy comiendo ECMA-335 para el desayuno, así que sé muy bien cuán voluminoso es el CIL. Los nodos DOM a menudo se generan dinámicamente. No hay forma de agregar algo a un módulo existente en CIL: debe definir un nuevo módulo. Y no puede agregar a una clase: debe definir una nueva clase (con los voluminosos metadatos adjuntos). Y simplemente compare el costo de leer, JITAR y ejecutar CIL con analizar, ejecutar y descartar inmediatamente una pequeña cadena de texto. Hay muchos casos en los que una interpretación ad hoc es mucho más eficiente que cualquier tipo de compilación.

— SK-logic

2

@Timwi, está proponiendo utilizar el bytecode como denominador común y formato de comunicación, ¿verdad? Mi punto es que la especificación actual del CIL es prácticamente inútil. ExpandoObject es irrelevante. Y su punto de vista sobre la complejidad del análisis está oscurecido. El módulo CIL contiene su propia tabla de referencia de ensamblaje, tabla de tokens de metadatos y solo entonces clases y métodos. Compare el esfuerzo requerido para leer y JITAR todas estas cosas voluminosas con la interpretación de una cadena de un lenguaje trivial de alto nivel. El costo de análisis es casi cero aquí. Solo prueba ambos enfoques y compárate.

— SK-logic

5

Javascript en sí mismo puede verse como un lenguaje intermedio, que define una máquina virtual en la que se pueden compilar otros idiomas. En proyectos como GWT, esta noción ya está despegando. Puede que no sea lo que diseñaría desde cero, pero ya se está convirtiendo en una realidad que podría compilar "su idioma favorito" en Javascript.

— John Snelson
fuente

5

Básicamente no. Estás prácticamente atascado con Javascript.

Dicho esto, en el pasado se han realizado esfuerzos para incorporar otros idiomas (java applets, vbscript, etc.) Cada uno de estos nunca ganó la tracción que tiene javascript porque javascript está integrado .

La única forma de construir a lo que se refiere es crear un lenguaje de script que se ejecute en una máquina virtual, compile el lado del cliente y luego lo ejecute. Luego, cada navegador tendría que implementar la máquina virtual en su propia base de código para que todo el código se ejecutara en todos los navegadores. Luego, debe asegurarse de tener algún tipo de estándares para que todos los navegadores ejecuten los comandos de la misma manera. Por supuesto, si los navegadores se crean de forma independiente, probablemente habría peculiaridades que los desarrolladores tendrían que tener en cuenta.

Pero ahora acabamos de describir Javascript.

Entonces, al final, sus opciones son:

acostumbrarse a Javascript
intente usar algún lenguaje que compile a Javascript. (Tenga en cuenta que aún querrá verificar el Javascript, que vuelve a la opción 1.)
utilice un lenguaje que exista como complemento del navegador, como actionscript (Flash), ActiveX, java applet, .Net (SilverLight). Esto evita el problema con múltiples proveedores / implementaciones del lenguaje, pero no integra el lenguaje.

Esencialmente, si quieres un lenguaje integrado, estás atascado con Javascript.

— Ricardo
fuente

2

Otra opción sería usar un lenguaje que compila a javascript y usar eso.

— Jetti

@Jetti ¿Estás pensando en CoffeeScript ? Es lema, es "la regla de oro" como lo llaman, es "es solo Javascript" . Pero si estás escribiendo algo que es esencialmente Javascript, ¿no estás realmente escribiendo Javascript? Es como argumentar que jQuery no es javascript porque es más limpio y fácil de usar.

— Richard

2

echar un vistazo a esta lista de idiomas que compilación de JavaScript

— Jetti

@Jetti Tal vez funcionarían bien. Pero con la peculiaridad de la compatibilidad entre navegadores, estaría nervioso por recomendar cualquiera de esos y no verificar el javascript generado real.

— Richard

1

Excepto que javascript es un lenguaje intermedio absolutamente horrible y muy difícil de ejecutar consistentemente.

— Milind R

4

De hecho, no está odiando javascript, como se describe en los estándares de Ecma, pero odia la horrible implementación en varios navegadores , con sus peculiaridades, errores y wtfs. El Javascript del lado del servidor es bastante agradable en realidad. Además, el modelo DOM es la causa del 80% del dolor de javascript del lado del cliente.

Si todavía desea usar otro lenguaje, puede usar GWT , que básicamente le permite escribir Java, luego compilarlo en (feo) javascript o CoffeeScript , que es un azúcar sintáctico sobre JS, que se compila en JS.

— Clemente Herreman
fuente

99

No puedo hablar por romkyns, pero yo odio JavaScript en sí ( además de los problemas que usted ha mencionado). No está orientado a objetos, no tiene tipeo estático, no es útil para el manejo de errores y no tiene un marco útil de funcionalidad moderna. También es inconsistente y difícil de manejar. Y, por cierto, la característica más odiada de JS, la inserción de punto y coma, está en el estándar ECMA.

— Timwi

1

@Timwi, está basado en funciones y puede escribir código OO si lo desea. La escritura estática es buena, pero si su código está bien escrito (funciones pequeñas, alcance adecuado), rara vez es un problema. En cuanto a la inserción de punto y coma, creo que es una molestia leve. Solo me mordió una vez, porque tuve el regreso y la apertura {de un objeto en diferentes líneas. ¿Qué "marco de funcionalidad moderna" encuentra falta?

— CaffGeek

2

JavaScript en sí no es el mejor lenguaje (por decirlo cortésmente). No me importan las cosas orientadas a objetos (cuanto menos, mejor), su sistema de tipo dinámico (desafortunadamente es realmente necesario para un lenguaje de scripting de este tipo), sino la presencia de declaraciones y la falta de listas y tuplas es molesto. Tanto para escribir en JavaScript como para implementar compiladores destinados a JavaScript.

— SK-logic

2

@Timwi: ves que no está orientado a objetos como algo malo, aunque no siempre es así. No veas a OOP como la bala de plata de los paradigmas de desarrollo. El enfoque funcional, como JS o Scala, también es genial. Puede tener OOP en JS, pero la principal diferencia es que es programación basada en prototipos, en lugar de programación basada en clases. OOP es un nombre amplio y no se limita a Java / C #. Basado en prototipo es diferente de basado en clase, y bien utilizado, es tan poderoso como basado en clase.

— Clement Herreman

2

@ClementHerreman: JavaScript no se limita al lado del cliente, pero esta discusión es sobre el lado del cliente. JavaScript está limitado a prototipos, lo cual es una desventaja en comparación con IL que le permitiría usar casi cualquier idioma.

— Timwi

2

Esta pregunta aparece de vez en cuando.

¿Por qué no tenemos otros idiomas en las etiquetas de script en lugar de solo Javascript?

En el pasado, IE introdujo VB como una alternativa a Javascript. Creo que ya se puede ver cómo esto conduciría al infierno de las normas si se da cuenta ...

Entonces, ¿por qué no un lenguaje intermedio estándar común entonces?

Hay un viejo podcast de Brendan Eich que explica por qué no ve un lenguaje de código de bytes intermedio en el futuro cercano:

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

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

El problema básico es que mientras el lenguaje intermedio (como CIL y los bytecodes de JVM) intentan ser genéricos, la mayoría de las veces resultan ser de nivel demasiado bajo y demasiado ligados a los lenguajes originales de alto nivel que se compilaron para ellos. Por ejemplo, realmente no puede implementar funciones recursivas de cola en la JVM: ¿qué otras características de lenguaje u opciones de implementación no podremos implementar si nos acoplamos a una abstracción de bytecode de bajo nivel demasiado pronto?

Mientras tanto, Javascript es un lenguaje flexible de alto nivel con semántica establecida e implementaciones múltiples, diferentes y eficientes. Lo que podríamos ver en el futuro es Javascript en sí mismo como un lenguaje intermedio . Desafortunadamente, esto es algo inmaduro y pocos idiomas compilan a JS a partir de hoy.

— hugomg
fuente

Pero este argumento se aplica tanto a JavaScript como a JVM y CIL, ¿no? :) Lo único que se aplica a JavaScript es que ya es compatible con todos los navegadores.

— Roman Starkov

El punto es más sutil: Javascript se describe en un nivel superior a la mayoría de los idiomas intermedios, por lo que las implementaciones tienen más espacio para elegir qué hacer. (Por supuesto, esto no es todo un mar de rosas - Sólo quería señalar que no somos los primeros en pensar en un IL para la web y que no es así de simple)

— hugomg

1

Si. Ya puede compilar Dart, Coffeescript y Java a Javascript. Tiene Emscripten, que es un backend del compilador para LLVM para generar código de bytes Javascript (y LLVM maneja bastantes idiomas, creo).

Pero aparte de compilar a JS, no en un corto período de tiempo. IE6 tiene 10 años y sigue pateando. Espero que los navegadores actuales (que no son compatibles con otros idiomas) no sobrevivan por tanto tiempo, pero estarán vigentes durante algunos años, provocando el ciclo de morderse la cola de "todavía tenemos que admitir navegadores que solo admitan Javascript, así que tenemos que usar Javascript ", de una manera mucho más difícil que decir CSS3: su sitio podría funcionar sin CSS3, pero intente hacerlo sin secuencias de comandos del lado del cliente.

— alex
fuente

0

Puede que solo tengas suerte. Este es el primer párrafo de una presentación en el foro webkit-dev:

Muchos lenguajes se compilan hoy en JavaScript para ejecutarse en la web. Como alternativa, hemos estado experimentando para habilitar diferentes tiempos de ejecución de idiomas en WebKit para que se ejecuten en páginas web junto con JavaScript ...

Puede ver el resto del mensaje aquí .

— pgfearo
fuente

0

JavaScript es el alma de los navegadores, por eso la mayoría de los nuevos intentos están generando JavaScript (CoffeeScript es un claro ejemplo).
En GWT, codifica su lógica del lado del cliente en lenguaje de programación Java y el kit de herramientas genera JavaScript.

ClojureScript es un proyecto interesante si estás en la codificación Lisp.

Así que parece que no importa qué, JavaScript está aquí para quedarse. (¿COBOL de la web tal vez?).

— Quirón
fuente

0

"Cualquier cliente puede pintar un automóvil del color que quiera, siempre que sea negro". -- Henry Ford

Ya hay una serie de compiladores que se dirigen a JavaScript, y puede elegir cualquier idioma que compile a JavaScript.

Su enlace que discute el valor de los idiomas intermedios los discute en el contexto de la implementación de un conjunto de compiladores, no en la provisión de código que se enviará a través de una red y se ejecutará en una máquina cliente. Puede que Javascript no sea el mejor formato para eso, pero sea lo que sea, no se parecerá mucho a los códigos de bytes CIL o java.

Si odias JavaScript, te sugiero que te muevas al espacio de desarrollo integrado, científico o de juegos, donde C, Fortran y C ++ gobiernan el gallinero. Las aplicaciones de línea de negocio se están moviendo mucho a la web, y eso significa más Javascript, no menos.

— Sean McMillan
fuente