¿Qué haría falta para que otro idioma destrone a JavaScript como la lengua franca de la web?

Sospecho que se necesitaría un problema comercial importante que no se puede resolver fácilmente con Javascript, pero que podría resolverse con un nuevo lenguaje … O una gran cantidad de publicidad sobre alguna nueva invención de la rueda.

Tomemos el ejemplo del desarrollo multiplataforma. A principios de los años 90, si deseaba escribir una aplicación para Windows y para Mac, generalmente programaba en un lenguaje (probablemente C o C ++) en una plataforma, pero tenía que tener diferentes versiones para admitir diferentes arquitecturas (por ejemplo, 68000 o PowerPC o Intel, big-endian, little-endian), diferentes GUI del sistema operativo, por ejemplo, MacOS vs Windows. Esto fue muy costoso.

A lo largo viene Java con su apodo de “Escribir una vez, ejecutar en cualquier lugar” que prometía que solo tenía que codificarlo una vez en cualquier plataforma y que se ejecutaría en cualquier lugar donde hubiera un JavaVM. Ahora, si está de acuerdo en que fue 100% exitoso o no en ese sentido, es una historia diferente, pero a los empresarios (que generalmente no tienen idea de la programación) les encantó la idea: redujo significativamente los costos de desarrollo multiplataforma … o movió los costos 😉 a por lo menos

Avanzar a Javascript. ¿Qué problema relacionado con el costo no puede resolver Javascript o qué costo agrega JavaScript innecesariamente? No hay muchos, si alguno, que los contadores de frijoles puedan entender claramente. A muchas personas no les gusta Javascript (incluido yo mismo) pero puedo asegurarles que a muy pocos empresarios les importa si a los técnicos les gusta o no les gusta algo …

Por la gran cantidad de cosas exageradas … bueno, tal vez así es como se interrumpirá … … Hay tanta basura en la industria del software donde las personas reinventan la rueda una y otra vez y si pueden exagerar su “nuevo brillo” idea brillante “, ganarán mucho dinero …

Así que hagamos una nueva rueda y exageremos muchísimo … pero asegúrese de que parezca que va a ahorrar dinero o generar dinero …

El proceso ya ha empezado.

Primero, teníamos transpiladores, por lo que podemos codificar nuestras aplicaciones en lenguajes diseñados adecuadamente como TypeScript.

TypeScript se transpira a JavaScript, que es el lenguaje de nivel más bajo por el cual la mayoría de los navegadores le permiten expresar operaciones. En teoría, sin embargo, cualquier lenguaje puede compilarse en JavaScript: por ejemplo, Java puede compilarse para su ejecución en el navegador usando GWT.

Pero no más

¡WebAssembly ahora nos da un formato de nivel mucho más bajo que podemos compilar! Veremos TypeScript, C #, Java y muchos otros lenguajes compilados en WA.

¿Qué significa esto en el contexto de su pregunta? Significa que el lenguaje de programación se vuelve irrelevante . No me importa en qué idioma se escribió Bioshock o qué idioma se utilizó para desarrollar la matemática. Todos se envían como ejecutables empaquetados que se ejecutan en mi máquina.

Así será cuando WA tenga un amplio apoyo. Las aplicaciones web serán más rápidas y se escribirán en una gran cantidad de lenguajes de programación diferentes. Los componentes se desarrollarán en C # y se empaquetarán en WA, y la gente que codifique a WA en Scala podrá usarlos, porque el tiempo de ejecución subyacente será universal.

Por amplio apoyo, por supuesto, quiero decir:

• Los IDE y los editores admiten cadenas de herramientas WA completas
• Las herramientas de depuración y los mapas de código están disponibles para la depuración en tiempo de ejecución
• Hay marcos de alta calidad disponibles, con buenos ejemplos y documentación.
• Alto compromiso de la comunidad para impulsar todo lo anterior
• Todos los principales navegadores en plataformas de escritorio y móviles son compatibles con WA
• Idealmente, fuertes puentes de interoperabilidad entre el ecosistema JS existente y el nuevo ecosistema WA para apoyar migraciones limpias. Por ejemplo, la capacidad de desarrollar sin problemas aplicaciones reactivas / angulares que usan componentes WA, y lo inverso: la capacidad de desarrollar aplicaciones WA que hacen uso de marcos y componentes JS populares, como D3, por ejemplo.

Noam Ben-Ami tiene razón, ya lo estamos viendo. De cualquier modo eso espero.

Hay dos partes en este problema, técnicas y actitudes.

WebAssembly es la respuesta técnica, pero no va a cambiar las actitudes, será un problema mucho más difícil.

Los programadores de front-end han crecido con JS, y sobre todo nada más, es difícil venderlos para que cambien, ¿por qué deberían hacerlo? Han manejado tanto tiempo con JS, probablemente son muy expertos en ello, entonces, ¿por qué cambiar algo que funciona?

Claro, JS apesta, pero hace el trabajo. Windows 3.1 / 95/98 / ME / XP todos apestaron, pero hicieron el trabajo, y esto, no se pudo mover desde una posición dominante.

Los malos idiomas siempre han existido, y continúan existiendo. Ser mejor en realidad no es tanto un argumento de venta como creemos que es.

Proporcionar WebAssembly es la parte técnica de la ecuación, la otra parte se quedará por mucho tiempo.

Gracias por la A2A

Creo que sería algo enorme.

La adopción masiva de JavaScript se produjo mediante la agrupación, no por la elección. Todos los navegadores admitían JavaScript, y nada más.

