En el
último artículo sobre WebAssembly, hice la siguiente declaración:
Algunos comparan WebAssembly con applets de Java. En cierto sentido, tienen razón, pero por otro lado están muy equivocados. De alguna manera escribiré un artículo sobre las diferencias, pero por ahora hablemos de las similitudes. En cierto modo, WebAssembly es una forma diferente de lograr lo que JVM estaba destinado: es una máquina virtual ordinaria para software multiplataforma.
Muchas personas han expresado interés en este tema, ¡así que echemos un vistazo más de cerca! En este artículo, comparamos WebAssembly con tres tecnologías: Flash, applets de Java y un
poco con PNaCL. El artículo también se enfoca en usarlo en la
web , aunque anteriormente analizamos el uso de opciones para usar WebAssembly sin conexión. Pero hablaremos de
tal comparación más tarde. Finalmente, este artículo es similar a comer tapas [merienda española de muchos ingredientes diferentes - aprox. per.], aquí hay un montón de pequeñas secciones. Me parece que es un poco corto, pero al mismo tiempo estoy tratando de bloguear, y si continúo expandiéndolo, tomará una eternidad, así que lo siento.
Creo que una comparación con los applets de Flash y Java es bastante
natural cuando te encuentras con esta descripción de WebAssembly:
WebAssembly (Wasm para abreviar) es un formato de instrucciones binarias para una máquina virtual apilada. Wasm fue desarrollado como una versión portátil de compilación de lenguajes de alto nivel como C, C ++ y Rust, que le permite implementar aplicaciones de cliente y servidor en Internet.
Esto es un poco como la tecnología pasada. Es lógico comparar cómo están conectados y sugerir pequeñas diferencias entre ellos. Pero WebAssembly es significativamente diferente por varias razones.
Wasm derrotado
La primera razón por la que WebAssembly es diferente es porque terminó teniendo éxito, mientras que las tecnologías anteriores no lo hicieron. Me refiero a la victoria en un sentido específico. Si compara la cantidad de aplicaciones Flash y la cantidad de aplicaciones WebAssembly, es probable que Wasm pierda. Los adherentes a WebAssembly tendrán que trabajar duro para distribuir esta plataforma.
Cuando hablo de la victoria de WebAssembly, quiero decir que se ha convertido en parte de la plataforma web. Flash, applets de Java y PNaCL funcionaron a través de complementos. En cierto sentido, estaban
fuera del ecosistema web. Nunca se incluyeron en el estándar, y esto es muy importante.
En cierto sentido, tal explicación es suficiente. Pero señalar un hecho no significa explicar sus
causas . El resto de este artículo intentará descubrir
por qué sucedió esto: por qué WebAssembly logró lo que otras tecnologías no podían hacer. Aquí,
muchas razones están relacionadas entre sí, pero estoy tratando de dividirlas razonablemente en puntos separados.
Otras tecnologías no encajan en la plataforma
¿Te acuerdas de eso?
O es?
¿Qué tal esto?
Un applet basado en estas tecnologías no es realmente una
aplicación web . Tiene una página web con una pieza cortada y su applet funcionó en este marco. Pierde todas las ventajas de otras tecnologías web: ni HTML, ni CSS, ni la capacidad de integrarse en la web. Estas plataformas no interactúan con el resto de la plataforma en el navegador. Bueno,
técnicamente pueden , pero en la práctica, estas tecnologías se han utilizado de manera diferente.
¿Cómo soporta la web un ecosistema que no se integra con él? Esto nunca sucederá. Y los usuarios finalmente lo rechazaron resueltamente. Además de los juegos, los usuarios
odiaban Flash, y los applets de Java eran pesados y lentos. Estas tecnologías no están arraigadas en la plataforma web.
WebAssembly, por otro lado, está mucho más cerca de JavaScript. De hecho, Wasm no te quita parte de la pantalla. Él no crea su propio pequeño mundo cerrado. Ahora usando JavaScript, y
en el futuro por sí solo , puede interactuar con el entorno. Él solo ... encaja en eso.
Otra tecnología propiedad de empresas
Java era propiedad de Sun Microsystems, Flash era propiedad de Adobe. ¿Por qué es esto importante?
La influencia corporativa en Internet es un tema complejo.
En general, la web opera en un modelo de pseudo consenso. Java y Flash, por otro lado, fueron controlados por sus respectivas compañías. Tienen una fuerte motivación para obtener ganancias, no para mejorar Internet. Y esto condujo parcialmente a la situación antes mencionada: a estas compañías no les importaba integrarse adecuadamente con el resto de la plataforma. ¿Por qué lo necesitan? Es mucho mejor para las empresas bloquear su plataforma y abandonar por completo el resto de Internet. La motivación está completamente sesgada.
WebAssembly es una iniciativa conjunta de Mozilla, Google, Apple, Microsoft y otros. No promueve la plataforma específica de alguien, sino que representa los intereses comunes de una amplia gama de partes interesadas, tanto corporativas como individuales.
WebAssembly siguió el proceso web
La afiliación corporativa
también significa que estas tecnologías nunca han seguido el proceso que usamos para estandarizar la web. El proceso de adopción de estándares web está bien establecido, pero estas tecnologías eran demasiado grandes y funcionaban de manera un poco diferente. En contraste, WebAssembly siguió el procedimiento estándar adoptado para las tecnologías web.
Asm.js se creó por primera vez como prueba de que podemos hacer cosas impresionantes con la web. Su ejecución resultó ser de alta calidad y demostró las capacidades de la tecnología, aunque no hay nada fantástico allí. La principal carta de triunfo de
asm.js fue que era solo código JavaScript: es totalmente compatible con el ecosistema existente. "No romper Internet" es una regla muy, muy importante para los desarrolladores de navegadores.
WebAssembly era una versión mejorada de
asm.js Después de encontrar un consenso sobre
asm.js todos se unieron para hacer de WebAssembly una realidad. Como no se trata solo de JavaScript, debería haber pasado por todo el proceso de implementación en los navegadores, y lo pasó. Esta es ahora la especificación W3C, que se
ajusta a los estándares web, pero no los contradice.
Consecuencia: otras tecnologías eran demasiado grandes e inestables.
Otra razón por la que Wasm tuvo éxito: es pequeña. Wasm adopta el enfoque de otras tecnologías web: comience con poco y aumente de tamaño sobre esta base. Mantener compatible con versiones anteriores. Las tecnologías pasadas tampoco siguieron esta convención social particular. Se cargó un tiempo de ejecución específico para los applets de Flash y Java, por lo que no era necesaria la compatibilidad. PNaCl está construido sobre el código IR LLVM completamente inestable. Iban a convertirlo en un subconjunto estable, pero si LLVM cambiara, habría una discrepancia, lo que no es muy bueno.
Estas tecnologías también son demasiado engorrosas para esperar la estabilización. ¿Te imaginas que cuatro fabricantes de navegadores definan completamente las especificaciones JVM y luego acepten esta semántica para siempre? Para todos los ActionScript, ¿cuál es en sí misma una versión similar pero diferente de ECMAScript? ¿Para todo LLVM-IR?
Las grandes tecnologías representan un riesgo inaceptable para la situación. Este es un acuerdo de todo o nada, y aquí hay una apuesta segura de "nada". WebAssembly, por otro lado, no hace casi nada. Esto es principalmente matemática y una llamada de JavaScript. Es decir, es
mucho más fácil estar de acuerdo aquí.
Corolario: otras tecnologías requieren una máquina virtual completamente separada
En este artículo no mencioné a Dart, pero también cabe aquí. La oración, "Pongamos la JVM en cada navegador", el problema principal es que el navegador
ya tiene un tiempo de ejecución de JavaScript. Incluso un tiempo de ejecución es bastante difícil de mantener, sin mencionar dos. ¿Y cómo los integras?
WebAssembly, por otro lado, está diseñado como una pequeña extensión para las máquinas virtuales JavaScript existentes. Aunque
puede implementar su propia máquina virtual de WebAssembly, esto a menudo se hace con WebAssembly sin conexión, pero para los navegadores, los costos de mantenimiento son mucho, mucho más bajos.
Otras tecnologías son demasiado específicas.
WebAssembly es fundamentalmente independiente del lenguaje. Los applets de Flash y Java fueron diseñados principalmente para ejecutar ActionScript y Java. Están profundamente apegados a su semántica relativa. Incluso PNaCl sufre hasta cierto punto de esto: LLVM es realmente adecuado para lenguajes tipo C, aunque no del mismo modo.
¿Realmente queremos elegir un idioma para todo Internet? Ya tenemos JavaScript. ¿Alguna vez imaginas un tercer idioma? Cuarto? Un enfoque independiente es mucho mejor a largo plazo.
Wasm tiene un enfoque estricto de seguridad
Los applets de Java y Flash fueron una verdadera
pesadilla de seguridad. Incluso si se hicieron intentos para protegerlos, en realidad surgieron problemas constantemente.
Por otro lado, WebAssembly recibió nuevamente bonos de la máquina virtual de JavaScript: todos los esfuerzos para aislar su caja de arena también se aplican a Wasm. Aquí, faltan algunas funciones del ensamblador habitual, lo que puede generar vulnerabilidades, como la destrucción de la pila. Wasm funciona de forma segura con la memoria, lo cual es muy importante.
Además, WebAssembly se diseñó originalmente con la idea de la
validación en mente : está completamente tipado y los programas se pueden verificar sin ejecutar el código. Las especificaciones incluyen instrucciones sobre cómo llevar a cabo dicha validación. ¡Esto es muy útil!
Conclusión
Quiero decir lo siguiente sobre este artículo: está escrito desde el punto de vista del
desarrollador . Pero los desarrolladores son importantes porque controlan la web. La tecnología debe ser coherente con sus objetivos: esto es tan importante como la conveniencia para los usuarios finales. En un artículo futuro, intentaré analizar los problemas desde el punto de vista de los usuarios. ¡Tengo que escribir mucho!
Para resumir:
- Otras tecnologías no se integraron en la plataforma web, y esto se vio obstaculizado por intereses comerciales.
- Otras tecnologías requieren demasiado: muchos tuvieron que sacrificarse en la implementación.
- Wasm tiene un aislamiento y validación de sandbox realmente bueno, que otros simplemente no tenían.