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.
|
etiquetas: w3c , wasm , web , www , assembly , webassembly , velocidad , eficiencia , respuesta 
¿lo tuyo es sarcasmo?
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.
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.
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.
Permíteme que lo dude. ¿Tienes algún enlace que sustente tamaña afirmación?
www.webassemblygames.com/
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.
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).
Un saludo!
pero ahí ya depende de la arquitectura y sistema operativo que tenga el cliente,¿o hay que compilar para todos los clientes posibles?
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
Claro que sí.
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
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.
Por ejemplo benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.h donde C++ es x veces más rápido que javascript en muchos de los tests.
Ahora en serio, golang y Rust son los mejores lenguajes del momento.
Salu2
Por cierto, con go no se puede compilar para webasambly, porque go tiene recolector de basura, ¿no?
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.
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 ( es.m.wikipedia.org/wiki/Single-page_application ), por ejemplo en angular se puede usar Server-side Rendering ( angular.io/guide/universal ) para que los buscadores indexen todo bien, como si fuera una aplicación web clásica
Se me ha caído el monóculo en la taza de té
En go somos pocos, pero cada vez hay más oferta.
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.
El código del motor de ajedrez Stockfish lo han portado a Webassembly en github.com/niklasf/stockfish.wasm
A algunos lo de la retrocompatibilidad se les olvida bastante.
20MB es una animalada. A saber cuanta librería estabas cargando.
lib.rs/crates/wasm-pack
rustwasm.github.io/docs/wasm-pack/