¿Por qué nadie ha intentado escribir un mejor idioma como sustituto de JavaScript?

En primer lugar, varias respuestas aquí han preguntado cuál es el problema con JavaScript. Me sorprende que, en estos tiempos, cualquiera haga esa pregunta. Es bastante obvio. Pero para aquellos que han estado viviendo en una cueva, vea la respuesta de Richard Kenneth Eng a ¿Cuáles son las ‘partes malas’ de JavaScript?

Ahora, en cuanto a un sustituto, no hay una razón técnica por la que no se pueda crear un mejor idioma. El problema es político : conseguir que todos los proveedores de navegadores compren en un idioma de reemplazo sería una gran experiencia. Afortunadamente, WebAssembly parece haberse abierto paso. Los amantes de C y C ++ ahora pueden escribir para la web. En un futuro próximo, espere que se admitan idiomas como Kotlin, Python, Ruby y Smalltalk.

Dart y TypeScript han sido intentos recientes. El problema con TypeScript es que todavía es JavaScript debajo de las cubiertas. TypeScript es un superconjunto estricto del lenguaje, por lo que de ninguna manera está protegido del merde que es JavaScript.

En cierto sentido, muchos idiomas superiores han existido durante mucho tiempo como reemplazos: los idiomas transpilados . No me refiero a cosas como Babel. Ver The Super Surrogates of JavaScript.

Usar JavaScript como el “lenguaje ensamblador de la web” es una estrategia perfectamente válida. He usado Amber Smalltalk durante años y rara vez, si alguna vez (no recuerdo), tengo que mirar el código generado, incluso durante la depuración. Esta es exactamente la misma situación cuando utilicé C para la programación de sistemas durante la década de 1990: rara vez, si alguna vez, tuve que mirar el código ensamblador generado.

Se ha probado un superconjunto más simple de JavaScript y es muy popular ==> TypeScript

• JavaScript puede volverse frustrante debido a la falta de tipos fuertes, verificación de tipos estáticos, interfaces limpias, etc.
• Un sustituto de JavaScript es una pregunta difícil, ya que todos los navegadores del mundo y los navegadores incrustados ahora necesitan entender cuál es el nuevo sustituto.
• En cambio, Microsoft (Anders Hejlsberg y su equipo) desarrollaron una abstracción auxiliar sobre JavaScript llamada TypeScript.
• Se compila en JavaScript limpio.
• TypeScript tiene comprobación de tipo, interfaces y admite ECMAScript 3 y superior.
• Tenga en cuenta que JavaScript es un lenguaje muy agradable en un contexto dado. Pero si no le gustan algunos aspectos y necesita más previsibilidad, entonces TypeScript es un buen punto de partida.
• Además, aunque no es un sustituto, han surgido muchos marcos de clientes como AngularJS, React, Ember.js, etc., que intentan salvarlo de la desagradable manipulación directa del DOM y la gestión del estado del navegador.
• Con esos marcos y TypeScript, puede aliviar algunos de los puntos débiles de JavaScript.

ps Por cierto, muchos programadores adoran JavaScript. Entonces no es tan malo como piensas. Al menos para algunos.

En realidad, hay cientos de reemplazos de JavaScript en la actualidad. En serio, no son difíciles de encontrar.

Básicamente, todos y su hermano ya han escrito un lenguaje que se compila en JavaScript y se ejecuta en máquinas virtuales JS como V8 y similares. En este punto, incluso las futuras versiones de JS se compilan en JS hasta que las máquinas virtuales puedan ejecutarlas de forma nativa.

Nunca ha sido un problema que no haya algo que pueda reemplazar y mejorar JS. Es más el tema de la adopción. JavaScript es sorprendente por el hecho de que está en todas partes y casi cualquier persona puede recuperarlo rápidamente.

Casi todo lo que intenta reemplazar a JS falla en una de esas dos áreas.

Es como tratar de reemplazar la música pop con el death metal o la orquesta sinfónica clásica. Para un pequeño grupo de personas, podría ser mejor o más puro que la música pop, pero todos escuchan música pop (lo quieran o no).

JavaScript en este punto es música pop. No desaparecerá, todos lo usan y lo disfrutan, así que ¿por qué luchar contra él?

Además, con los lenguajes que compilan a JS, puedes usar el que más te guste y seguir ejecutándolo en JS, así que está bien.

-Brian

PD: También podrías disfrutar de mi otro escrito …

Se inventaron muchas pilas web para otro lenguaje o marco front-end; Sin embargo, nadie realmente tuvo éxito:

• VBScript (retirado)
• Java Applet (retirado)
• ActiveX (heredado y peligroso)
• Flash (casi retirado)
• Silverlight (retirado)
• CoffeeScript (desvaneciéndose)
• Dart (bien diseñado pero no popular)
• TypeScript (un popular compilador de JavaScript)
• Babel (otro transcompilador de JavaScript)
• Web Assembly (¿nueva esperanza ?, todavía en avance tecnológico)

La tecnología web está demasiado arraigada debido a problemas tanto tecnológicos como políticos. Ningún gigante tecnológico quiere perder el control en este campo de batalla; por lo tanto, la tecnología exclusiva de una compañía no es políticamente correcta. Parece que todos los gigantes aceptan felizmente JavaScript, la lengua franca de la Web. Web Assembly puede promover una Web mejor y más segura, pero tenemos que esperar un tiempo.

Personalmente, escribo JavaScript solo para front-end, principalmente manipulaciones DOM simples, dibujo HTML Canvas, validación de formularios web, etc. por jQuery. Si necesito escribir algunas bibliotecas en JavaScript, me referiré a TypeScript (o Babel). Todavía lucho con los marcos frontales. Cuando esté en otro campo, evitaré las pilas de JavaScript cuando sea posible.

Obviamente, no sabes mucho sobre JavaScript, pero esto claramente no te impide tener una opinión sólida sobre él. Los programadores que son buenos en JavaScript pueden escribir un código increíblemente efectivo usando esa basura. Es posible que desee considerar cómo formula sus preguntas en el futuro porque, francamente, suena como un … Bueno, mantendré mis modales.

Aunque no pertenezca al grupo de programadores que conoce JavaScript de manera significativa, su deseo se ha otorgado en forma de WebAssembly. Ahora puede escribir C o C ++ y, eventualmente, cualquier otro lenguaje que le interese, siempre que pueda compilar el código en WebAssembly. Luego se ejecutará en el navegador a algo parecido a las velocidades nativas. Sospecho que LLVM eventualmente producirá trivialmente la salida de WebAssembly, momento en el que puede escribir el código del navegador en casi todos los idiomas razonablemente populares que existen. Por ahora, debe consultar la Guía del desarrollador (utiliza esto: Principal – documentación de Emscripten 1.37.10) y ver si eso puede ser más lo suyo.

¿Por qué nadie ha intentado escribir un mejor idioma como sustituto de JavaScript?

Creo que un lenguaje de programación debe cumplir los requisitos del problema y la solución. Por lo tanto, la pregunta no puede sostenerse sin este contexto.

Hay muchos lenguajes de programación que se transcodifican a JavaScript o se ejecutan dentro de JavaScript (por ejemplo, Amber Smalltalk o jeForth).

El problema con los lenguajes de programación en general es que intentan resolver cualquier problema en lugar del problema específico (actual). Entonces, después de seleccionar un idioma apropiado, uno tiene que vivir con el lado oscuro de ese idioma también. Esta es la razón por la cual la pregunta anterior siempre es cierta para cualquier lenguaje de programación siempre que no cumpla con todos los requisitos.

La única solución es construir un DSL.

He tocado algunos lenguajes de programación durante mis estudios de informática: C ++ y Java (J2SE / J2EE) y más tarde durante mi carrera: C #

Pero realmente me encantó desarrollar aplicaciones web durante mis estudios, así que me concentré en el desarrollo web front-end en JavaScript 1.5 + xhtml 1.0, xml 1.0, CSS y DOM y desarrollo web completo en W / LAMP (Windows / Linux, Apache, MySQL y PHP 4.2).

Entonces me gustó mucho JavaScript y hubiera preferido usar el mismo lenguaje del lado del cliente y del lado del servidor, pero en ese momento (principios de 2000) no había ningún marco / tecnología de JavaScript del lado del servidor real disponible.
Aunque había creado varias aplicaciones web como Desarrollo Web Full Stack en WIISJ (Windows, IIS, SQL Server y JScript 5.6), no era una pila de tecnología viable para una carrera de tiempo completo.
JScript es JavaScript por cierto, solo la versión de Microsoft que podría ejecutarse en el lado del servidor.