El DOM sucedió, lo que significa que podría controlar las interacciones del lado del cliente. XMLHttpRequest (AJAX; XHR) sucedió, lo que significa que podría usar JavaScript para hablar con el servidor. Nodo sucedió para que este servidor en sí mismo pudiera escribirse usando JavaScript. JSON se convirtió en una opción obvia para transferir datos.

En este punto, tiene muchas herramientas para escribir aplicaciones web, en el navegador y en el servidor.

Entonces, ¿qué tomaría esto para cambiar?

• Una forma de continuar usando JavaScript en el navegador, para admitir aplicaciones existentes
• Una forma de ejecutar los nuevos idiomas en el navegador, agrupados
• Algún interés de los desarrolladores sobre esto (nb: ¡cuenta conmigo!)
• Ecosistema decente de bibliotecas, tutoriales, herramientas en torno a los nuevos idiomas.
• Algún “dispositivo asesino” (o aplicación) que apresuró el cambio en el uso del consumidor

Y todo esto debe ser compatible con los estándares web existentes.

Por lo tanto, será un pequeño cambio incremental (como los transpiladores en la actualidad, tal vez WebAssembly o alguna otra idea de VM, que tenga éxito donde la JVM de Java falló), o algo catastrófico. Al igual que la web se descarta por razones políticas, y se reemplaza con algo equivalente pero igual.

Me parece bastante improbable.

Cara triste.

Supongo que nada dura para siempre … pero JavaScript puede contrarrestar esa tendencia. Web Assembly, como otros han mencionado, va a cambiar la web. Dicho esto, no veo que reemplace JavaScript como la lengua franca en el corto plazo. JavaScript es bueno en lo que hace, que es interactuar con el DOM de una manera basada en eventos.

Para que un lenguaje reemplace JavaScript, tendría que hacer todo lo que JavaScript hace, sin aumentar la barrera de entrada y con grandes aumentos de rendimiento o con una escalabilidad más empresarial. Este lenguaje maravilloso necesitaría un cuerpo de estándares neutral y una aceptación universal o casi universal de todos los principales fabricantes de navegadores.

Es una tarea difícil. Puede suceder algún día, pero no estoy de acuerdo con quienes dicen que el proceso ya ha comenzado. No veo ninguna evidencia de eso. Por ahora y en el futuro previsible (unos cinco años en tecnología) JavaScript es rey, reina y bufón.

Tenga en cuenta que esto solo se aplica a JavaScript del lado del cliente. El destino de JavaScript en el servidor está mucho más abierto al debate.

Tomaría más de lo que es probable que suceda. Incluso como la lengua franca del desarrollo front-end, no fue hasta hace poco (con el advenimiento de jQuery y otros frameworks front-end) que finalmente tuvimos una capa razonablemente abstracta para codificar, en lugar de tener que escribir soluciones complicadas para cubrir las múltiples implementaciones de JavaScript por varios navegadores, en sus diversas versiones, en sus diversas plataformas.

Incluso hoy, hay problemas. La prueba aún se requiere. Edge no ha hecho nada más fácil. He estado creando páginas web desde la década de 1990. Los principales navegadores han cambiado con el tiempo y la plataforma (si se piensa en ellos colectivamente) está menos fragmentada hoy de lo que estaba entonces. Pero sigue siendo un espacio disputado. Y los creadores de los principales navegadores no están de acuerdo con cada estándar, ahora que tenemos estándares, lo cual es excelente, y mucho menos cómo implementarlo. No espero que empiecen a cantar la misma melodía. Mientras la plataforma sea lo que es, un espacio controlado por múltiples y poderosas compañías, habrá inconsistencias que requerirán capas de abstracción y soluciones alternativas.

Hoy, puede codificar su interfaz en una miríada de idiomas que pueden compilarse a JavaScript. Aquellos que no se preocupan por la sintaxis de JavaScript pueden escribir en casi cualquier idioma que deseen y obtener los mismos efectos. Personalmente, estoy tan contento con JavaScript que no he pasado mucho tiempo explorando estas opciones, pero es bueno tenerlas. JavaScript no es el lenguaje más elegante, tampoco es el lenguaje horrible que a menudo crean algunos desarrolladores. Yo, por mi parte, doy la bienvenida a nuestros señores de JavaScript.

Pudo haber sucedido en 2010.

Es casi imposible ahora. De hecho, JavaScript se usa tanto en aplicaciones web de clientes, scripts del lado del servidor, aplicaciones de escritorio, aplicaciones de Android, y tanto que no va a cambiar en el corto plazo.

Piense en ello como “INGLÉS” pero para la web.

• La dirección de Brandon Eich circa 1994
• Un cuchillo
• Una maquina del tiempo

Dicho esto, WebAssembly existirá en algún momento y luego las personas pueden usar lenguajes distintos al JavaScript para fines de desarrollo web, poco después los desarrolladores se darán cuenta de que sus lenguajes favoritos son igualmente terribles para el desarrollo web y comenzarán a atacar a los navegadores como objetivos para cualquier tipo de desarrollo. .

Hay lenguaje de programación Perl. Las personas que inventan Perl6 tienen el siguiente proyecto: Ian Hague Solicitud de subvención Perl 6: backend JavaScript para Rakudo

¿Y con esto te refieres a los idiomas front-end?

Para que los navegadores lo acepten … son extremadamente lentos para actualizar incluso las funciones básicas.

Muchos idiomas se transfieren a JS, por lo que no siempre necesita escribirlo.