La W3C recomienda WebAssembly para forzar límites en pro de velocidad, eficiencia y respuesta. [ENG]

El WebAssembly Working Group ha publicado las tres especificaciones de WebAssembly como recomendaciones W3C, marcando la llegada de un nuevo lenguaje para la web del cual permite ejecutar código en el navegador.

[#1 Jakeukalane]

"A June 2019 study from the Technische Universität Braunschweig, analyzed the usage of WebAssembly in the Alexa top 1 million websites and found the most prevalent use was for malicious crypto mining.[15][16][17]"

[#8 KaborlllLLLONE]

#1 hace poco hice una charla sobre WebAssembly para mí empresa y resumiendo en una línea: WAssembly es una manera de llevar a los navegadores web rutinas concretas con un performance normalizado.

La velocidad: un código de JavaScript optimizado es muy rápido pero puede que lo sea solo en Chrome y no lo sea tanto en Firefox. Con WebAssembly, el rendimiento será similar en ambos navegadores.

Rutinas concretas: literalmente eso. WA es parecido a los webworkers. Están pensados para realizar rutinas concretas y delimitadas, como cryptominado o rotar una foto en un editor online. No sirve para hacer una librería web (aunque seguro que están en ello) o para cosillas tontas "para que sean más rápidas".

WA es muy bienvenido y se agradecen pero no va a traer velocidad a las web porque simple y llanamente un JavaScript optimizado es tan rápido como C++ o en algunas tareas incluso más rápido.

[#11 Desactivado]

#8 Javascript es muy lento cuando se utiliza de forma normal.
Webassembly tiene todas las de ganar y es mucho más facil de usar en aplicaciones que necesiten rendimiento o que necesiten threads, sin olvidar que se puede reaprovechar millones de librerías hechas en c/c++ que es como un legado humano de conocimiento.
La idea es muy buena pero veremos como se gestiona algo que a mi modo de ver es revolucionario, que hará apple cuando las aplicaciones webassembly son de una calidad similar a las apps, permitirá su uso sin pasar por caja?
Que hará google cuando no pueda meter mano de los entresijos de una web para su "indexación"?
Tengo mis palomitas preparadas.

[#12 KaborlllLLLONE]

#11 no es cierto lo que dices. Como te comentaba JavaScript es muy rápido (optimizado o no). Otra cosa es que el código JS sea una mierda pero el mismo código escrito en C++ también lo sería.

La ventaja de WebAssembly es que se puede compilar rutinas concretas ya escritas en otros lenguajes y poder ejecutar esas rutinas concretas en el navegador. Pero su utilidad termina aquí. Es decir no es su intención sustituir a JavaScript en absoluto.

Que hará google cuando no pueda meter mano de los entresijos de una web para su "indexación"?

???? Vale, definitivamente aquí estamos confundiendo cosas. Google no indexa una web generada con JavaScript a día de hoy.

Por cierto, NO tiene soporte de threads ni de muchísimas otras cosas. Están ello, por supuesto, pero ahora mismo no lo soporta.

[#22 Desactivado]

#12 El soporte de threads en wasm están soportados y habilitados por defecto desde chrome 74, estuvieron en trial desde la 69.
SharedArrayBuffer se deshabilitó por las vulnerabilidades que todos sabemos, pero chrome ya lo ha reactivado y el resto pues les seguirá pronto. Solo hay que ver la aplicación earth en wasm para ver la mejora de rendimiento con threads.
Con lo de que javascript es rápido, ya sabes que todo es relativo, pero yo que hago aplicaciones nativas con Qt/QML, el codigo es una mezcla de C++ y javascript, y bueno, las comparaciones reales no van en la linea de tu pensamiento.
Solo tienes que ver las recomendaciones por doquier de Digia de usar javacript lo menos posible si quieres rendimiento (de hecho ahora se ha optado por desarrollar un compilador en tiempo de compilación de javascript para mejorar tiempos).

[#27 KaborlllLLLONE]

#22 por lo general los motores de JavaScript son bastante rápidos... En teoría por supuesto pero también en los diferentes tests que se hacen en los diferentes entornos. No soy un experto ni nunca he llevado web engines al escritorio pero seguramente en tus aplicaciones usas un V8 integrado sobre más cosas y en tu caso probablemente sean esas otras cosas lo que hace que algo vaya lento. Si tienes problemas de rendimiento en tus interfaces me juego el cuello a que es debido a las rutinas de dibujado de la interfaz y, quizás, a los cambios de contexto de un entorno a otro. Probablemente sea lo primero. Qué se puede hacer para evitar eso? Probablemente nada... Más allá de evitar usar JavaScript para manipular la interfaz como bien comentas.

Un saludo!

[#30 Desactivado]

#12 se puede compilar rutinas concretas ya escritas en otros lenguajes y poder ejecutar esas rutinas concretas en el navegador

pero ahí ya depende de la arquitectura y sistema operativo que tenga el cliente,¿o hay que compilar para todos los clientes posibles?

[#33 Porkopek_]

#12 Google no indexa una web generada con JavaScript a día de hoy

Claro que sí.
https://seopressor.com/blog/javascript-seo-how-does-google-crawl-javascript/

A efectos de SEO, es mejor renderizar el HTML en el servidor, pero Google si que indexa páginas donde el HTML se produce solo client-side

[#38 dudo]

#11 apple permite instalar cualquier web como app, de hecho cuando salió el iPhone sólo se podían instalar webapps, el modelo no tuvo mucho éxito

[#45 prejudice]

#11 Que hará google cuando no pueda meter mano de los entresijos de una web para su "indexación"?
Si los buscadores no indexan bien tu página, posiblemente el problema lo tengas tú.
A parte de eso. A día de hoy, existen soluciones para que indexen correctamente cuándo haces aplicaciones SPA ( https://es.m.wikipedia.org/wiki/Single-page_application ), por ejemplo en angular se puede usar Server-side Rendering ( https://angular.io/guide/universal ) para que los buscadores indexen todo bien, como si fuera una aplicación web clásica

[#14 Penetrator]

#8 JavaScript optimizado es tan rápido como C++ o en algunas tareas incluso más rápido

Permíteme que lo dude. ¿Tienes algún enlace que sustente tamaña afirmación?

[#15 Desactivado]

#14 un foro de hackers de la web y lo que le han dicho en la JS party Valdepeñas

[#17 Desactivado]

#15 Algunos juegos 3D "potentes" no tiraban lento en absoluto en un navegador como Chrome con un Pentium G y 4GB de RAM. Y una HD2000/3000 como soporte gráfico integrado.

https://www.webassemblygames.com/

[#20 Desactivado]

#17 ¿Y que y tiene esto que ver con "JavaScript optimizado es tan rápido como C++ o en algunas tareas incluso más rápido"?

[#21 Desactivado]

#20 A, vale, JS. Bueno, con algunos JIT como v8 pueden jugar con la optimización en según que casos donde C++ no puede. Pero no generalmente.

[#18 Desactivado]

#15 https://jquesnelle.github.io/mupen64plus-ui-console/

Un ejemplo. Y en PC's actuales podrías emular la DC y la PSP sin problemas al menos a 2X usando WebAssembly y un port EMScripten de PPSSPP.

[#16 KaborlllLLLONE]

#14 no me apetece buscar pero es fácil encontrar webs especializadas hablando precisamente sobre esto. Un adelanto: los algoritmos de manejo de strings suelen ser casi tan rápidos en JavaScript como en C++. Y otra cosa, JavaScript es código interpretado sólo la primera vez que se lee. Después se compila a código máquina por el navegador.

[#39 MarkIV]

#16 Prefiero que te saltes el adelanto y muestres pruebas concretas y controladas.
Por ejemplo https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html donde C++ es x veces más rápido que javascript en muchos de los tests.

[#41 Nova6K0]

#16 Se ve perfectamente en la implementación de las páginas web... Una cosa entra casi en cualquier web con NoScript desactivado en dicha web y luego con NoScript activado en la misma, a ver si notas diferencia. Yo ya te digo que sí. Además de que te evitas posibles scripts de minado, malwares varios por redirección...

Salu2

[#31 Porkopek_]

#c-8" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3222215/order/8">#8 ¿En serio hiciste una charla y les contaste eso? Porque WebAssembly permite, entre otras muchas cosas, ejecutar otros lenguajes en el navegador, compilándolos Just in Time. Entre otros proyectos, Microsoft tiene Blazor, que es todo un framework con sus distintas librerías y su parafernalia, que permite ejecutar C# en el navegador.

Y lo de que javascript optimizado es tan rápido como C++... ¿eso lo has soñado? ¿Cómo va a ser un lenguaje con Garbage Collector tan rápido como un lenguaje que permite hacerle las perrerías que quieras a la memoria? Si comparamos el mismo programa Javascript optimizado y C++ optimizado, el segundo gana siempre

La rapidez de WebAssembly es una característica que se dejará para un futuro cercano. Por lo de ahora es una herramienta muy interesante para poder programar en cualquier otro lenguaje en el navegador.
Resumiendo: para que los chicos del backend puedan también hacer sus cosas cool en el frontend

[#44 Nielo]

#8 He estado en un par de conferencias donde explicaban las bondades de WebAssembly, que no son pocas.

Lo que siempre se obvia y me está costando un poco encontrar información es que no deja de ser código compilado y que como tal no se puede ver la fuente.

¿No atenta un poco/mucho contra la filosofía de "la web"?

Pregunto desde la ignorancia, aunque podría decirse que soy un programador competente de JS.

[#55 mcfgdbbn3]

#44: Y que si el principal uso es minar criptomonedas...

[#46 prejudice]

#8 JavaScript optimizado es tan rápido como C++ o en algunas tareas incluso más rápido.

Se me ha caído el monóculo en la taza de té

[#54 mcfgdbbn3]

#1: Y otra: ¿Qué pasa si no puedes usar un navegador actualizado?

A algunos lo de la retrocompatibilidad se les olvida bastante.

[#9 KaborlllLLLONE]

#6 ?? WebAssembly no es JavaScript, es un lenguaje diferente. Creo que te estás confundiendo con "asm.js" que sí es JavaScript.

[#19 omegapoint]

#9 es verdad, lo siento, he leido mal.

[#5 Desactivado]

Ahora que empezaba a entender el JavaScript... Grrrr

[#6 omegapoint]

#5 esto es javascript igual.

¿lo tuyo es sarcasmo?

[#29 mipisha]

#5 Siempre seguirás necesitando Javascript. WebAssembly no tiene acceso al DOM, este se usa para realizar cálculos complejos que después querrás pintar en pantalla con Javascript.

[#32 mipisha]

#5 #29 Aunque creo que había entendido mal la noticia, parece que recomienda un sustituto a javascript y no una mejora de WebAssembly

[#4 hasta_los_cojones]

Y yo recomiendo rust para programar y compilar a webasambly

[#26 MDman]

#4 Pregunta tonta de Rust. Los paquetes de Rust...¿cargo se llaman?...¿Funcionan en ambiente nativo y web igualmente? ¿O hay paquetes que sólo funcionan nativo? ¿Si es así se pueden filtrar?

[#36 hasta_los_cojones]

#26 para que funcione en web tienes que compilarlo a webasambly

Y no te puedo decir mucho más porque aún no he hecho nada más que ejemplos y ejercicios.

El lenguaje mola. Más que go, más que c y más que java.

No sé si mola más que erlang. Nunca he usado erlang.

[#40 cosmonauta]

#36 Noorrrr... Go mola más.

Ahora en serio, golang y Rust son los mejores lenguajes del momento.

[#43 hasta_los_cojones]

#40 las gorrutinas me han flipado, pero la gestión de memoria de rust y el polimorfismo, me han flipado incluso más.

Por cierto, con go no se puede compilar para webasambly, porque go tiene recolector de basura, ¿no?

[#49 cosmonauta]

#43 Si se puede. Sólo hay que pasarle un flag de compilación, igual que si haces compilación cruzada.

[#52 hasta_los_cojones]

#49 ohhhh, intrresante.

Supongo que aunque WebAssembly no tiene recolector de basura nativamente, el archivo compilado puede incluirlo. Tampoco tiene recolector de basura el código máquina, y eso no impide que un lenguaje como go pueda compilar a código máquina.

Igual le doy otra ojeada.

#50 nop, lo estoy aprendiendo para usarlo en proyectos propios y de cara al futuro.

[#50 cosmonauta]

#43 ¿Trabajas con Rust? Yo lo he estado mirando en plan novato y me ha gustado, pero no quise profundizar más después de ver que no había una sola oferta de Rust en toda Barcelona.

En go somos pocos, pero cada vez hay más oferta.

[#58 Desactivado]

#26 Cargo es el gestor de paquetes y herramienta de compilación, los paquetes en sí se llaman crates.

[#59 MDman]

#58 ¿Pero los paquetes son universales o los hay sólo para "binario" y otros sólo "web"?

[#60 Desactivado]

#59 Creo, pero no estoy seguro, que muchos son universales, a menos que dependan de funcionalidades específicas del SO. Compilar tu crate para WASM es un poco con utilizar un compilador cruzado, pero por suerte hay herramientas que ayudan en la tarea:

https://lib.rs/crates/wasm-pack
https://rustwasm.github.io/docs/wasm-pack/

[#53 JCarlesVilaseca]

Para los curiosos, Webassembly se usa en lichess.org en el análisis de jugadas en vivo (https://lichess.org/analysis)
El código del motor de ajedrez Stockfish lo han portado a Webassembly en https://github.com/niklasf/stockfish.wasm

[#34 gilipipas]

Mierda, justo ahora que acabo de aprender react y typescript....

[#35 otrohastalasnarices]

Probé webassembly hace un tiempo. Una simple aplicación de todo list eran 20 MB a descargar por el navegador. No lo veo

[#37 box3d]

#35 Define "simple" y entenderé si 20MB es mucho o poco.

[#56 TheGreatDoc]

#37 Tampoco es que puedas complicar mucho un "TODO List"...

[#57 box3d]

#56 Cargar Qt con widgets (framework de escritorio, con ventanas y botones, compilado para WebAsm) son ~10MB. Sin hacer nada. Pero es un framework pesado.

20MB es una animalada. A saber cuanta librería estabas cargando.

[#2 Jesuo]

Si, si, un claro ingles nativo el que escribió eso, y la dirección w3.org ccccccccchirria.

[#3 Jakeukalane]

#2 ¿a qué te refieres?

[#7 David_VG]

#3 w3CCCC

[#10 Jakeukalane]

#7 world wide web (w3) consortium. El consortium no lo han puesto en la url. Es su web.

[#23 David_VG]

#10 explicaselo a el yo solo soy el mensajero.

[#24 Jakeukalane]

#2 - #10

[#13 frg]

#2 #3 Creo que alguno no conoce la w3 (The World Wide Web Consortium), y se cree que se puede comprar un dominio barato, ¡de dos letras! para hacer el mal

[#47 Jesuo]

#13 W3C.org

[#48 Jesuo]

#13 w3c.org me importa una mierda como redireccione hoy o los dns, tengo muy buena memoria.

[#51 frg]

#48 No tan buena, que el dominio w3.org lo compraron en el 94, ...

[#25 PortgasDAce]

#2

[#28 Porkopek_]

#2 El inglés del artículo es perfecto. Puede no ser nativa, pero o lo habla muy bien o se lo ha revisado un nativo

[#42 Ithilwen2]

Opera mini aprende alguna cosa