Mi carrera en TI se convirtió en pruebas de software después de la universidad, por lo que la programación ya no se realizó. Pasé por todas las etapas desde el ingeniero de pruebas, pasando por el analista de pruebas hasta el gerente de pruebas.
Ahora, comenzando de nuevo con la automatización de pruebas, he redescubierto (vainilla) JavaScript nuevamente y comencé a aprender Desarrollo Web MEAN completo para aprender Node.js.
No tengo ninguna ambición de convertirme en un desarrollador de aplicaciones, porque me encanta probar demasiado, pero (vanilla) javascript, Node.js y Cucumber.js se utilizan como / el lenguaje de secuencias de comandos predeterminado en varias herramientas de automatización de pruebas.

JavaScript se mejora constantemente, así que eso es bueno. También existe TypeScript y CoffeeScript, que son buenos, pero si tiene una buena comprensión de la programación y trabaja metódicamente, no son realmente necesarios.
Si no tiene una buena comprensión de la programación y / o no trabaja metódicamente, creará un código feo en cualquier otro lenguaje de programación.
Al final, todo se reduce al desarrollador y no al lenguaje de programación.

Me gustaría compartir con ustedes una increíble charla de Gary Bernhardt de Pycon 2014. Habla sobre la historia de Javascript, que explica mucho por qué aspectos de su popularidad a pesar de algunas deficiencias bastante increíbles. También habla sobre el futuro de Javascript, que es esencialmente una respuesta a esta pregunta, pero no es lo que esperarías porque es realmente inteligente y técnicamente brillante.

Por favor revisa esta charla esclarecedora:

El nacimiento y la muerte de JavaScript

https://destroyallsoftware-talks.s3.amazonaws.com/the-birth-and-death-of-javascript.mp4

Bueno, tengo una relación de amor y odio con JavaScript.

No diré que es el mejor idioma; pero sí, la gente se ve obligada a usarlo en algunos casos.

El mundo real no funciona en casos ideales. Idealmente, debería haber sido reemplazado hace mucho tiempo, pero aquí estamos.

Google había intentado hacer lo que le pediste, pero el esfuerzo fracasó porque el esfuerzo de migrar es mucho más que continuar con él; incluso con migración incremental.

Pero no diré que es una porquería porque las cosas funcionan y funcionan muy bien.

Y para crear sitios web, no está obligado explícitamente a escribir código en JavaScript. Puede codificar su sitio web en un lenguaje completamente diferente que genere o transpile a JavaScript.

Tengo una pregunta para ti: ¿qué parte de JavaScript odias tanto?

JS tiene una mala reputación entre las personas que no conocen las soluciones para las partes malas.
Pasan por alto las partes prácticas y decentes.
La API DOM está mejorando rápidamente, ES6 está disponible, solucionó muchos problemas. JQuery para una implementación rápida compatible con varios navegadores. Angular, React, VueJS, los navegadores en sí mismos han mejorado enormemente.

¿Sabes quién trató de capturar el navegador también? Java, busque el historial de applets y cómo funcionó 🙂

Otros lenguajes tienen sus propias trampas, consulte la documentación de PHP, pero ¿hace que PHP sea inútil?

Lea esto, esto es muy bueno:

Pensamientos de un programador C / C ++ después de años en JavaScript

Google Dart fue un proyecto para ser incorporado en el proyecto de Chrome. Algunos dicen que hoy se usa bastante internamente en Google junto con Angular.

El cambio más destacado en estos días es el ensamblaje web como objetivo del compilador. Sería irrelevante qué idioma escribes, ya que el objetivo será el navegador. El ensamblaje web tiene acceso a la API del navegador, por lo que es cuestión de tiempo hasta que todo vuelva a cambiar.

También es interesante echar un vistazo a Kotlin, que también es un buen reemplazo para Java. Kotlin ahora también compila a JavaScript.

JavaScript es fácil de aprender, fácil de escribir.

Necesitas saber cómo usarlo.

Pero js es uno de los mejores idiomas. Es ligero, rápido y muy dinámico.

Js nunca ha sido diseñado para ser utilizado como Java.

Los últimos esfuerzos con clases y constantes son solo para atraer a más programadores. Pero en mi opinión, esto es lo peor en js, tratando de emular otros idiomas.

Js es dinámico, ¡esta es la forma en que debería usarse!

La ayuda de devolución de llamada se debe a que los desarrolladores prefieren escribir devoluciones de llamada.

Pero también deberían ofrecer alternativas.

Yo sí, así que tu conjetura es errónea. Bueno, omití bastantes cosas en mi respuesta hasta ahora. Cuando aludí que he escrito un lenguaje mejor que JS, ¿qué significa exactamente mejor? Mi suposición errónea es; ‘mejor’ implica tener un sistema más fuertemente tipado y no tener el defecto de alcance variable global. Diré humildemente que mi lenguaje sustituto es magnitudes más expresivas y apetecibles de usar. De hecho, se parece un poco a un lenguaje oscuro llamado Dart que fue iniciado por Google en 2010 para repensar el diseño de un lenguaje web y crear un lenguaje alternativo para usar en los navegadores web.

