Alternativas a JavaScript


144

Por el momento, el único lenguaje totalmente compatible y el estándar de facto para la manipulación del árbol DOM en el navegador es JavaScript. Parece que tiene problemas de diseño profundos que lo convierten en un campo minado de errores y agujeros de seguridad para el novato.

¿Conoces alguna iniciativa existente o planificada para introducir un lenguaje mejor (rediseñado) de cualquier tipo (no solo JavaScript) para la manipulación del árbol DOM y las solicitudes HTTP en los navegadores de la próxima generación? En caso afirmativo, ¿cuál es la hoja de ruta para su integración en, digamos, Firefox, y en caso negativo, por qué razones (aparte de la interoperabilidad) debería ser JavaScript el único idioma admitido en la plataforma del navegador?

Ya usé jQuery y también leí "javascript: las partes buenas". De hecho, las sugerencias son buenas, pero lo que no puedo entender es: ¿por qué solo JavaScript? En el lado del servidor (su plataforma de sistema operativo favorito), podemos manipular un árbol DOM con cada idioma, incluso para fortran. ¿Por qué el lado del cliente (la plataforma del navegador) solo admite JavaScript?


44
Google Dart, Script #, CoffeeScript, JSX (ambas implementaciones diferentes de JS), JavaScript Harmony, etc. Vea este enlace para más github.com/jashkenas/coffee-script/wiki/…
nawfal

25
Buena pregunta. El lenguaje desarrollado en 10 días todavía está con nosotros en 2013. wtfjs.com
Den

2
"¿por qué solo javascript? En el lado del servidor (su plataforma de sistema operativo favorito), podemos manipular un árbol DOM con cada idioma, incluso para fortran. ¿Por qué el lado del cliente (la plataforma del navegador) solo admite javascript?" en el lado del servidor, puede instalar lo que quiera, pero no puedo obligar a sus clientes a instalar complementos / complementos adicionales, también si tenemos tantos errores y problemas de seguridad con JavaScript, adivine cuántos errores y problemas de seguridad tendríamos si agregamos algunos más?
Peter

66
@Peter No puedo decir si tu argumento es serio o una broma. Es trivialmente fácil para las personas instalar plataformas si lo desean. Si una alternativa a Javascript estuviera disponible y funcionara bien, los proveedores comerciales solo requerirían que los usuarios descarguen lo que sea necesario para ejecutarlo, tal como lo han hecho siempre con Flash, y como lo hicieron durante un tiempo con Silverlight. De todas las razones por las cuales podrían no surgir alternativas en el lado del cliente, la dificultad de garantizar que sus usuarios tengan su plataforma no es una de ellas.
ely

1
@ely: ¿Y resultó bien? ¿Destello? Applets de Java? Silverlight? Ni siquiera tuve una instancia de Silverlight instalada.
Sebastian Mach

Respuestas:


41

El problema con JavaScript no es el lenguaje en sí, es un lenguaje perfectamente prototipado y dinámico. Si vienes de un entorno OO, hay una pequeña curva de aprendizaje, pero no es culpa del idioma.

La mayoría de la gente supone que Javascript es como Java porque tiene una sintaxis similar y un nombre similar, pero en realidad es mucho más parecido a lisp. En realidad, es bastante adecuado para la manipulación DOM.

El verdadero problema es que está compilado por el navegador, y eso significa que funciona de una manera muy diferente dependiendo del cliente.

El DOM real no solo es diferente según el navegador, sino que hay una gran diferencia en el rendimiento y el diseño.


Editar siguiente aclaración en cuestión

Supongamos que se admiten varios idiomas interpretados: aún tiene los mismos problemas. Los distintos navegadores seguirían teniendo errores y tendrían diferentes DOM.

Además, tendría que tener un intérprete integrado en el navegador o instalado de alguna manera como complemento (que podría comprobar antes de publicar la página) para cada idioma. Se necesitaron años para que Javascript fuera consistente.

