¿Por qué JavaScript en lugar de una máquina virtual de navegador estándar?

Creo que JavaScript es un buen lenguaje, pero me encantaría tener una opción al desarrollar aplicaciones web del lado del cliente. Por razones heredadas estamos atascados con JavaScript, pero hay proyectos e ideas que buscan cambiar ese escenario:

1. Google Native Client : tecnología para ejecutar código nativo en el navegador.
2. Emscripten: compilador de bytecode LLVM para javascript. Permite que los idiomas LLVM se ejecuten en el navegador.
3. Idea:. NET CLI en el navegador, por el creador de Mono: http://tirania.org/blog/archive/2010/May-03.html

Creo que tendremos JavaScript durante mucho tiempo, pero eso cambiará tarde o temprano. Hay muchos desarrolladores dispuestos a usar otros idiomas en el navegador.

Respondiendo a la pregunta - No, no tendría sentido.

Actualmente las cosas más cercanas que tenemos a una máquina virtual multilenguaje son la JVM y el CLR. Estos no son exactamente bestias ligeras, y no tendría sentido tratar de incrustar algo de este tamaño y complejidad en un navegador.

Examinemos la idea de que podría escribir una nueva máquina virtual multilenguaje que sería mejor que la solución existente.

• Estás atrasado en estabilidad.
• Eres detrás de la complejidad (camino, camino, detrás porque estás tratando de generalizar sobre múltiples idiomas)
• Estás atrasado en la adopción

Así que, no, no tiene sentido.

Recuerde, con el fin de apoyar a estos lenguajes vas a tener que despojar a sus API algo feroz, cortar cualquier parte que no tiene sentido en el contexto de un script de navegador. Hay un gran número de decisiones de diseño que se deben tomar aquí, y una gran oportunidad de error.

En en términos de funcionalidad, probablemente solo estamos realmente trabajando con el DOM de todos modos, así que esto es realmente un problema de sintaxis y lenguaje idom, en cuyo momento tiene sentido preguntar: "¿Vale la pena esto?"

Teniendo en cuenta, lo único de es el scripting del lado del cliente, porque el scripting del lado del servidor ya está disponible en cualquier idioma que desee. Es un campo de programación relativamente pequeño, por lo que el beneficio de traer varios idiomas es cuestionable.

¿Qué idiomas tendría sentido traer? (Advertencia, material subjetivo sigue)

Traer un lenguaje como C no tiene sentido porque está hecho para trabajar con metal, y en un navegador no hay mucho metal realmente disponible.

Traer un lenguaje como Java no tiene sentido porque lo mejor de todo son las API.

Traer un lenguaje como Ruby o Lisp no tiene sentido porque JavaScript es una dinámica poderosa lenguaje muy cercano al Esquema.

Finalmente, ¿qué browser maker realmente quiere admitir la integración DOM para varios idiomas? Cada implementación tendrá sus propios errores específicos. Ya hemos caminado a través del fuego tratando con las diferencias entre MS Javascript y Mozilla Javascript y ahora queremos multiplicar ese dolor cinco o seis veces?

No tiene sentido.

En Windows, puede registrar otros idiomas con el Host de Scripting y tenerlos disponibles para IE. Por ejemplo, VBScript es compatible desde el primer momento (aunque nunca ha ganado mucha popularidad, ya que para la mayoría de los propósitos es incluso peor que JavaScript).

Las extensiones de Python win32 permitieron agregar Python a IE de esta manera con bastante facilidad, pero no fue realmente una buena idea, ya que Python es bastante difícil de sandbox: muchas características del lenguaje exponen suficientes ganchos de implementación para permitir una supuestamente-aplicación restringida para escapar.

Es un problema en general que cuanto más complejidad agregue a una aplicación orientada a la red como el navegador, mayor es la probabilidad de problemas de seguridad. Un montón de nuevos idiomas sin duda encajarían en esa descripción, y estos son nuevos idiomas que también se están desarrollando rápidamente.

