Design: Webasm puede reemplazar Javascript en el navegador?

No estoy lo suficientemente familiarizado con c #, pero en realidad, creo que wasm no puede hacerse cargo de javascript por completo.

Primero, si lo ha intentado, encontrará que javascript es mucho más rápido que wasm en algunas operaciones de nivel inferior, como "+, -, *, /" y algunas otras operaciones relacionadas con las matemáticas debido a la ligera sobrecarga al llamar desde JavaScript. en WebAssembly y viceversa. N.º 1120

En segundo lugar, para los desarrolladores web, que ya estaban familiarizados con javascript y su gramática, es innecesario y difícil para ellos crear aplicaciones web con otro lenguaje de desarrollo que no sea web.

Por fin, con la ayuda de " Binary AST ", el rendimiento de las aplicaciones web actuales se elevará a un nuevo nivel sin ninguna revisión de esas aplicaciones.

PD:
No importa C # o Java, si desea que este lenguaje de programación sea mucho más amigable para los desarrolladores, la eficiencia de este lenguaje será limitada debido a algunas características de "fácil uso" como "tipo débil" y cualquier otra característica, viceversa.

@Becavalier Puede ser afirmativo si está intentando llamar a una función wasm desde la sobrecarga de contexto de JS, pero el tiempo de ejecución no se comunica con Javascript hasta que, a menos que se requiera exclusivamente, ... como consulta DOM / Manipulación, CSS en línea, pinturas de lienzo _etc .._ Toda la ejecución que ocurre dentro del contexto de wasm es bastante más rápida. El retraso entra en escena cuando se introduce el puente JS, como en el caso de # 1120, está intentando imprimir la marca de tiempo de rendimiento en el contexto de Javascript para una función que se ejecuta en el contexto de wasm, que es un retraso adicional.

Los marcos populares como Angular2 / 4, que es una renovación completa que adopta Typecript, Android en Kotlin o iOS en Swift, cuando hay un gran nombre detrás de algunos de los marcos o el lenguaje, todo el mundo intenta adoptar el cambio.

Entonces, el punto es que existe la posibilidad de que JS sea dejado de lado o incluso eliminado de la imagen al abstraer los puentes de API y portar tiempos de ejecución en el navegador. Webassembly ha abierto la puerta para que los compiladores de otros lenguajes compitan con Javascript en el navegador.

Inicialmente, solíamos adoptar tecnologías que hicieron que nuestro código JS fuera más eficiente para ejecutarse en máquinas virtuales como V8 y otras, pero ahora puede escribir y compilar en un código ensamblador que puede saltar el código JS.

Ahora puede esperar compiladores para la web que reemplacen a transpiladores como TypeScript, CoffeeScript, etc.

Desarrolladores de Javascript, crucen los dedos . Se pueden esperar grandes cambios en los próximos años.

PD: me encanta Javascript y C-Lang

Webassembly ha abierto la puerta para que los compiladores de otros lenguajes compitan con Javascript en el navegador.

Sí, de hecho, ese es uno de los propósitos de WebAssembly.

Aquí hay una cita de las preguntas frecuentes de WebAssembly :

Si bien WebAssembly permitirá, con el tiempo, que se compilen muchos lenguajes en la Web, JavaScript tiene una cantidad increíble de impulso y seguirá siendo el único lenguaje dinámico privilegiado (como se describió anteriormente) de la Web. Además, se espera que JavaScript y WebAssembly se utilicen juntos en varias configuraciones:

• Aplicaciones C ++ completas y compiladas que aprovechan JavaScript para unir las cosas.

Tenga en cuenta que otros lenguajes se han compilado en JavaScript durante años y continuarán haciéndolo con o sin WebAssembly.

Ya puede compilar C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. en JavaScript.

Puede compilar código de bytes .NET a JavaScript , puede compilar código de bytes OCaml a JavaScript , y GWT ha existido durante 11 años y se ha utilizado en grandes proyectos.

Estos proyectos existen desde hace muchos años. Realmente no es algo nuevo.