No puede usar los lenguajes compilados de la misma manera, entonces está introduciendo un ejecutable que no puede ser fácilmente examinado por lo que hace. Muchos usuarios elegirían no dejarlo correr.

Bien, ¿qué pasa con algún tipo de sandbox para el código compilado? Suena como Applets de Java para mí. O ActionScript en Flash. O C # en Silverlight.

¿Qué pasa con algún tipo de estándar IL? Eso tiene más potencial. Desarrolle en el idioma que desee y luego compílelo en IL, que el navegador luego JIT.

Excepto que Javascript ya es una especie de IL, solo mira GWT . Le permite escribir programas en Java, pero distribuirlos como HTML y JS.


Editar después de una aclaración adicional en cuestión

Javascript no es, o más bien no fue, el único idioma admitido por los navegadores: en la era oscura de Internet Explorer, podría elegir entre Javascript o VBScript para ejecutarse en IE. Técnicamente, IE ni siquiera ejecutó Javascript: ejecutó JScript (principalmente para evitar tener que pagarle a Sun por la palabra java , Oracle aún posee el nombre Javascript ).

El problema era que VBScript era propiedad de Microsoft, pero también que no era muy bueno. Mientras Javascript estaba agregando funcionalidad y obteniendo herramientas de depuración de alta velocidad en otros navegadores (como FireBug), VBScript se mantuvo solo en IE y prácticamente no se podía depurar (las herramientas de desarrollo en IE4 / 5/6 no existían). Mientras tanto, VBScript también se expandió para convertirse en una herramienta de script bastante poderosa en el sistema operativo, pero ninguna de esas características estaba disponible en el navegador (y cuando lo fueron se convirtieron en agujeros de seguridad masivos).

Todavía hay algunas aplicaciones internas corporativas que usan VBScript (y algunas dependen de esos agujeros de seguridad), y todavía están ejecutando IE7 (solo detuvieron IE6 porque MS finalmente lo eliminó).

Llevar Javascript a su estado actual ha sido una pesadilla y ha llevado 20 años. Todavía no tiene soporte consistente, con características de lenguaje (especificadas en 1999) que todavía faltan en algunos navegadores y se requieren muchas cuñas.

Agregar un idioma alternativo para interpretar en los navegadores enfrenta dos problemas principales:

  • Lograr que todos los proveedores de navegadores implementen el nuevo estándar de idioma, algo que aún no han logrado para Javascript en 20 años.

  • Un segundo idioma potencialmente diluye el soporte que ya tiene, permitiendo (por ejemplo) que IE tenga un soporte Javascript de segundo nivel pero un gran VBScript (nuevamente). Realmente no quiero escribir código en diferentes idiomas para diferentes navegadores.

Cabe señalar que Javascript no está 'terminado', todavía está evolucionando para mejorar en nuevos navegadores. La última versión está años por delante de las implementaciones de los navegadores y están trabajando en la próxima.


55
Yo diría que es "interpretado", no "compilado" por el navegador.
Flavius ​​Stef

19
Los navegadores más nuevos compilan JIT en JavaScript.
Nosredna

44
También busqué en Google el reclamo de jit y, como resultado, Firefox 3.1 tendrá el soporte incorporado. Visite andreasgal.com/2008/08/22/tracing-the-web o people.mozilla.com/~schrep/ tm-image-ajuste.swf
Flavius ​​Stef

2
El motor V8 JavaScript (Chrome) se compila directamente.
Dave W. Smith

3
Estoy totalmente en desacuerdo con su primera respuesta "el problema con JavaScript no es el lenguaje en sí". Creo que es sintácticamente un lenguaje muy feo y carece de características que obtienes de la mayoría de los otros idiomas. Características que, al menos yo, todavía necesito en aplicaciones grandes (dependencias de carga, principios de OO legibles ). Si tuviéramos que hacerlo (internet) por todas partes, no creo que JavaScript sea la 'mejor' opción para un idioma.
SirLenz0rlot

28

Compilar a Javascript

