¿Por qué no hay otros lenguajes de script del lado del cliente para los sitios web? [cerrado]

35

¿Por qué hoy solo se admite JavaScript y algunos VBScript en los navegadores? Sé que JavaScript es bueno y todo, pero ¿no tener la opción de usar otro lenguaje de programación ayudaría a promover diferentes estilos de desarrollo?

web-development javascript browser

— Eric Packwood
fuente

1

Vea esta pregunta en Stack Overflow: stackoverflow.com/questions/2872037/…

— Corey

1

Su pregunta es precisamente por qué Google hizo GWT .

— jhocking

1

Creo que el objetivo de la API DOM era proporcionar soporte para múltiples idiomas. La cuestión es que JS en realidad está muy bien preparado para el desafío. Se normaliza como si no fuera el negocio de nadie y las funciones de primera clase son enormes en un paradigma fuertemente impulsado por eventos. En realidad, todo se redujo a que nadie quería dejar que MS tomara esa decisión y a nadie se le ocurrió una mejor que JS. Además, los Applets de Java eran realmente, REALMENTE cojos.

— Erik Reppen el

33

No es necesario agregar soporte para varios idiomas, una solución sería estandarizar un código de bytes genérico que podría ser utilizado por los implementadores de idiomas. Pero actualmente no hay planes para esto (se ha sugerido).

Los idiomas también se pueden implementar sobre Javascript. Javascript es lo suficientemente bueno como para permitir que otros idiomas se implementen encima. Y ya hay muchos ejemplos de esto.

— nkassis
fuente

3

+1: para señalar que JavaScript es un lenguaje poderoso que se puede usar como abstracción para otros idiomas. ¡Sería un proyecto interesante escribir una extensión de Firefox que ejecutara el cliente C ++ o Java! <script type="text/cpp" src="test.cpp"></script>.

— jmort253

2

@ jmort253, eche un vistazo al cliente nativo.

— dan_waterworth

El cliente nativo es definitivamente interesante, pero a menos que Mozilla lo adopte también, no habrá ninguna tracción. Lo último que comprobé era que aún no estaban listos para enfrentarlo.

— nkassis

1

Encontré Gestalt ~ hace un par de años: gestalt.codeplex.com es un buen ejemplo de cómo construir otros lenguajes de scripting sobre Javascript.

— Jim Schubert

2

Otro ejemplo: Google Web Toolkit ? Java está compilado en JavaScript

— MarkJ

21

JavaScript es el estándar de facto y lo ha sido desde 1996. Ser un estándar simplemente porque no hay competencia no es exactamente justo, pero no he escuchado muchas quejas sobre por qué no se incluye otro idioma.

Agregar otro lenguaje "estándar" promueve todo tipo de pequeños problemas divertidos.

¿Cómo van a trabajar con otros idiomas?
¿Se compartirá el DOM?
¿Podrían funcionar los guiones escritos en ambos?
Portar bibliotecas a ambos

— Josh K
fuente

8

En realidad, creo que JavaScript es el lenguaje utilizado en Gecko de Mozilla. En IE tenemos JScript. La mayoría de los otros navegadores usan algo que sigue más o menos las especificaciones de ECMAScript. Todos estos lenguajes son por simplicidad llamados 'JavaScript', mientras que de hecho difieren.

— Mchl

1

Puede tener varios idiomas que generen el mismo código de bytes. Mire JVM: Groovy, Java, Scala, Clojure, jRuby se pueden compilar directamente en el código de bytes JVM. De esta manera, compartirán la misma API DOM y pueden hacerse interoperables. Aunque es exponencialmente más difícil de implementar con JavaScript VM ya que está interpretado.

— David Sergey

21

Piense en las inconsistencias entre los navegadores por su soporte solo de JavaScript. Ahora piense en cómo sería si hubiera más idiomas.

— Michael Brown
fuente

55

Yay, ya está allí, VBScript del lado del cliente ... uugh, estremecerse.

— ocodo

1

+1 Creo que nuestras cabezas explotarían si tuviéramos que memorizar un subconjunto de otros idiomas para cada uno de los principales navegadores y sus versiones. Buena respuesta.

— jmort253

44

Esto puede ser un poco curioso, pero ... el soporte de los navegadores de JavaScript [ECMAScript] en realidad ha sido muy consistente en todos los ámbitos desde el principio. Lo que ha sido inconsistente es su implementación del DOM (y los métodos asociados). Desde un punto de vista práctico (e histórico), es difícil separar los dos, ya que el único uso real de JS ha sido manipular el DOM en un navegador, pero con el surgimiento de JS del lado del servidor (cosas como NodeJS), esto realmente se convierte en una distinción algo importante.

— josh3736

iba a escribir exactamente esto como respuesta, Internet tiene suficientes estándares que no se siguen o no son compatibles. El hecho de que el desorden mezclado que tenemos funciona a la mitad de lo que funciona es un milagro.

— Ryathal

1