JavaScript ya compite con otros lenguajes. WebAssembly solo hace que otros lenguajes sean más eficientes, eso es todo.

Inicialmente, solíamos adoptar tecnologías que hicieron que nuestro código JS fuera más eficiente para ejecutarse en máquinas virtuales como V8 y otras, pero ahora puede escribir y compilar en un código ensamblador que puede saltar el código JS.

Sí, porque las VM de JavaScript nunca pueden lograr un rendimiento nativo, debido a la sobrecarga de los motores JIT (y la naturaleza inherentemente dinámica de JavaScript), por lo que si desea más rendimiento, necesita un control estricto de bajo nivel de la ejecución del código. WebAssembly le brinda ese control.

Entonces, el punto es que existe la posibilidad de que JS sea dejado de lado o incluso eliminado de la imagen al abstraer los puentes de API y portar tiempos de ejecución en el navegador.

No, la gente seguirá usando JavaScript.

Durante muchos años en el escritorio ha habido muchos lenguajes para elegir: Python, Perl, Ruby, PHP, Haskell, JavaScript (Node.js), OCaml, C ++, Java, etc.

La gente usa muchos lenguajes, incluido JavaScript. JavaScript no va a ninguna parte.

Incluso en un mundo hipotético ( muy improbable) donde JavaScript no es un lenguaje de primera clase, la gente aún puede compilar JavaScript en WebAssembly.

Ahora puede esperar compiladores para la web que reemplacen a transpiladores como TypeScript, CoffeeScript, etc.

Eso es poco probable, todavía hay buenas razones para que la gente use TypeScript y JavaScript.

Por supuesto, habrá alternativas a TypeScript, y algunas personas usarán esas alternativas, pero es poco probable que TypeScript desaparezca.

Digo eso porque ya ha habido buenas alternativas a TypeScript durante años (como Haxe ) pero nunca reemplazaron a TypeScript.

El 4 de septiembre de 2017 a las 03:42, Pauan [email protected] escribió:
>

JavaScript ya compite con otros lenguajes. WebAssembly solo hace
otros lenguajes más eficientes, eso es todo.

Esto último no es del todo correcto. Otro objetivo de Wasm es habilitar funciones
que no son compatibles con JavaScript y, potencialmente, nunca lo serán. Para
ejemplo, la concurrencia, las llamadas finales o las excepciones reanudables están todas en el
mapa vial.

@ rossberg-chromium De hecho, tienes razón, había olvidado ese detalle. Gracias por aclararlo.

@Pauan Gracias por los detalles. Aunque algunos de sus puntos son válidos y tienen sentido, no estoy de acuerdo con todos.

C # en el lado del cliente parece prometedor y un excelente ejemplo para evitar Javascript por completo en la etapa de desarrollo. es decir, puedo usar C # para escribir una aplicación web completamente funcional sin que tenga que escribir ningún código Javascript. Este tipo de marcos basados ​​en actitudes tienen una posibilidad probable de silenciar el legado de Javascript, al menos hasta cierto punto.

Ya puede compilar C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. en JavaScript.

Sí, el Javascript estaba en la imagen. Pero ahora, con WASM / Webasm, mi motivo de compilación en Javascript ha cambiado. Uno puede compilar directamente en wasm y escribir una capa de máscara de API o puentes en Javascript cuando sea necesario, por lo que la base de desarrolladores no necesita saber Javascript para desarrollar una aplicación web con Webapp, me refiero a Webapp puro, no ASP.net, como marcos JSP.

Tenga en cuenta que otros lenguajes se han compilado en JavaScript durante años y continuarán haciéndolo con o sin WebAssembly.

Ya puede compilar C #, F #, C ++, OCaml, Elm, PureScript, Haskell, Java, Python, Ruby, Perl, etc. en JavaScript.

Si bien muchos lenguajes ya pueden compilar en JavaScript, ¿la compilación en Webasm evitaría la carga significativa y las penalizaciones en el rendimiento del tiempo de ejecución por hacerlo? ¿Y los problemas de rendimiento si compila una máquina virtual C completa de idiomas en Webasm para hacerlo de esa manera?