Por ahora, el uso de un lenguaje que compila a Javascript parece ser la única forma realista de llegar a todas las plataformas mientras se escribe un código más inteligente, y esto probablemente seguirá siendo así durante mucho tiempo. Con cualquier oferta nueva, siempre habrá alguna razón por la cual uno o más proveedores no se apresurarán a enviarla.

(Pero realmente no creo que esto sea un problema. Javascript se ha optimizado muy bien por ahora. El código de la máquina también es inseguro si está escrito a mano, pero funciona bien como un objetivo de compilación y lenguaje de ejecución).

Tantas opciones

Hay un grupo cada vez mayor de idiomas que se compilan a Javascript. Puede encontrar una lista bastante completa aquí:

Notable

Mencionaré algunos que creo que son dignos de mención (aunque sin duda descuido algunas gemas que desconozco):

  • Spider apareció en 2016. Afirma tomar las mejores ideas de Go, Swift, Python, C # y CoffeeScript. No es seguro, pero tiene algunas características menores de seguridad .

  • Elm : Haskell puede ser el lenguaje más inteligente de todos, y Elm es una variante de Haskell para Javascript. Es muy consciente de los tipos y es conciso, y ofrece programación funcional reactiva como una alternativa ordenada a las plantillas reactivas o espaguetis MVC. Pero puede ser un shock para los programadores de procedimientos .

  • Google's Go está dirigido a la concisión, simplicidad y seguridad. El código Go puede ser compilado en Javascript por GopherJS .

  • Dart fue el intento posterior de Google de reemplazar Javascript. Ofrece interfaces y clases abstractas a través de una sintaxis tipo C / Java con escritura opcional.

  • Haxe es como el ActionScript de Flash, pero puede apuntar a varios idiomas para que su código pueda reutilizarse en los programas Java, C, Flash, PHP y Javascript. Ofrece objetos de tipo seguro y dinámicos.

  • Opalang agrega azúcar sintáctico a Javascript para proporcionar acceso directo a la base de datos , continuaciones inteligentes, verificación de tipos y ayuda con la separación cliente / servidor. (Atado a NodeJS y MongoDB.)

  • GorillaScript , "un lenguaje de compilación a JavaScript diseñado para capacitar al usuario mientras intenta evitar algunos errores comunes". es similar a Coffeescript pero más completo, ya que proporciona un montón de características adicionales para aumentar la seguridad y reducir los patrones repetitivos repetitivos.

  • LiteScript cae en algún lugar entre Coffeescript y GorillaScript. Ofrece sintaxis asíncrona / de rendimiento para devoluciones de llamada "en línea" y la comprobación de errores tipográficos variables.

  • TypeScript de Microsoft es un pequeño superconjunto de Javascript que le permite colocar restricciones de tipo en argumentos de función, lo que puede detectar algunos errores. De manera similar, BetterJS le permite aplicar restricciones, pero en Javascript puro, ya sea agregando llamadas adicionales o especificando tipos en los comentarios de JSDoc. Y ahora Facebook ha ofrecido Flow, que además realiza inferencia de tipos.

  • LiveScript es un spin-off de Coffeescript que fue popular por su brevedad, pero no me parece muy legible. Probablemente no sea el mejor para los equipos.

¿Como escoger?

Al elegir un idioma alternativo, hay algunos factores a considerar :

  • Si otros desarrolladores se unen a su proyecto en el futuro, ¿cuánto tiempo les llevará ponerse al día y aprender este idioma, o cuáles son las posibilidades de que ya lo sepan?

  • ¿El lenguaje tiene muy pocas características (el código seguirá lleno de repeticiones) o demasiadas características (tomará mucho tiempo dominarlo y hasta entonces algún código válido puede ser indescifrable)?

  • ¿Tiene las características que necesita para su proyecto? (¿Su proyecto necesita verificación de tipo e interfaces? ¿Necesita continuaciones inteligentes para evitar el infierno de devolución de llamada anidada? ¿Hay mucha reactividad? ¿Podría necesitar apuntar a otros entornos en el futuro?)