Josh tiene razón. Es donde te conectas con la idea simplificada del navegador individual de cómo se supone que las cosas deben renderizar y JS accede a esas cosas que se pusieron feas, pero IE finalmente al menos atiende problemas de API patentados de larga data en ese frente (a pesar de que continúa va a la zaga de lo último en casi todo debido a la fatídica decisión de MS de vincular su navegador a su navegador de archivos (jackasses).

— Erik Reppen

6

Los navegadores tienen que estar estandarizados, para que lo que desarrolles funcione en todas partes, en todos los navegadores.

Si tiene varios idiomas dando vueltas, entonces debe asegurarse de que todos funcionen de manera muy similar. Si usted es un desarrollador web y tiene una selección de idiomas, que pueden o no ser compatibles en algunas ubicaciones, entonces eso es un dolor de cabeza adicional.

Javascript es un lenguaje muy flexible, es imperativo, es funcional, puede ser POO (de una manera con prototipos), y se interpreta. Ahora con motores decentes como en Chrome, es razonablemente capaz de hacer algunas cosas buenas. Los idiomas adicionales simplemente establecerían las cosas aquí, mire VBScript, solo IE, y todo lo que esté escrito en él está vinculado a un navegador y plataforma en particular, pesadilla.

— Orbling
fuente

2

El punto importante aquí es "con motores decentes como en Chrome". Hacer cualquier cosa, aunque sea un poco exigente, hace que incluso IE8 comience a cojear como si tuviera una pierna rota, mientras que las versiones recientes de Firefox y Chrome desde siempre que lo he usado (esta fue la razón por la que cambié de hecho) saltan sin perder el ritmo.

— Matthew Scharley

1

@Matthew Scharley: IE generalmente es lento, de hecho parece empeorar con cada versión. Necesitan mejorar su juego, o estarán fuera de él. La única razón por la que IE tiene alguna retención es por la inclusión del sistema operativo, ahora tienen que poner un selector en el primer uso, que ha bajado mucho.

— Orbling

"Puede ser POO" ... Se está POO! La herencia no es lo que define la POO. Los objetos son

— KaptajnKold

@KaptajnKold: Sorprendentemente, es un tema de debate en los círculos académicos. Estoy de acuerdo en que JS es capaz de OOP, ya que tiene objetos, sin embargo, algunos no siempre los usan en exceso. El sistema prototipo es bastante diferente al sabor OOP habitual, lo que lo elimina aún más de la definición estándar de "un lenguaje OOP". Como con la mayoría de los idiomas, depende de cómo lo use; cuando lo uso, es POO.

— Orbling

3

En lugar de construirlos en navegadores, a los proveedores les gusta construir complementos de navegador torpes: Java, Flash, Silverlight, etc. Esto garantiza la coherencia entre plataformas.

— Kirk Broadhurst
fuente

Bueno, no se trata de garantizar la coherencia multiplataforma sino de garantizar el control. Como en el control del complemento y no tiene que responder a nadie más.

— jhocking

En comparación con la dificultad de ejecutar JavaScript sucio rápidamente, los complementos "torpes" son mucho mejores. Solía sentirme negativamente acerca de la descarga completa del complemento del navegador, pero definitivamente es más abierto que "javascript implementado de manera universal".

— Milind R

2

Una de las razones es que es prácticamente imposible que diferentes proveedores de navegadores lleguen a un acuerdo sobre una implementación estándar de Javascript y Javascript ha existido desde siempre, al menos desde la perspectiva del lenguaje web. Por lo tanto, la mayoría de la gente piensa con razón que introducir otro lenguaje del lado del cliente en el ecosistema y lograr que todos los proveedores lo respalden es prácticamente imposible y la mayoría de las personas que podrían hacerlo realidad ya están involucradas en problemas de estandarización de Javascript, lo que creo que es mucho mejor. uso de su tiempo.

— davidk01
fuente

Más o menos lo que iba a decir. La diferencia importante (en esta discusión) entre los idiomas del lado del cliente y del lado del servidor es que los navegadores tienen que implementar el lenguaje del lado del cliente.

— jhocking

2

Aquí hay varias respuestas que afirman que admitir varios idiomas haría muy odioso para los creadores de navegadores web asegurarse de que cumplen con todos los idiomas. Para mí esto parece incorrecto.

Java, por ejemplo, es un estándar extremadamente bien definido. Esencialmente, todo lo que necesita hacer es exponer el DOM del navegador como una API de Java y ejecutar la Máquina virtual Java (JVM) dentro de su navegador web. Puede especificar que el código de secuencias de comandos tenga que entregarse en forma de archivos JAR compilados y firmados, o como código fuente JavaScript. Si el navegador encuentra JavaScript, podría ejecutarlo a través de un intérprete dedicado (como lo hace hoy) o a través de Rhino en la parte superior de la JVM. Si encuentra archivos jar, crea un nuevo cargador de clases y un entorno limitado de seguridad, carga el código de bytes de Java en la memoria y lo ejecuta. Esto sería completamente compatible con las páginas web existentes y permitiría que el navegador, con un solo trazo, admitiera docenas de idiomas que se ejecutan en la JVM.

Otras ventajas:

La JVM se ha beneficiado de una década de mejoras de rendimiento. Ahora es muy rápido, estable y maduro. Apuesto a que verías una gran mejora en el rendimiento sobre JavaScript interpretado.
A medida que las aplicaciones del lado del cliente se hacen más grandes y complejas, aumentan los beneficios de los lenguajes estructurados y mecanografiados como Java y Scala.
Tendría acceso a verdaderos subprocesos múltiples y, a través de Scala, una biblioteca de colecciones optimizada para computación multinúcleo.
Puede usar cualquiera de los miles de bibliotecas Java de código abierto dentro del navegador.
A través de bibliotecas como openGL, el navegador podría proporcionar acceso a gráficos avanzados y capacidades informáticas de tarjetas gráficas.
Si tenía Java ejecutándose en el lado del cliente y el servidor, podría beneficiarse aún más de las comunicaciones cliente-servidor a través de una serialización de gráficos de objetos binarios extremadamente comprimida = carga y ejecución más rápidas de páginas web.

— Patrick Arnesen
fuente

1

Ya puedes ejecutar el código JVM. Se llama un applet de Java

— Raynos

1

Creo que JavaScript va a ganar aún más terreno como el lenguaje estándar para la Web. Estamos viendo un aumento en JavaScript del lado del servidor. Aquí hay algunos ejemplos de implementaciones de este poderoso lenguaje en el servidor:

POW Web Server SJS : JavaScript del lado del servidor para el servidor web POW, que se ejecuta como una extensión de Firefox o como una aplicación XULRunner. SJS juega un papel similar al de PHP en Apache en que puede conectarse a bases de datos y generar contenido del lado del cliente.
NodeJS : JavaScript del lado del servidor que utiliza un modelo basado en eventos. Está construido con el motor JavaScript V8 de Google . NodeJS se anuncia como una herramienta para crear programas de red escalables. ¡Un servidor web "Hello World" se puede escribir en solo 6 líneas cortas!
Jaxer : un servidor JavaScript que interpreta todos los bloques de script con runat="server"JavaScript del lado del servidor. Las aplicaciones web completas se pueden escribir en JavaScript.
Rhino - JavaScript para Java - Mozilla creó esta implementación de JavaScript del lado del servidor que se ejecuta en Java. Es esencialmente un concepto similar a Querces PHP para Java , Jython, JRuby y muchas otras abstracciones de otros lenguajes que se ejecutan en la JVM. Rhino generalmente se usa para incrustar JavaScript en Java para proporcionar herramientas de secuencias de comandos a los usuarios finales, pero también se puede usar para mover el código del lado del cliente al servidor sin tener que volver a escribir la lógica de negocios en otro idioma.
JQuery Claypool : marco de JavaScript del lado del servidor que utiliza el poder de JQuery en el servidor. ¡Muy genial! Está desarrollado utilizando la implementación de JavaScript del lado del servidor EnvJs de un navegador.
EnvJs : un navegador sin cabeza construido sobre Rhino.

Lo que demuestran muchas de estas implementaciones y marcos es que JavaScript se está convirtiendo en una fuerza tan poderosa en el desarrollo web que los líderes de la comunidad ya han comenzado a mover JavaScript al servidor. JavaScript es un lenguaje de programación funcional extremadamente poderoso, y con el paso del tiempo creo que lo veremos evolucionar.

En resumen, parece una contradicción portar los otros idiomas al navegador cuando, en cambio, podemos portar este único idioma del navegador al servidor y cerrar esa brecha de una manera más unificada.

— jmort253
fuente

+1 por señalar que JavaScript no está limitado al navegador

— Gary Rowe

1

Hay varios ejemplos de herramientas que compilarán otros lenguajes para javascript, incluidos Haskel, Lisp y Python (probablemente otros). Entonces, si desea trabajar en uno de esos idiomas, puede hacerlo.

Y creo que uno de mis profesores de la universidad escribió un esquema de implementación en Javascript. Entonces, si te gusta el esquema, puedes hacerlo también.

— Zachary K
fuente

0

La gente ha trabajado en torno a la falta de variedad incorporada de dos maneras: usando complementos como flash o applets de Java, y creando capas que usan JavaScript como su "código de máquina", como jquery o kit de herramientas web de google. Si hubiera un nuevo estilo de desarrollo lo suficientemente popular, las personas encontrarían la forma de introducirlo.

Solo tenga en cuenta que si realiza un tiempo de ejecución .net en javascript, y alguna vez se vuelve popular, ciertos círculos maldecirán su nombre en Internet para siempre.

— Karl Bielefeldt
fuente

Culpa a los formularios web y al IE. Mearías menos a los desarrolladores de IU web al pincharlos con hot pokers. No es bueno para la asociación de marca.

— Erik Reppen