Si el uso de otros lenguajes da como resultado problemas de rendimiento inevitables, o muchos lugares que violan esa especificación de idiomas (por razones de rendimiento), es un reemplazo parcial de JavaScript en el mejor de los casos y, en general, los he visto usados ​​más para portar código heredado que código nuevo para "reemplazar JavaScript "(excepto CoffeeScript, TypeScript, etc. que están diseñados para compilarse en JS muy bien).

¿Son estos problemas que se pueden resolver? por ejemplo, con un nuevo compilador Ruby -> Webasm y obtener un rendimiento comparable al JavaScript del navegador actual?

Para usar JavaScript y Ruby (con Opal) como ejemplo (como algo que probé y básicamente abandoné anteriormente):

En JavaScript con un operador + , permite que los números se conviertan en una cadena, por ejemplo

5 + " example" === "5 example"

Ruby tiene una escritura mucho más fuerte y eso no está permitido:

5 + " example"
#TypeError: String can't be coerced into Integer

Por lo tanto, Opal tiene que crear sus propias ventajas y métodos bastante complejos para muchos tipos de núcleos.

function $rb_plus(lhs, rhs) {
  return (typeof(lhs) === 'number' && typeof(rhs) === 'number') ? lhs + rhs : lhs['$+'](rhs);
}
String.prototype['$+'] = function (r){var t=this,n=arguments.length;return 1!==n&&e.ac(n,1,this,"+"),r=ke.get("Opal").$coerce_to(r,ke.get("String"),"to_str"),t+r.$to_s()}

Lo mismo ocurre con muchas operaciones básicas.

