javascript - tag - title of page html

Alternativas a JavaScript (18)

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

Si y no. Hay una alternativa llamada Dart by Google que compila a JavaScript y al igual que jQuery, intenta hacer la manipulación del DOM un poco más fácil. Puede ser divertido experimentar, verificarlo.

De Google, vea Dart
De Microsoft vea el TypeScript

Ver también

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 los novatos.

¿Conoce 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 próxima generación? En caso afirmativo, ¿cuál es la hoja de ruta para su integración en, digamos, Firefox, y si no, por qué razones (aparte de la interoperabilidad) debería ser JavaScript, el único lenguaje compatible en la plataforma del navegador?

Ya utilicé 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 favorita), podemos manipular un árbol DOM con todos los idiomas, incluso fortran. ¿Por qué el lado del cliente (la plataforma del navegador) solo admite javascript?

Compilar a Javascript

Por ahora, el uso de un lenguaje que se compila en Javascript parece ser la única forma realista de llegar a todas las plataformas mientras se escribe 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 ha sido muy bien optimizado por ahora. El código de la máquina tampoco es seguro si está escrito a mano, pero funciona bien como un objetivo de compilación y lenguaje de ejecución).

Tantas opciones

Hay un conjunto cada vez mayor de idiomas que compilan a Javascript. Una lista bastante completa se puede encontrar aquí:

Lista de idiomas que compilan JS en Coffeescript Wiki

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 de seguridad menores.
Elm : Haskell puede ser el lenguaje más inteligente de todos ellos, y Elm es una variante de Haskell para Javascript. Es altamente sensible al tipo y concisa, y ofrece la Programación Reactiva Funcional como una alternativa limpia a plantillas reactivas o espagueti MVC. Pero puede ser un gran shock para los programadores de procedimientos .
Google Go tiene como objetivo la concisión, la simplicidad y la seguridad. Go code 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 tipeo opcional.
Haxe es como el código ActionScript de Flash, pero puede apuntar a varios idiomas para que su código pueda reutilizarse en programas Java, C, Flash, PHP y Javascript. Ofrece objetos dinámicos y de seguridad de tipo.
Opalang agrega azúcar sintáctico a Javascript para proporcionar acceso directo a la base de datos , continuaciones inteligentes, verificación de tipos y asistencia 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 al intentar evitar algunos errores comunes". es similar a Coffeescript pero más completa, que proporciona un montón de características adicionales para aumentar la seguridad y reducir los patrones repetitivos repetitivos.
LiteScript se encuentra en algún lugar entre Coffeescript y GorillaScript. Ofrece sintaxis asíncrona / rendimiento para devoluciones de llamadas "en línea", y la comprobación de errores tipográficos variables.
El TypeScript de Microsoft es un pequeño superconjunto de Javascript que le permite colocar restricciones de tipo en los argumentos de la función, lo que podría detectar algunos errores. Del BetterJS modo, BetterJS permite aplicar restricciones, pero en JavaScript puro, ya sea mediante la adición de llamadas adicionales o especificando tipos en los comentarios de JSDoc. Y ahora Facebook ha ofrecido Flow que además realiza inferencias tipográficas.
LiveScript es un spin-off de Coffeescript que fue popular por su brevedad pero que no parece muy legible para mí. 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 probabilidades de que ya lo sepan?
¿El lenguaje tiene muy pocas características (el código aún estará lleno de texto repetitivo) o demasiadas características (llevará mucho tiempo dominar, 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 tipos e interfaces? ¿Necesita continuaciones inteligentes para evitar el retorno de llamada anidado? ¿Hay mucha reactividad? ¿Podría necesitar dirigirse a otros entornos en el futuro?)

El futuro...

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

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