El futuro...

Jeff Walker ha escrito una serie de publicaciones de blog que invitan a la reflexión sobre "el problema de Javascript", incluyendo por qué cree que ni TypeScript , ni Dart ni Coffeescript ofrecen soluciones adecuadas. Sugiere algunas características deseables para un lenguaje mejorado en la conclusión .


ES6 extiende Javascript con un conjunto de características que permiten especificar las clases más claramente y "asíncrono en línea" a través de generadores. Sin embargo, todavía se escribe dinámicamente!
joeytwiddle

El enfoque de Elm es similar al Nitrógeno o N2O (marcos erlang) por eso me gusta.
DenisKolodin

Hoy en día tenemos parte del azúcar sintáctico de CoffeeScript en ES8 y TypeScript, así como async-wait. ¡TypeScript ha evitado muchos errores en mi lugar de trabajo, aunque todavía hay algunas oportunidades para sorpresas!
joeytwiddle

También hay Wasm ahora, que permite que se ejecuten varios otros idiomas en el navegador. Sin embargo, la comunicación con el DOM todavía está pasando por JavaScript.
Joeytwiddle

22

¿debería ser JavaScript el único idioma admitido en la plataforma del navegador?

Si y no. Existe una alternativa llamada Dart by Google que compila a JavaScript y, al igual que jQuery, intenta facilitar un poco la manipulación del DOM. Puede ser divertido experimentar, échale un vistazo.

Ver también


15

Es cierto que Javascript fue en un punto notoriamente difícil de manejar, pero la comunidad de desarrollo web ha recorrido un largo camino desde entonces. En cambio, te animo a que eches un vistazo a jQuery . Es fácil y abstrae todos los diversos problemas.

Y realmente no hay alternativas que funcionen en todos los ámbitos. Flash me viene a la mente, pero eso también es un script ECMA y probablemente sea más de matar para la mayoría de las cosas.


1
o MooTools, Prototype y Dojo. jqueryvsmootools.com es una gran comparación entre mootools y jquery.
Ryan Florence

No hay / hubo nada inherentemente incorrecto con Javascript. Es probable que se refiera a problemas en JScript de IE y problemas generales de representación e inconsistencias con varios navegadores.
Gavin

7

A corto plazo, usaría cosas como jQuery para ocultar las incompatibilidades del navegador. A largo plazo, tecnologías como Silverlight o Adobe AIR pueden hacer de este un campo minado muy diferente (pero aún un campo minado) en el futuro.


1
+1 por usar jQuery para ocultar incompatibilidades del navegador. Leí un libro que explica cómo funcionan algunos de esos mecanismos y créanme cuando digo que jQuery está ahorrando dolores de cabeza a los programadores en este departamento.
Vivian River

1
mirar las respuestas tecnológicas en retrospectiva siempre es una visión extraña. ahora sabemos que la web ganó: silverlight, flash y air están todos muertos, y el vencedor restante es javascript en todos sus encantamientos extraños y maravillosos.
oligofren

6

Doug Crockford dio una charla a Google que detalla las partes buenas y malas de JavaScript y su futuro. En realidad, no ha cambiado mucho desde 1999, lo que se puede decir que es algo bueno (casi todos los navegadores pueden ejecutar el mismo código siempre que conozca sus limitaciones) y Doug muestra dónde están las partes buenas fueron en su mayoría malentendidos que resultaron ser muy poderosos.

Para la manipulación DOM, mire a JQuery como una biblioteca del lado del cliente que reemplaza la mayor parte de la horrible API DOM con operaciones que son difíciles de escribir en fragmentos de código bastante elegantes que son más fáciles de escribir.


5

Si está pensando que JavaScript tiene problemas profundos, le recomiendo el libro de Doug Crockford, JavaScript: The Good Parts . (O busque "Crockford JavaScript" en Google para encontrar varias presentaciones de video que ha hecho). Crockford esboza un subconjunto seguro y un conjunto de prácticas, y enumera específicamente algunas partes del lenguaje para evitar.