# Ruby: if a || b
if ((($a = ((($b = a) !== false && $b !== nil && $b != null) ? $b : b)) !== nil && $a != null && (!$a.$$is_boolean || $a == true))) {

Tal vez, en teoría, un JIT podría optimizar eso por completo, pero no creo que estén cerca (no hizo un micro benchmark, pero para un prototipo completo de aplicación / página que hice, la versión Ruby fue significativamente más lenta) y conversiones como esa parecen estar haciendo el optimistas la vida más difícil?

E incluso entonces, algunas cosas están mal o no son compatibles (aunque Webasm tiene enteros nativos, por lo que es un comienzo con suerte si se compila en Webasm en lugar de JS):

1 / 2 == 0.5 # Should be 0, Ruby has integer division

str = "Hello"
str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.
puts str # "Hello World"

@nirus

Puedo usar C # para escribir una aplicación web completamente funcional sin que tenga que escribir ningún código Javascript.

Sí, y estoy de acuerdo en que es muy bueno (estoy trabajando en un lenguaje que planeo compilar en WebAssembly), pero mi punto es que ya puedes hacerlo, incluso sin WebAssembly.

Uno puede compilar directamente en wasm y escribir una capa de máscara de API o puentes en Javascript cuando sea necesario, por lo que la base de desarrolladores no necesita saber Javascript para desarrollar una aplicación web con Webapp, me refiero a Webapp puro, no ASP.net, como marcos JSP.

De hecho, y eso ya es posible desde hace muchos años. No necesita esperar a WebAssembly, puede comenzar ahora : asm.js existe desde hace varios años.

@wnewbery

Si bien muchos lenguajes ya pueden compilar en JavaScript, ¿la compilación en Webasm evitaría la carga significativa y las penalizaciones en el rendimiento del tiempo de ejecución por hacerlo? ¿Y los problemas de rendimiento si compila una máquina virtual C completa de idiomas en Webasm para hacerlo de esa manera?

Puede ayudar a los tiempos de análisis, pero es poco probable que ayude al rendimiento del tiempo de ejecución.

Permítanme aclarar algo: asm.js existe desde hace varios años. Le permite compilar un programa en JavaScript, y ese programa se ejecutará a velocidades casi nativas. En otras palabras, puede ejecutar un programa a la misma velocidad que se ejecuta en el escritorio.

Entonces, ya ha sido posible tomar un idioma, compilar su VM, tiempo de ejecución y recolector de basura en asm.js, y luego puede ejecutar el idioma que desee en el navegador, casi a la misma velocidad que en el escritorio. Esto ya es posible desde hace bastante tiempo.

Sin embargo, compilar la máquina virtual, el tiempo de ejecución y el recolector de basura significa que el tamaño del archivo será bastante grande (muchos megabytes).

Y es difícil comunicarse con las API de JS (como el DOM).

Pero algunas personas lo han hecho de todos modos y han creado cosas como PyPy.js que compila el intérprete de PyPy en asm.js.

Se ejecuta más rápido que CPython (¡sí, de verdad! ¡El intérprete de PyPy que se ha compilado en JavaScript y se ejecuta en un navegador se ejecuta más rápido que el CPython nativo en el escritorio!)

Pero el tamaño del archivo es bastante malo (5 megabytes en gzip, 15 megabytes sin procesar).

Entonces, podría compilar la VM de Ruby + recolector de basura + tiempo de ejecución en asm.js, y sería muy rápido, pero tendría esos problemas. Entonces, en cambio, la gente crea cosas como Opal.

WebAssembly es la próxima evolución de asm.js. Por el momento, cualquier cosa que pueda hacer con WebAssembly, también puede hacerlo con asm.js.

Entonces, sí, es posible compilar su lenguaje + VM + tiempo de ejecución + recolector de basura en WebAssembly, y se ejecutará a una velocidad casi nativa.

Pero, por supuesto, tiene las mismas desventajas que asm.js: un tamaño de archivo muy grande y es difícil comunicarse con las API de JS.

Hay siete diferencias entre WebAssembly y asm.js:

1. WebAssembly es un poquito (5%) más rápido que asm.js en general.

2. WebAssembly es significativamente (~ 400%) más rápido que asm.js si usa enteros de 64 bits.

3. WebAssembly se puede analizar mucho más rápido. Esto no mejora la velocidad de ejecución de su programa, pero sí significa que el tiempo de carga inicial es más rápido con WebAssembly.

4. El tamaño del archivo de WebAssembly es más pequeño que el tamaño del archivo asm.js (aproximadamente un 10-20% más pequeño).

5. En el futuro, WebAssembly podría obtener características increíbles que asm.js no tiene (subprocesos, simultaneidad, excepciones de costo cero, etc.).

6. En el futuro, WebAssembly podría obtener acceso al recolector de basura de JavaScript (lo que significa que ya no necesitará compilar el recolector de basura de su idioma en WebAssembly, lo que significa tamaños de archivo más pequeños).

7. WebAssembly obtendrá en el futuro la capacidad de utilizar fácilmente las API de JS (como el DOM).

Pero incluso en el futuro será necesario compilar el tiempo de ejecución de VM + de su idioma en WebAssembly, por lo que el tamaño del archivo seguirá siendo un problema.

Si compilar la máquina virtual + tiempo de ejecución + recolector de basura de su idioma en asm.js no es aceptable para usted, probablemente no lo sea incluso con WebAssembly.

Y si la compilación de VM + tiempo de ejecución + recolector de basura de su lenguaje es aceptable para usted, ya puede hacerlo ahora mismo con asm.js (y luego pasar fácilmente a WebAssembly más adelante).

¿Son estos problemas que se pueden resolver? por ejemplo, con un nuevo compilador Ruby -> Webasm y obtener un rendimiento comparable al JavaScript del navegador actual?

El propósito de WebAssembly es ejecutar programas a velocidades nativas. En otras palabras, ejecutarlos a la misma velocidad que se ejecutan en el escritorio.

Entonces, si compila Ruby en WebAssembly, se ejecutará a la misma velocidad que Ruby se ejecuta en el escritorio.

Ruby es un lenguaje bastante lento. Los lenguajes lentos y los programas lentos seguirán siendo lentos, incluso cuando se compilen con WebAssembly.

1 / 2 == 0.5 # Should be 0, Ruby has integer division

Ese es un error en Opal que se puede solucionar simplemente cambiando la definición de la función $rb_divide .

str << " World" # Opal: String#<< not supported. Mutable String methods are not supported in Opal.

Eso se puede solucionar haciendo que Opal compile cadenas en matrices de JavaScript (que son mutables).

@Pauan

En el futuro, WebAssembly podría obtener características increíbles que asm.js no tiene (subprocesos, simultaneidad, excepciones de costo cero, etc.).

Thread es una característica muy importante para muchos lenguajes, bibliotecas, frameworks. Sin hilo, muchas aplicaciones creadas por c ++, c #, java que se basan en multiproceso no pueden simplemente transformarse en aplicaciones web, ya que pueden causar un comportamiento extraño (sin mencionar otra cosa buena como SIMD soporte _en el futuro (?) _). En resumen, creo que asm.js no es lo suficientemente bueno, ni el rendimiento ni la capacidad de puerto, si es tan bueno, debería haber más bibliotecas "portadas" a asm.js hace mucho tiempo.

como todo el mundo ha dicho que javascript no desaparecerá porque es tan popular y para el soporte heredado, la mayoría de los navegadores seguirán admitiendo la ejecución de javascript de forma nativa, pero creo que en el futuro cualquiera que cree nuevos sitios web con javascript lo compilará en wasm para obtener todas esas ganancias de rendimiento.

@unmellow , para desacreditar ese mito nuevamente: no habría ganancias de rendimiento mágicas compilando JS en Wasm, todo lo contrario. Si desea un mejor rendimiento del que pueden ofrecer los motores JS, debe elegir un idioma mejor.

sí, lo siento, olvidé que quise decir que se analizaría más rápido
editar: algo que podría suceder es que el navegador no actualice sus motores javascript para admitir
las versiones más nuevas de javascript permiten que la gente compile en wasm sin pérdidas de rendimiento

No me siento realmente cómodo pateando un boleto de hace un año, pero, por el bien de la discusión y solo un poco de perorata.

Puedo ver que muchas personas se muestran escépticas con la idea de reemplazar Javascript con WASM, pero una cosa es que WASM no se trata solo de rendimiento. Lo que la gente suele olvidar es que Javascript no es el idioma que quieren (o querían). Quiero decir, al menos, el Javascript básico no es lo que la gente quiere. Cada vez más personas optan por transpiladores, que son básicamente compiladores para lenguajes de terceros. Esto se debe simplemente a que la gente dejó de depender de los estándares y se desvió hacia las soluciones de la tierra de los usuarios (?).

Pero la transpilación es, por su naturaleza, mucho más difícil que la compilación. El problema matemático de mapear un idioma a otro no siempre se limita al ámbito local. Alguna información contextual tiene que transferirse al otro lado, y hacerlo correctamente es un problema difícil. Es por eso que los transpilers no similares a JavaScript no se adoptan ampliamente (o por qué no se debe confiar en ellos).

Además, existe un problema con la duplicación de esfuerzos. Los transpiladores son compiladores y los empaquetadores son enlazadores. Todos hemos tenido esas herramientas durante años. Módulos, agitación de árboles, división de código, carga dinámica / diferida, gestión de activos, etc. Nada es realmente nuevo, pero la gente necesita nuevas herramientas para tener estas funciones solo para la web, lo que no es compatible con las soluciones que no son web.

No es que WASM cambie todo en un día. Javascript tiene un ecosistema bien construido en este momento, mientras que otros lenguajes no lo tienen. Me tomaré un tiempo antes de que Javascript realmente vaya a alguna parte, pero claramente sucederá a largo plazo.

Javascript se dirige, lo que considero, una dirección terrible, así que doy la bienvenida a un reemplazo de WASM. Creo que si bien ha habido mejoras significativas, gran parte de la comunidad y la dirección han sido engañadas durante los últimos años. Daría la bienvenida a un lenguaje adecuado para ... no necesariamente para tomar su lugar, sino para ser un competidor directo para no tener que escribir este nuevo y desagradable sabor de JS y sus "frameworks" que han aparecido.

@spencerudnick ¿ Nunca ha escrito un ensamblaje para obtener ganancias de rendimiento que no puede obtener de C?