JavaScript es un lenguaje feo, pero a través del uso cuidadoso de un subconjunto selectivo de características, y el soporte de bibliotecas de objetos adecuadas, puede en general, ser bastante tolerable. Parece incremental, adiciones prácticas a JavaScript son la única manera web scripting es probable que seguir adelante.

Definitivamente daría la bienvenida a una máquina virtual independiente del lenguaje estándar en los navegadores (preferiría codificar en un lenguaje de tipo estático).

(Técnicamente) Es bastante factible gradualmente: el primer navegador principal lo soporta y el servidor tiene la posibilidad de enviar bytecode si la solicitud actual es desde un navegador compatible o traducir el código a JavaScript y enviar JavaScript de texto sin formato.

Ya existen algunos lenguajes experimentales que compilan a JavaScript, pero que tienen un la VM definida (tal vez) permitiría un mejor rendimiento.

Admito que la parte "estándar" sería bastante complicada, sin embargo. También habría conflictos entre las características del lenguaje (por ejemplo. static vs. dynamic typing) concerning the library (assuming the new thing would use same library). Por lo tanto no creo que vaya a suceder (pronto).

Si siente que se está ensuciando las manos, entonces le han lavado el cerebro o todavía está sintiendo los efectos posteriores de los "años DHTML". JavaScript es muy potente, y se adapta bien para su propósito, que es la interactividad de script del lado del cliente. Esta es la razón por JavaScript 2.0 tiene una mala reputación. Quiero decir, por qué paquetes, interfaces, clases y similares, cuando esos son claramente aspectos de los lenguajes del lado del servidor. JavaScript está bien como un lenguaje basado en prototipos, sin ser orientado a objetos en toda regla.

Si hay una falta de continuidad en sus aplicaciones porque el lado del servidor y el lado del cliente no se comunican bien, entonces es posible que desee reconsiderar cómo diseñar sus aplicaciones. He trabajado con sitios web y aplicaciones Web extremadamente robustos, y nunca he dicho, " Hmm, realmente desearía que JavaScript pudiera hacer (xyz)."Si pudiera hacer eso, entonces no sería JavaScript would sería ActionScript o AIR o Silverlight. No necesito eso, y tampoco lo hacen la mayoría de los desarrolladores. Esas son buenas tecnologías, pero tratan de resolver un problema con una tecnología, no con una... bueno, una solución.

Si bien Javascript es el único lenguaje de scripting bien soportado desde el que puede controlar la página directamente, Flash tiene algunas características muy buenas para programas más grandes. Últimamente tiene un JIT y también puede generar bytecode sobre la marcha (echa un vistazo a runtime expression evaluation para ver un ejemplo donde usan flash para compilar expresiones matemáticas de entrada de usuario hasta el binario nativo). El lenguaje Haxe te da tipeo estático con inferencia y con las habilidades de generación de bytecode que podrías implemente casi cualquier sistema de tiempo de ejecución de su elección.

No creo que una máquina virtual web estándar sea tan inconcebible. Hay varias maneras de introducir un nuevo estándar de VM web con gracia y con soporte heredado completo, siempre y cuando se asegure de que cualquier formato de bytecode de VM que use pueda descompilarse rápidamente en javascript, y que la salida resultante sea razonablemente eficiente (incluso diría que un decompilador inteligente probablemente generaría mejor javascript que cualquier javascript que un humano pudiera producir por sí mismo).

Con esta propiedad, cualquier formato de VM web podría descompilarse fácilmente en el servidor (rápido), en el cliente (lento, pero posible en los casos en que tenga un control limitado del servidor), o podría generarse previamente y cargarse dinámicamente por el cliente o el servidor (más rápido) para navegadores que no admiten el nuevo estándar de forma nativa.

