153 votos

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

¿No tendría sentido el apoyo de un conjunto de lenguajes (Java, Python, Ruby, etc.) por medio de un estándar de máquina virtual alojado en el navegador en lugar de requerir el uso de un lenguaje especializado, realmente, especializado paradigma-para el cliente de secuencias de comandos sólo?

Para aclarar la propuesta, una página web podría contener código de bytes en lugar de cualquier lenguaje de alto nivel como JavaScript.

Entiendo que la pragmática de la realidad que JavaScript es simplemente lo que tenemos ahora, debido a la evolución razones, pero estoy pensando más en el largo plazo. Con respecto a la compatibilidad con versiones anteriores, no hay ninguna razón por la que en línea de JavaScript no podía ser al mismo tiempo apoyado por un período de tiempo y, por supuesto, JavaScript podría ser uno de los idiomas soportados por el navegador de la máquina virtual.

25voto

Adam Wright Puntos 31715

Bueno, sí. Sin duda, si tuviera una máquina del tiempo, volver atrás y asegurando una gran cantidad de Javascript características se han diseñado de manera diferente sería un pasatiempo importante (que, y garantizar la gente que diseñó es decir CSS del motor nunca entró en ELLA). Pero eso no va a suceder, y seguimos con los de ahora.

Sospecho que, en el tiempo, se convertirá en el "lenguaje de Máquina" de la web, con otros de mejor diseñado lenguajes y APIs de compilación abajo (y frente a las diferentes motor de tiempo de ejecución de debilidades).

No creo, sin embargo, ninguna de estas "mejor diseñado idiomas" será Java, Python o Ruby. Javascript es, a pesar de la capacidad para ser utilizada en otro lugar, una aplicación Web lenguaje de secuencias de comandos. Dado que el caso de uso, se puede hacer mejor que cualquiera de esos idiomas.

19voto

the happy moron Puntos 473

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

En la actualidad el más cercano cosas tenemos a una multi-idioma de la VM son la JVM y el CLR. Estos no son exactamente ligero bestias, y no tendría sentido tratar e incorporar algo de este tamaño y complejidad en un navegador.

Vamos a examinar la idea de que podría escribir una nueva, multilenguaje VM que sería mejor que la solución actual.

  • Usted está atrasado en la estabilidad.
  • Estás detrás de la complejidad (modo, manera, detrás porque estás tratando de generalizar a través de múltiples idiomas)
  • Usted está atrasado en adopción

Así que no, no tiene sentido.

Recuerde, con el fin de apoyar estas lenguas se va a tener que tira hacia abajo de sus APIs algo feroz, picar a cabo alguna de las partes que no tienen sentido en el contexto de un navegador de secuencia de comandos. Hay un gran número de decisiones de diseño que se debe de hacer, y una gran oportunidad para el error.

En términos de funcionalidad, estamos probablemente sólo realmente trabajar con el DOM de todos modos, así que esto es realmente un problema de la sintaxis y el lenguaje idom, momento en el que tiene sentido la pregunta, "¿Es esto realmente la pena?"

Teniendo en cuenta, la única cosa de la que estamos hablando es de scripting del lado del cliente, porque el lado del servidor de secuencias de comandos ya está disponible en el idioma que usted desee. Es un relativamente pequeño de programación de arena y por lo tanto el beneficio de la integración de múltiples idiomas en es cuestionable.

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

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

Llevar en un lenguaje como Java no tiene sentido, porque lo mejor de todo es la Api de todos modos.

Llevar en un lenguaje como el Rubí o Lisp no tiene sentido debido a que JavaScript es un potente lenguaje dinámico muy cerca de Esquema.

Por último, ¿qué navegador maker realmente quiere el apoyo de la DOM de integración para varios idiomas? Cada aplicación tiene sus propios errores específicos. Ya hemos caminado a través del fuego para tratar con las diferencias entre MS Javascript y Mozilla Javascript y ahora queremos multiplicar que el dolor de los cinco o seis veces?

No tiene sentido.

17voto

Manuel Ceron Puntos 3568

Creo que JavaScript es un buen lenguaje, pero me encantaría tener una opción cuando el desarrollo del lado del cliente de las aplicaciones web. Por motivos de compatibilidad, estamos atascados con JavaScript, pero hay ideas y proyectos que buscan cambiar ese escenario:

  1. Google Native Client: tecnología para la ejecución de código nativo en el navegador.
  2. Emscripten: LLVM compilador de bytecode a código javascript. Permite LLVM idiomas para ejecutarse 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 vamos a tener JavaScript para mucho tiempo, pero eso va a cambiar tarde o temprano. Hay tantos desarrolladores dispuestos a la utilización de otras lenguas en el navegador.

13voto

bobince Puntos 270740

En Windows, usted puede registrar otros idiomas con el Host de secuencias de comandos y tenerlos disponibles para IE. Por ejemplo VBScript es apoyado fuera de la caja (a pesar de que nunca ha ganado mucha popularidad como lo es para la mayoría de los propósitos, incluso peor que la de JavaScript).

El Python win32 extensiones permitió agregar Python para IE como este con bastante facilidad, pero no era realmente una buena idea de como Python es bastante difícil sandbox: muchas de las características del lenguaje de exponer lo suficientemente aplicación ganchos para permitir una supuestamente-aplicación restringida para salir.

Es un problema en general, que los más de complejidad que se agrega a una red orientada aplicación, como el navegador, la mayor probabilidad de problemas de seguridad. Un montón de nuevos lenguajes sin duda se ajusta a esa descripción, y estos son los nuevos lenguajes que todavía están en rápido desarrollo.

JavaScript es un feas, pero a través de un cuidadoso uso de un selectiva subconjunto de características, y ayuda de objeto adecuado de las bibliotecas, por lo general puede ser bastante tolerable. Parece incremental, práctico adiciones a JavaScript son la única forma de secuencias de comandos web es probable que se mueva.

9voto

Brian Reindel Puntos 6416

Si usted se siente como usted está ensuciarse las manos, luego de haber sido lavado el cerebro, o aún están sintiendo el después de los efectos de la "DHTML años". JavaScript es muy potente, y se adapta bien para su propósito, que es a la secuencia de comandos de interactividad 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 los aspectos de los lenguajes del lado servidor. JavaScript está bien como un lenguaje basado en prototipos, sin ser completo orientado a objetos.

Si hay una falta de fluidez de las aplicaciones debido a que el lado del servidor y del lado del cliente no se están comunicando, entonces usted puede desear reconsiderar cómo el arquitecto de sus aplicaciones. He trabajado con muy robusta de los sitios Web y las aplicaciones Web, y nunca me dijo una vez, "Hmm, yo realmente deseo JavaScript podría hacer (xyz)." Si se pudiera hacer eso, entonces no sería JavaScript -- sería ActionScript o AIRE o Silverlight. Yo no necesito eso, y tampoco la mayoría de los desarrolladores. Son buenas tecnologías, pero que intenta resolver un problema con una tecnología, no es una... bueno, una solución.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X