Como ya se dijo, tiene Flash (ActionScript, que es un lenguaje derivado de Javascript) y Silverlight / Moonlight (IronPython, IronRuby, JScript, VBScript, C #) que se puede ejecutar 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 está muy maduro, pero puedes echarle un vistazo.

Doug Crockford dio una charla a Google detallando las partes malas y buenas de JavaScript y su futuro. En realidad, no ha cambiado mucho desde 1999, lo que se puede decir que es algo bueno (prácticamente todos los navegadores pueden ejecutar el mismo código siempre que conozcas 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 de DOM, mira a JQuery como una biblioteca del lado del cliente que reemplaza la mayoría de la horrible DOM API con operaciones que son difíciles de escribir en fragmentos de código bastante elegantes que son más fáciles de escribir.

El problema con javascript no es el lenguaje en sí; es un lenguaje perfectamente prototipo y dinámico. Si vienes de un fondo OO, hay un poco de curva de aprendizaje, pero no es culpa del idioma.

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

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

El DOM real no solo depende del navegador, sino que también presenta una gran diferencia en rendimiento y diseño.

Editar la siguiente aclaración en cuestión

Supongamos que se admiten varios idiomas interpretados: todavía tiene los mismos problemas. Los diversos navegadores seguirán teniendo errores y tienen diferentes DOM.

Además, debería tener un intérprete integrado en el navegador o instalado de alguna manera como un complemento (que podría verificar antes de publicar la página) para cada idioma. Nos llevó años conseguir Javascript constante.

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

OK, entonces ¿qué pasa con algún tipo de espacio aislado para el código compilado? Me suena a Applets de Java. O ActionScript en Flash. O C # en Silverlight.

¿Qué pasa con algún tipo de estándar IL? Eso tiene más potencial. Desarrolla en el idioma que quieras y luego compílalo en IL, que el navegador luego JITs.

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

Editar siguiendo más aclaraciones en cuestión

Javascript no es, o mejor dicho no era, el único idioma admitido por los navegadores: en las épocas oscuras de Internet Explorer, se podía elegir entre Javascript o VBScript para ejecutarse en IE. Técnicamente, IE ni siquiera ejecutaba Javascript, ejecutaba JScript (principalmente para evitar tener que pagar a Sun por la palabra java , Oracle aún tenía el nombre de Javascript ).

El problema era que VBScript era propiedad de Microsoft, pero también que simplemente no era muy bueno. Mientras que Javascript estaba agregando funcionalidades y obteniendo herramientas de depuración de alta velocidad en otros navegadores (como FireBug), VBScript permanecía 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 scripting bastante poderosa en el sistema operativo, pero ninguna de esas características estaba disponible en el navegador (y cuando 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 ejecutan IE7 (solo detuvieron IE6 porque MS finalmente lo mató).

Obtener Javascript en su estado actual ha sido una pesadilla y ha tomado 20 años. Todavía no tiene un soporte consistente, con características de lenguaje (especificadas en 1999) aún faltantes en algunos navegadores y se requieren muchas cuñas.

Agregar un idioma alternativo para la interpretación en navegadores enfrenta dos problemas principales:

Conseguir 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 puede diluir el soporte que ya tiene, lo que permite (por ejemplo) que IE tenga soporte de Javascript de segunda, pero excelente 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 los navegadores nuevos. La última versión es años antes que las implementaciones de los navegadores y están trabajando en la próxima.

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

Es cierto que JavaScript en un momento fue notoriamente difícil de tratar, pero la comunidad de desarrollo web ha recorrido un largo camino desde entonces. En cambio, te animo a echar 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 viene a la mente, pero eso también es el guión de ECMA y es probable que sea demasiado para matar a la mayoría de las cosas.

Internet Explorer admite lenguajes de scripts conectables, aunque el único que se incluye de manera fiable con IE además de JScript es VBScript.

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

JavaScript es el idioma inglés de la web. El inglés se extendió históricamente porque tenía una fuerte armada que conquistaba varios países. Esto es comparable a las grandes empresas que conquistaron la web con JavaScript. Es un lenguaje abordado de múltiples fuentes europeas (griego, latín, lenguas germánicas, francés, incluso algunas palabras chinas e indias). JavaScript tomó prestados muchos conceptos de otros idiomas a lo largo de los años (estructural, OO, funcional). El inglés se habla en diferentes lugares con ligeras variaciones en dialecto y acento, que pueden dificultar la comprensión. Al igual que JavaScript tiene diferentes navegadores que lo interpretan de forma 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 seas inglés y escribas aquí en inglés, todos los navegadores web tienen 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 de inglés como lengua extranjera.

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

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

Muchas personas entienden que Javascript no es el mejor y el lenguaje más bello de la historia. Sin embargo, actualmente es compatible con navegadores, por lo que será extremadamente difícil introducir un idioma diferente. Simplemente no necesitamos otra guerra de navegador.

Esto explica por qué no tengo planes de cambiar a un lenguaje diferente del lado del cliente.

Pero creo que Javascript no es tan malo si empiezas a pensar en el modelo DOM y cómo se puede trabajar con él. Muchas cosas que son complicadas con JS son el resultado del modo en que funciona el modelo DOM.

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.

No. JavaScript es, pero evolucionará. La próxima versión es "Armonía de JavaScript", y puede obtener más información si la 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, incluyendo GWT, que compila Java a JavaScript y Script #, que compila C # a JavaScript.

Si está dispuesto a restringir sus clientes / visitantes a navegadores específicos, y posiblemente desee solicitarles que instalen un complemento, puede consultar MS Silverlight : una descripción general legible está en wikipedia . Con Silverlight 2, puede ejecutar, en el lado del cliente, el código que ha escrito en C #, IronPython, IronRuby, VB.NET, etc .; el clon gratuito 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 que 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 participación importante, adopción y tracción para cualquier otra cosa resulta ser una lucha cuesta arriba incluso para Microsoft con sus grandes grupos de ingenieros y presupuestos de marketing y un proyecto de software libre en el lateral (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. "Además de la interoperabilidad", dices: pero claramente el tema de la interoperabilidad es EL mayor problema aquí, dado lo que observamos con respecto al progreso de Silverlight ...

Si estás pensando que JavaScript tiene problemas profundos, te recomiendo el libro de Doug Crockford, JavaScript: The Good Parts . (O Google para "Crockford JavaScript" 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 de manipular el DOM. Así que lo mejor es aprender a usarlo de manera segura y bien.

Tal vez algo como haxe (ver haxe.org) podría ayudarte. Es un lenguaje que parece más limpio que JavaScript y se puede compilar en JavaScript, por lo que se puede ejecutar 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.

Una cosa que no he visto mencionar (oh, veo que Alcides mencionó a HotRuby mientras escribía y Nosredna mencionó GWT y Script #) y me gustaría descartar que haya una serie de implementaciones de [insertar idioma] -en- JavaScript (por ejemplo, traductores que le permiten convertir HotRuby , Python , C# , GWT , Obj-J/Cappuccino [similar a Obj-C / Cocoa] o Processing [for Canvas] a JavaScript en el cliente o antes del despliegue [y algunos de los cuales también presentan 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.

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