Los navegadores que admiten de forma nativa el nuevo estándar se beneficiarían de una mayor velocidad del tiempo de ejecución de las aplicaciones basadas en vm web. Encima de eso, si los navegadores basan sus motores javascript heredados en el estándar de vm web (es decir, analizar javascript en el estándar de vm web y luego ejecutarlo), entonces no tienen que administrar dos tiempos de ejecución, pero eso depende del proveedor del navegador.

Actualización rápida sobre esta vieja pregunta.

Todos los que afirmen que una "página web contendría código de bytes en lugar de cualquier lenguaje de nivel superior como JavaScript" "no sucederá".

Junio 2015 el W3C anunció WebAssembly que es

Un nuevo formato portátil, eficiente en tamaño y tiempo de carga adecuado para compilación a la web.

Esto todavía es experimental, pero ya hay alguna implementación prototípica en Firefox nightly y Chrome Canary y ya hay algún trabajo de demostración.

Actualmente, WebAssembly está diseñado principalmente para ser producido a partir de C/C++, sin embargo

A medida que WebAssembly evolucione, soportará más lenguajes que C/C++, y esperamos que otros compiladores también lo soporten.

Os dejo echar un vistazo más de cerca a la página oficial del proyecto, ¡es realmente emocionante!

Esta pregunta resurge regularmente. mi postura sobre esto es:

A) no sucederá y B) ya está aquí.

Ad A

Una máquina virtual no es solo una especie de dispositivo mágico universal. la mayoría de las máquinas virtuales están optimizadas para un determinado idioma y ciertas características del idioma. tomemos el JRE / Java (o LLVM): optimizado para escritura estática, y definitivamente hay problemas y desventajas al implementar escritura dinámica u otras cosas java no apoyaba en primer lugar.

Entonces, la "VM multipropósito general" que admite muchas características del lenguaje (optimización de llamadas de cola , escritura estática y dinámica, foo bar boo,...) sería colosal, difícil de implementar y probablemente más difícil de optimizar para obtener un buen rendimiento. pero no soy diseñador de lenguaje o gurú de vm, tal vez estoy equivocado: en realidad es bastante fácil, solo que nadie tenía la idea todavía? hrm, hrm.

Ad B

Ya está aquí: puede que no haya un bytecode compilador/vm, pero en realidad no necesita uno. afaik javascript está turing completo, por lo que debería ser posible:

1. crear un traductor del lenguaje X a javascript (por ejemplo, coffeescript)
2. cree un intérprete en javascript que interprete el lenguaje X (por ejemplo, brainfuck). sí, el rendimiento sería abismal, pero oye, no puedo tenerlo todo.

Ad C

¿Qué? ¡no había un punto C en primer lugar!? porque no lo hay ... aun. google NACL. si alguien puede hacerlo, es Google. tan pronto Google lo pone en funcionamiento, sus problemas se resuelven. sólo que puede que nunca funcione, no lo sé. la última vez que leí sobre él había algunos problemas de seguridad sin resolver de la realmente tipo complicado.

Aparte de eso:

• Javascript ha estado allí desde ~1995 = 15 años. aún así, las implementaciones del navegador difieren hoy en día (aunque al menos ya no es insufrible). así que, si empiezas algo nuevo aún, es posible que tenga una versión de trabajo cross browser alrededor de 2035. al menos un subconjunto de trabajo. eso solo difiere sutilmente. y necesita libs y capas de compatibilidad. sin embargo, no tiene sentido no tratar de mejorar las cosas.

• Además, ¿qué pasa con el código fuente legible? sé que muchas compañías preferirían no servir su código como" tipo de " código abierto. personalmente, estoy bastante feliz de poder leer la fuente si sospecho algo sospechoso o quiero aprender de ella. hurra por la fuente código!

En efecto. Silverlight es efectivamente solo eso: una máquina virtual basada en. Net del lado del cliente.

Hay algunos errores en su razonamiento.