También soy vagamente consciente de que otra gran corporación, ‘Microsoft’, ha creado un lenguaje llamado Typecript para abordar las limitaciones de JS y posiblemente para reemplazar a JS. Con mis habilidades de Google algo limitadas pude sacar algunos enlaces.

TypeScript: el reemplazo de Microsoft para JavaScript

¿Podría TypeScript ser el futuro de JavaScript?

¿Dart de Google en el blanco para reemplazar JavaScript? Ese será el día

Incluso encontré algunas preguntas anteriores sobre Quora. Preguntas como “¿Podría Dart reemplazar a JavaScript?” Me pregunto cuánto esfuerzo ha hecho antes de hacer esta pregunta en Quora. ¿Hay alguna razón específica por la que hizo esta pregunta, a pesar de que su premisa defectuosa podría establecerse fácilmente, haciendo una búsqueda muy básica y preliminar en Internet? Me rasco la cabeza ante el esfuerzo que se hace para responder preguntas tan mundanas en este medio.

Microsoft lo hizo hace 20 años impares, con VBScript. Pero para una adopción amplia, todos los navegadores tendrían que soportarlo, y no lo hacen y nunca lo harán.

Google podría haber complementado JavaScript con algún otro idioma por ahora, considerando que proporcionan el navegador más utilizado. Hasta ahora no lo han hecho, sino que se han centrado en mejorar JavaScript “desde el costado” a través de Angular, etc.

Las implementaciones de JavaScript son muy eficientes, a pesar de que JavaScript se escribe dinámicamente. Además, hay muchos marcos, bibliotecas de código, código de muestra, CMS, etc. que dependen de JavaScript, por lo que no desaparecerá rápidamente.

Es probable que WebAssembly cambie eso con el tiempo, pero para la mayoría del procesamiento del lado del cliente, JavaScript junto con un buen marco están perfectamente bien.

Ok, no vayamos por ahí golpeando los idiomas. El origen de JavaScript es muy interesante. También es extremadamente fácil de usar y frustrante a veces. Empresas como Google han intentado reemplazarlo con alternativas como Dart. ¡El mundo entero está demasiado invertido en JavaScript para migrar a un idioma diferente! Con Node.js popularizándolo en el backend, se ha vuelto extremadamente popular entre los ingenieros. No requiere que aprendas dos idiomas para crear aplicaciones web. Entonces, aunque alguien pueda intentarlo en el futuro, a partir de ahora JavaScript está aquí para quedarse.

Es muy difícil lograr que todos los proveedores de navegadores participen para implementar un nuevo estándar de idioma que apunte al navegador.

Hay algo llamado WebAssembly en las obras. Es posible que desee leer más al respecto:

¿Cuál es el futuro de WebAssembly?

Los idiomas mejores que JavaScript son fáciles de encontrar, si desea una lista, consulte los 50 idiomas principales en TIOBE.

El problema es que todos comenzaríamos a usar el idioma y ningún navegador lo admite.

No existe un deseo ardiente en la industria de reemplazar JavaScript (si es lo suficientemente bueno como para mostrarle algunos anuncios, está bien), por lo que tenemos que esperar a que las ruedas lentas giren cuando WebAssembly despegue.

Reemplazar técnicamente JavaScript no es un problema, el problema es lograr que todos los grandes jugadores estén de acuerdo en algo que no beneficiará sus resultados.

¡Me encanta!

La popularidad de NodeJS demuestra que las personas prefieren JS a otros lenguajes “mejores”.

Hay alternativas, pero nunca se dieron cuenta porque la gente ama tanto a JS.

Por favor, no seas una uva agria.

La ironía es que solía realizar una pasantía en una empresa donde a todos los ingenieros superiores les encantaría usar JavaScript. Su front-end está construido con GWT (Java). Crucé de Java a la tierra de JavaScript a través del puente ActionScript, y nunca miré hacia atrás.

Sí, pero hay demasiados intereses económicos en JavaScript para que esto suceda.

El problema es que incluso si finalmente logramos deshacernos de él (lo que sería IMPRESIONANTE) los navegadores aún tendrían que admitirlo porque no todos los desarrolladores seguirían adelante y usarían lo que sea más nuevo.

Je