No estoy al tanto de los planes para reemplazar JavaScript como el medio de facto para manipular el DOM. Así que mejor aprende a usarlo de manera segura y bien.


1
Lea de nuevo. Está claro que editó su pregunta después de leer las respuestas.
Dave W. Smith

4

En términos del lado del cliente, Javascript es la única forma de manipular el DOM. En términos del lado del servidor, hay una multitud de formas.


4

Internet Explorer admite lenguajes de secuencias de comandos conectables, aunque el único incluido de manera confiable con IE además de JScript es VBScript.

Por lo que he visto, parece haber un tipo general de sesgo hacia los lenguajes dinámicos en el navegador, y JavaScript parece satisfacer esta necesidad lo suficiente como para que los efectos de red hagan que cualquier otro idioma no sea un iniciador. El lenguaje es bastante poderoso, aunque su implementación en los navegadores deja mucho que desear.


1
No use VBScript en IE: es una variante horrible de VB que la gran MS pensó que despegaría pero no lo hizo. En realidad, no funciona como VB o VBScript normal, y es más lento que Javascript.
Keith

1
¿Qué falta, por ejemplo, en las implementaciones de JavaScript / ECMAScript de WebKit o Gecko que están disponibles en implementaciones que no son del navegador? Ese comentario es totalmente confuso para mí.
párpado

4

Si está dispuesto a restringir a sus clientes / visitantes a navegadores específicos, y posiblemente esté dispuesto a exigirles que instalen un complemento, puede consultar MS Silverlight : una descripción legible está en wikipedia . Con Silverlight 2, puede ejecutar el código del lado del cliente que ha escrito en C #, IronPython, IronRuby, VB.NET, etc. El clon gratuito de Moonlight de Silverlight, del proyecto Mono, promete traer la misma funcionalidad a Linux.

En la práctica, la mayoría de los desarrolladores de aplicaciones y sitios web prefieren llegar a audiencias más amplias de las que Silverlight (y eventualmente Moonlight) pueden ofrecer actualmente, lo que significa quedarse con Javascript, o posiblemente Flash (que usa un lenguaje de programación similar, Actionscript).

Por lo tanto, obtener una gran cantidad de mentes compartidas, adopción y tracción para cualquier otra cosa está demostrando ser una lucha cuesta arriba incluso para Microsoft con sus grandes grupos de ingenieros y presupuestos de marketing y un proyecto de software libre (para posiblemente aliviar las preocupaciones sobre el bloqueo de propiedad) ), lo que puede ayudar a explicar por qué hay muy poco interés, por ejemplo, por parte de la Fundación Mozilla, en impulsar ese objetivo. "Aparte de la interoperabilidad", usted dice: pero claramente el tema de la interoperabilidad es EL problema aquí, dado lo que observamos en el progreso de Silverlight ...


3