1. Una máquina virtual estándar en un navegador estándar nunca será estándar. Tenemos 4 navegadores, e IE tiene intereses en conflicto con respecto a 'estándar'. Los otros tres están evolucionando rápidamente, pero la tasa de adopción de nuevas tecnologías es lenta. ¿Qué pasa con los navegadores en los teléfonos, dispositivos pequeños,...

2. La integración de JS en los diferentes navegadores y su historial nos lleva a subestimar el poder de JS. Usted prometa un estándar, pero desaprueba JS porque el estándar no funcionó en los primeros años.

3. Como han dicho otros, JS no es lo mismo que AIR/. NET / ... y similares. JS en su encarnación actual se ajusta perfectamente a sus objetivos.

A largo plazo, Perl y Ruby bien podrían reemplazar javascript. Sin embargo, la adopción de esos idiomas es lenta y se sabe que nunca se harán cargo de JS.

¿Cómo se define mejor? Mejor para el navegador, o mejor para el desarrollador? (Además ECMAScript es diferente a Javascript, pero eso es un tecnicismo.)

Encuentro que JavaScript puede ser poderoso y elegante al mismo tiempo. Desafortunadamente, la mayoría de los desarrolladores que he conocido lo tratan como un mal necesario en lugar de un lenguaje de programación real.

Algunas de las características que disfruto son:

• tratar las funciones como ciudadanos de primera clase
• ser capaz de añadir y eliminar funciona a cualquier objeto en cualquier momento (no es muy útil pero es alucinante cuando lo es)
• es un lenguaje dinámico.

Es divertido de tratar y está establecido. Disfrútalo mientras está alrededor porque aunque puede no ser el "mejor" para el scripting del cliente, ciertamente es agradable.

Estoy de acuerdo en que es frustrante al hacer páginas dinámicas debido a las incompatibilidades del navegador, pero eso puede ser mitigado por las bibliotecas de interfaz de usuario. Eso no debe ser mantenido en contra de JavaScript en sí más que Swing debe ser sostenido contra Java.

JavaScript es la máquina virtual estándar del navegador. Por ejemplo, OCaml y Haskell ahora tienen compiladores que pueden generar JavaScript. La limitación no es JavaScript el idioma, la limitación son los objetos del navegador accesibles a través de JavaScript y el modelo de control de acceso utilizado para garantizar que pueda ejecutar JavaScript de forma segura sin comprometer su máquina. Los controles de acceso actuales son tan pobres, que JavaScript solo tiene permitido un acceso muy limitado a los objetos del navegador por razones de seguridad. El proyecto Harmony está buscando arreglar eso.

Es una idea genial. ¿Por qué no dar un paso más?

• Escriba el analizador de HTML y el motor de diseño (todos los bits complicados en el navegador, en realidad) en el mismo lenguaje de VM
• Publicar el motor en la web
• Servir a la página con una declaración de qué motor de diseño a utilizar, y su URL

Entonces podemos agregar características a los navegadores sin tener que enviar nuevos navegadores a cada cliente - los nuevos bits relevantes se cargarían dinámicamente desde la web. Podríamos también publicar nuevas versiones de HTML sin toda la ridícula complejidad de mantener la compatibilidad hacia atrás con todo lo que ha funcionado en un navegador - la compatibilidad es responsabilidad del autor de la página. También podemos experimentar con lenguajes de marcado distintos del HTML. Y, por supuesto, podemos escribir compiladores JIT de lujo en los motores, para que pueda escribir sus páginas web en cualquier idioma que desee.

Daría la bienvenida a cualquier lenguaje además de javascript como posible lenguaje de scripting.

Lo que sería genial es usar otros lenguajes luego Javascript. Java probablemente no sería un gran ajuste entre la etiqueta, pero lenguajes como Haskell, Clojure, Scala, Ruby, Groovy serían beneficiosos.