Como ya se dijo, tiene Flash (ActionScript, que es un lenguaje derivado de Javascript) y Silverlight / Moonlight (IronPython, IronRuby, JScript, VBScript, C #) que pueden ejecutarse en el navegador a través de complementos (el primero es mucho más ubicuo) .

También hay otra alternativa si te gusta Ruby: HotRuby , es una implementación de Ruby en JavaScript que se ejecutará en el navegador. Todavía no es muy maduro, pero puedes echarle un vistazo.


3

Algo que no he visto mencionado (oh, veo que Alcides mencionó HotRuby mientras escribía y Nosredna mencionó GWT y Script #) y me gustaría desechar que hay una serie de implementaciones de [insert language] -on- JavaScript (p. Ej., Traductores que le permiten convertir Ruby , Python , C # , Java , Obj-J / Cappuccino [similar a Obj-C / Cocoa] o Processing [for Canvas] a JavaScript en el cliente o antes de la implementación [y algunos de los cuales también cuentan con varias bibliotecas de abstracción] Por supuesto, hay una sobrecarga de rendimiento si se está traduciendo en el cliente, pero si se siente más cómodo con otro idioma, le permitirá cierta flexibilidad.

Sin embargo, personalmente, recomiendo aprender a amar JavaScript. Es un lenguaje excelente, potente y bastante elegante una vez que lo conoces. Me enfrento al dilema opuesto, mordiendo un poco para tener una solución capaz de JavaScript / DOM del lado del servidor que satisfaga todas mis necesidades. / opinión no solicitada


Mencioné GWT y Script #. Para aquellos interesados ​​en Script #, el enlace es projects.nikhilk.net/ScriptSharp
Nosredna

Gracias por señalarme a Obj-J / Cappuccino. Es increíble para crear aplicaciones web y solo lo abrí porque lo mencionaste y el nombre (y la relación con Cocoa) me intrigó.
Timo

2

No. JavaScript lo es, pero evolucionará. La próxima versión es "JavaScript Harmony", y puede obtener más información si lo busca en Google.

De vez en cuando alguien sugiere poner un intérprete de código de bytes en los navegadores junto con JavaScript. Probablemente no sucederá, al menos por un tiempo.

Me encanta JavaScript. Pero hay otras soluciones, incluida GWT, que compila Java a JavaScript y Script #, que compila C # a JavaScript.


2

Jquery (todavía javascript pero) realmente te ayudará a tener soporte para casi todos los navegadores y no es realmente tan difícil de aprender :)


2

JavaScript es el idioma inglés de la web. El inglés se extendió históricamente porque tenía una armada fuerte que conquistó varios países. Esto es comparable a las grandes empresas que conquistaron la web con JavaScript. Es un idioma unido de múltiples fuentes europeas (griego, latín, idiomas germánicos, francés, incluso algunas palabras chinas e indias). JavaScript tomó prestados muchos conceptos a lo largo de los años de otros lenguajes (estructural, OO, funcional). El inglés se habla en diferentes lugares con ligeras variaciones en el dialecto y el acento, lo que puede dificultar la comprensión. Al igual que JavaScript tiene diferentes navegadores que lo interpretan un poco diferente.

Aunque el inglés es fácil de aprender inicialmente, tiene una pronunciación muy inconsistente y más excepciones que reglas. Al igual que JavaScript, siempre está ahí para ofrecer una sorpresa.

A pesar de los diferentes acentos, JavaScript es la lengua franca de la web. Al igual que es posible que no sea inglés y escriba aquí en inglés, cada navegador web tiene un cierto grado de comprensión del inglés. IE6 es como el tipo que dice en su currículum que habla con fluidez, pero solo asistió a un curso de dos semanas sobre inglés como idioma extranjero.

Ha habido intentos de suplantar el inglés como el idioma principal del mundo, por ejemplo, el esperanto. Pero todos fallaron, porque la mayoría de la gente en la tierra habla algo de inglés. Del mismo modo, será difícil introducir mejores alternativas a JavaScript.


1

No creo que Javascript sea reemplazado pronto. Para un enfoque completamente diferente para los clientes ricos, es posible que desee investigar Flex, que es una tecnología basada en Flash.


1

Tal vez algo como haxe (ver haxe.org) podría ayudarte. Es un lenguaje que parece más limpio que JavaScript y puede compilarse en JavaScript, por lo que puede ejecutarse dentro de un navegador.

Sé que esta no es una respuesta directa a su pregunta, pero pensé que podría ser interesante para usted, sin embargo.


1

Mucha gente entiende que Javascript no es el mejor y más bonito lenguaje de todos. Sin embargo, actualmente es compatible con los navegadores, por lo que será extremadamente difícil introducir un idioma diferente. Simplemente no necesitamos otra guerra de navegadores.

Esto explica por qué no conozco ningún plan para cambiar a un idioma diferente del lado del cliente.

Pero creo que Javascript no es tan malo si comienzas a pensar en el modelo DOM y cómo funcionaría con él. Muchas cosas que son complicadas con JS son el resultado de la forma en que funciona el modelo DOM.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.