Llegué a un Rubyscript cruzado hace algún tiempo ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby y http://code.google.com/p/ruby-in-browser /
Todavía experimental y en progreso, pero parece prometedor.
Para. Net acabo de encontrar: http://www.silverlight.net/learn/dynamic-languages / Acaba de encontrar el sitio, pero parece interesante también. Funciona incluso desde mi Apple Mac.

No sé qué tan bueno es el trabajo anterior en proporcionar una alternativa para Javascript, pero se ve bastante bien a primera vista. Potencialmente, esto permitiría usar cualquier Java o. Net framework de forma nativa desde el navegador-dentro del sandbox del navegador.

En cuanto a la seguridad, si el lenguaje se ejecuta dentro de la JVM (o el motor.Net para el caso), la VM se encargará de la seguridad, por lo que no tenemos que preocuparnos por eso, al menos no más de lo que deberíamos para cualquier cosa que se ejecute dentro del navegador.

Probablemente, pero para hacerlo necesitaríamos que los principales navegadores los soportaran. IE apoyo sería el más difícil de conseguir. Se usa JavaScript porque es lo único con lo que puedes contar estando disponible.

La gran mayoría de los desarrolladores con los que he hablado sobre ECMAScript et. al. terminan admitiendo que el problema no es el lenguaje de scripting, es el ridículo DOM HTML que expone. Combinar el DOM y el lenguaje de scripting es una fuente común de dolor y frustración con respecto a ECMAScript. Además, no olvide que IIS puede usar JScript para scripting del lado del servidor, y cosas como Rhino le permiten crear aplicaciones independientes en ECMAScript. Intente trabajar en uno de estos entornos con ECMAScript por un tiempo, y ver si su opinión cambia.

Este tipo de desesperación ha estado rondando por algún tiempo. Te sugiero que edites esto para incluir, o volver a publicar con, problemas específicos. Usted puede ser gratamente sorprendido por algo del alivio que obtiene.

Un sitio antiguo, pero sigue siendo un gran lugar para comenzar: El sitio de Douglas Crockford.

Bueno, ya tenemos VBScript, ¿no? Espera, solo IE lo soporta!
Lo mismo para su buena idea de VM. ¿Qué pasa si script mi página usando Lua, y su navegador no tiene el analizador para convertirlo a bytecode? Por supuesto, podríamos imaginar una etiqueta de script aceptando un archivo de bytecode, que incluso sería bastante eficiente.
Pero la experiencia demuestra que es difícil traer algo nuevo a la Web: tomaría años adoptar un cambio radical como este. Cuántos navegadores soportan SVG o ¿CSS3?

Además, no veo lo que encuentras "sucio" en JS. Puede ser feo si es codificado por aficionados, propagando malas prácticas copiadas en otros lugares, pero los maestros demostraron que también puede ser un lenguaje elegante. Un poco como Perl: a menudo parece un lenguaje ofuscado, pero se puede hacer perfectamente legible.

Mira esto http://www.visitmix.com/Labs/Gestalt / - le permite usar python o ruby, siempre y cuando el usuario tenga silverlight instalado.

Esta es una muy buena pregunta.

No es el problema solo en JS, como lo es en la falta de buenos IDE libres para desarrollar programas más grandes en JS. Solo conozco uno que es gratis: Eclipse. La otra buena es Visual Studio de Microsoft, pero no gratis.

¿Por qué sería gratis? Si los proveedores de navegadores web quieren reemplazar las aplicaciones de escritorio con aplicaciones en línea (y lo desean), entonces tienen que darnos, a los programadores, buenas herramientas de desarrollo. No se puede hacer 50.000 líneas de JavaScript usando un simple editor de texto, JSLint y depurador integrado de Google Chrome. A menos que seas un macohist.

Cuando Borland hizo un IDE para Turbo Pascal 4.0 en 1987, fue una revolución en la programación. han pasado 24 años desde entonces. Vergonzosamente, en el año 2011 muchos programadores todavía no utilizan la finalización de código, la comprobación de sintaxis y los depuradores adecuados. Probablemente porque hay muy pocos buenos IDUs.

Está en el interés de los proveedores de navegadores web hacer herramientas adecuadas (GRATUITAS) para los programadores si así lo desean construir aplicaciones con las que puedan luchar contra Windows, Linux, macOS, iOS, Symbian, etc.

Siendo realistas, Javascript es el único lenguaje que cualquier navegador utilizará durante mucho tiempo, por lo que aunque sería muy bueno usar otros idiomas, no puedo ver que suceda.

Esta "máquina virtual estandarizada" de la que hablas sería muy grande y tendría que ser adoptada por todos los principales navegadores, y la mayoría de los sitios simplemente seguirían usando Javascript de todos modos, ya que es más adecuado para sitios web que muchos otros navegadores.

Tendría que sandbox cada lenguaje de programación en esta VM y reduzca la cantidad de acceso que cada idioma tiene al sistema, lo que requiere muchos cambios en los idiomas y la eliminación o reimplementación de muchas características. Mientras que Javascript ya tiene esto en mente, y lo ha hecho durante mucho tiempo.

Tal vez estás buscando el Cliente nativo de Google.

En cierto sentido, tener un lenguaje más expresivo como Javascript en el navegador en lugar de algo más general como Java bytecode ha significado una web más abierta.

Creo que esto es no es tan fácil problema. Podemos decir que estamos atascados con JS, pero ¿es realmente tan malo con jQuery, Prototype, scriptaculous, MooTools y todas las bibliotecas fantásticas?

Recuerde, JS es ligero, aún más con V8, TraceMonkey, SquirrelFish - nuevos motores Javascript utilizados en los navegadores modernos.

También está probado - sí, sabemos que tiene problemas, pero tenemos muchos de estos solucionados, como los primeros problemas de seguridad. Imágenes que permiten su navegador para ejecutar código Ruby, o cualquier otra cosa. La caja de arena de seguridad tendría que hacerse por cero. ¿Y sabes qué? La gente de Python ya falló dos veces.

Creo que Javascript va a ser revisado y mejorado con el tiempo, al igual que HTML y CSS. El proceso puede ser largo, pero no todo es posible en este mundo.

No creo que "entienda el problema pragmático de que JavaScript es simplemente con lo que tenemos que trabajar ahora". En realidad es un lenguaje muy poderoso. Ha tenido su applet Java en el navegador durante años, ¿y dónde está ahora?

De todos modos, no es necesario "ensuciarse" para trabajar en el cliente. Por ejemplo, prueba GWT.

... quieres decir...

Java y applet de Java Flash y Adobe AIR sucesivamente..

En general, cualquier framework RIA puede satisfacer sus necesidades; pero para cada uno hay un precio a pagar por usarlo ( ej. tiempo de ejecución disponible en el navegador o / y propietary o / y menos opciones que pure desktop ) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Para desarrollar Web con cualquier idioma no web, tienes GWT: develop Java, compile to Javascript

Porque todas tienen máquinas virtuales con intérpretes de bytecode ya, y el bytecode también es diferente. {Chakra (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera(Carakan).

Lo siento , creo que Chrome (V8) compila hasta el código de máquina IA32.

IMO, JavaScript, el lenguaje, no es el problema. JavaScript es en realidad un lenguaje bastante expresivo y poderoso. Creo que tiene una mala reputación porque no tiene características clásicas de OO, pero para mí cuanto más voy con el groove prototípico, más me gusta.

El problema como yo lo veo son las implementaciones inconsistentes y escamosas a través de los muchos navegadores que estamos obligados a soportar en la web. Bibliotecas JavaScript como jQuery van un largo camino hacia la mitigación de que sucio sentimiento.

JavaScript es su única opción nativa y estándar disponible. Si quieres mucha potencia, coge jQuery, pero si necesitas hacer un montón más, considera escribir un complemento para Firefox? o similar para IE, etc.