Un año esperando este video. "Gracias Pelado", tengo varias app migradas a WASM usando Tiny Golang y se ve claro que el camino es "WebAssembly", pienso que en los proximos años usaremos compiladores y framework que automaticamente generaran el compilado es WASM y sera trasparente para el desarrollador o la plataforma. ;) Yo veo mucha utilidad en aplicaciones PWA con WASM (cliente) consumiendo lo necesario via API y otros servicios, tambien es la puerta a multiplataforma.
En mi experiencia: Rust y Kotlin tienen muy buena compatibilidad para WASM y ya llevan algunos años en prod… seguramente este sea el futuro del serverless por qué es básicamente lo mismo pero esta vez de forma Edge
Recuerdo hace 20 años en la universidad la revolución que fueron las JVM, build once run everywhere... Tambien Web Assembly no despegaba pero finalmente lo hara ... Que chingon
En la imagen de C estas incluyendo el compiler y buildeando el codigo, para despues ejecutarlo. Podrias simplemente copiar el binario y traer una imagen de un OS con lo minimo necesario para correr dicho binario.
Hay un error conceptual muy grande que no es relevante en el tiempo de ejecución que es lo que se dice en el video en 11:25. Un binario de docker es NATIVO desde la conceptualización del conteiner, mientras que en WASM hay un interprete que es una máquina virtual de webassembly. El código que se genera en WASM es como el código que se genera en JAVA, un binario que se ejecuta en una máquina virtual arriba de la plataforma. Es una idea vieja y está muy optimizadoya que creo que lo utilizan hace un tiempo los compiladores internos del estandar ECMA en los navegadores (no estoy absolutamente seguro). Entonces ¿porque resulta más rápido ejecutar una app wasm que en docker? por el entorno, dado que docker tiene que hacer una inicialización que wasm no necesita, pero si tenemos una aplicación muy grande escrita en wasm y la misma en C y tiene que hacer por ejemplo cálculo que no requieren interface con el sistema sospecho que se invertiran los resultados, porque C es compila a código assembly de la plataforma destino muy óptimo, por eso en docker es necesario especificar si es para x86, ARM, etc. En definitiva desde el tema speed es discutible y hay que afilar, pero la palabra NATIVA es acá lo incorrecto porque el binario generado en WASM es intérprete y no es nativo y en docker la aplicación es compilada y es nativa al entorno objetivo. Si se usa alpine en C con musl no sería extraño que le pase el trapo a wasm, pero no por mucho (siempre si hablamos de código pequeño, en aplicaciones de HPC habría que investigar) y para el caso del ejemplo creo que se puede hacer en unos pocos megas.
Gracias a wasam existe blazor y es de las cosas más bonitas que me han pasado como desarrollador C#, pude empezar mi propio emprendimiento de desarrollo de software, todo con solo C#
gracias tío por la info, estoy tan lleno de cosas que no llego a estos temas de webassembly, a la final será un intermediario pero que quizás nunca programaremos en él sino lo utilizaremos como herramienta y ya está
Pero hombre, son dos conceptos completamente diferentes. Es un lenguaje de bajo nivel que está soportado en el navegador y node. La eficiencia es muy alta porque tiene su propio sub entorno en el navegador. Lo otro son máquinas emuladas, nada que ver...
Esta muy interesante WASM, pero no todo es compilable a WASM. Si tu aplicacion esta en c++ es candidato, pero no tiene la amplitud que tiene Docker u otras tecnologias de contenedores de poder "correr" cualquier aplicacion de cualquier lenguaje. Incluso para ser mas justo con la comparativa que propones From Skratch de wasm, yo hubiese hecho un multi-stage buildean con Docker From gcc y creando una imagen From Skratch solo con el binario de salida de gcc que seria practicamente igual de liviana de WASM. Desde mi humilde opinión veo a WASM como una evolución de lo antes era un Java Applet
Muy buen video!!! Si bien docker permite entre otras cosas encapsular tu aplicación y hacer uso de puertos,volúmenes, etc quizá para el caso de uso de desarrollo web se ve súper pontente!!!
Pelado sos una bestia, inconmensurable, impresionante! Gracias por tanto Dicho esto, salchicha voladora: esa forma de funcionar de wasm me hace acordar a la jvm
No entendí la comparacion, Docker principalmente es para empaquetar sistemas completos, WASM más bien es un entorno de ejecución como la JVM no puedes tener un sistema para construir tu aplicación empaquetado en WASM o si?
Solo está comparando en base a lo que la gente dice, se enfoca al target de lo que ambos pueden hacer a nivel de navegador, es decir wasm puede correr código en navegadores y puede servirte aplicaciones para ser consumidas en navegadores, nunca dijo que sirvan los dos para lo mismo.
En realidad si se puede. Es verdad que vas a necesitar un runtime, algo similar a Docker Engine, pero dentro de eso puedes hacer si quieres un filesystem identico, no es necesario pero si quieres podrias compilar Linux a WASM. Piensalo más bien como una runtime para ejecutar codigo cercano al binario, hay runtimes que no necesitan un OS propio, creo que Wasmer por ejemplo tiene una forma de ejecutar codigo sin OS.
lo veo excelente del lado del frontend, pero para aplicaciones back no se tengo mis dudas habria que comprobar rendimientos, pero pues es lo que hace la virtual machine de java eso si con compatiblilidad para varios lenguajes, seria interesante si sacaran un lenguaje universal intermedio tal vez sea wasm toca ver como se desarrolla
Gracias por el video, muy interesante, me gustaría saber si haz hecho pruebas con algo mas complejo, por ejemplo una app en Java o .Net con UI, como WASM trabaja con la experiencia de usuario y dado que estos lenguajes son interpretados como se genera el ensamblado y las dependencias, supongo que en este escenario el tamaño del archivo si va a ser mayor.
Lo tenia guardado este video para ver ...y ayer me comentaron que WASM ...remplazaría a Docker en el futuro (what ???) . Partiendo que el nombre que le pusieron apesta WASM WASI??? mamita ...mas alla de las ventajas que pueda tener sobre Docker ....el ecosistema que tiene Docker desde su creación es enorme hasta su integración en Kubernetes...y es una herramienta que funciona y funciona muy bien....y pensar (WASM ???) que esto lo pueda reemplazar ...ni empedo!!! ... Quizas se pueda acomplar en una parte del ecosistema de Docker (Development) y darle a docker más versatilidad aún de la que tiene.....pero reemplazarlo ...no me lo imagino ...Gracias @Pablo por siempre trayendonos última tecnogía . Abrazo groso!!!
Hace apenas un par de años Docker agregó un nuevo runtime para correr contenedores de wasm, podman desde sus inicios siempre ha permitido correr contenedores de wasm, aquí podman lleva la delantera, en integración
Las aplicaciones de Go se pueden ejecutar en contenedores sin usar una imagen base por lo que las imagenes pesan lo que pese el garbage colector. Si mal no recuerdo figma supero a adobexd por wasm
Recien ví este video, algo que pasa en Docker es que hay muchos CVE relacionados a dependencias (librerías, componentes base de linux, openssl por ejemplo) que fuerzan a que uno haga un update del contenedor, controlar la base de donde sale la misma, etc. ¿Cómo se aplica esto al archivo wasm?
Excelente, al hacerlo con un binario se podria hacer con GO tambien, es interesante. En este caso, que tanta es la diferencia de performance en el navegadpr? Como podriamos hacer un benchmark de esto? Esta muy interesante, buen video!
Creeria que tiene algo de diferencia, el navegador es un runtime más complejo que para informar cosas por consola estoy seguro que tiene que serializar e informar mediante una API de JS. Sigue siendo mejor que la opción de usar JS si lo que buscas es performance pero bueno, existe esa diferencia entre runtime dentro y fuera del navegador. Por otro lado estan disponibilizando más APIs con el paso del tiempo. WASM tiene una desventaja que es que no provee garbage collector. Tu podrías usar Go pero a diferencia de C, C++ y Rust el GC va a tener un costo adicional y en web el tiempo de carga suele influir, sobre todo por como gestiona los recursos el navegador.
@PeladoNerd, llamame loco, pero no veo el boton de "Guardar" para poder añadir tu video a "Ver mas tarde". No sé si es un error o es intencionado, pero para mi es esencial :') Gracias!
Ojo! Que sea nativo no significa que de los mismos beneficios, la mayoría de proyectos hechos en WASM son en C, C++ y Rust por el tema de que uno de los puntos fuertes era poder re utilizar codigo nativo del lado del navegador. El tema es que en el navegador se castiga el tamaño de los binarios y WASM no tiene Garbage Collector en si. Cuando compilas otros lenguajes se incluye el GC justamente por ese motivo, entonces los binarios terminan teniendo un rendimiento similar al original, no seria taan cerca al binario, sin embargo tienes una performance identica.
Muy interesante video. Ésto me recordó otra tecnología que también es un salto en el paradigma, en este caso, de PHP. Me refiero a FrankenPHP. Con tu estilo creo que saldría un buen video que quedará como referencia. Te animo a hacerlo cuando sea posible (si no lo has hecho aún). Saludos!
Yo lo que quiero es que web assembly tenga acceso al DOM, para ver si podemos librarnos de Javascript como unico lenguaje del navegador y hacer a la web language agnostic
lo interesante seria acceder a funciones nativas del sistema operativo ya que es un codigo binario en C por ejemplo listar las impresoras instaladas para mandar a imprimir directamente desde el navegador, entiendo que no se puede debido a restricciones del mismo navegador web.
No es exactamente binario pero si, los runtimes de WASM proveen de alguna forma acceso a hardware. El navegador es un runtime mucho más restringido pero debe de tener algunos casos, por ejemplo si necesitas usar la GPU desde el navegador estan estabilizando esa API en todos los navegadores.
Es un poco eso, WASM en realidad no es un compilado final final, se dice que es cercano al binario pero puedes leerlo si te interesa, son prácticamente instrucciones bytecode.
WASM no es lo mismo que solo web assembly. WASM es web assembly system modules. WASM es precisamente (aunque sobresimplifico) para que web assembly salga del mundo del navegador.
WASI también soporta un GC genérico, igual no se compara a los contenedores, sino a una app compilada, incluso podes correr un server de .NET en el navegador (sí, el server dentro del browser).. Lo vengo usando hace rato para cosas de high performance como IA dentro del browser, no reemplaza ni a docker ni a JS, lo complementa en performance. Me pondría cachondo verlo con docker compose jajaja
Ojo, si usas WASM en el navegador tiene una gran ventaja, WASM en los ultimos meses, se estaba trabajando para darle una API nativa a WebGPU desde el lado de WASM. Entiendo que con esa API ya no tienes cuello de botella. Antes se hacia WASM se serializaba -> Se comunicaba con JS -> Js se comunicaba con WebGPU -> enviaba esa información a WASM. Era ineficiente, esta nueva API va a potenciar mucho a WASM en el navegador, quizas para IA por dar un caso.
@@PhosphorusMoscu-codenaturalmente, desde WASM no tenías acceso directo a la GPU, tenías que volver a pasar por JS, supongo que con el tiempo le irán adicionando API. Ahí seguramente veamos videojuegos AAA o algunas cosas más locas en la web, como plataforma me parece la más avanzada y hasta diría que quien termine el reinado de las instalables ya que también hay API para caché (así se instalan las PWA), van a tener que mover mucho. De todas formas es un presentimiento mío, depende de cómo se termine vendiendo y las vueltas de la gente
De hecho se esta haciendo, es una gran ventaja el tamaño a la hora de distribuir, además el mismo runtime es sandbox, es bastante cercano a lo que seria Docker.
Con Rust es automagico te diria, al compilar codigo Rust el mismo compilador te da la opción de compilar a WASM, no necesitas una herramienta adicional. A diferencia de otros lenguajes Rust esta muy pensado para que todo lo que escribas no necesite un OS en si mismo, puedes tenerlo pero no es obligatorio en muchos casos. Rust al igual que C y C++ es uno de los candidatos perfectos para aprovechar todas las ventajas de WASM, diria que el catalogo de librerias es un 90% compatible con WASM por default.
Yo diría que más que como un contenedor es en realidad similar al cil de . Net, creo en realidad técnicamente dista de las jaulas chroot y se parece a ellas solo en el planteamiento del sandbox, el resto es casi una analogía del cil de .net en el browser.
Che Pelado, estuve buscando mucho por github y no encuentro que wasm soporte lenguages interpretados como python. Y claro como buen machine learning engineer, todo lo codeamos en python. En resumen, Hay alguna manera de compilar python y hacer que corra en wasm? Estas fachero pela crack idolo
Entiendo tu punto, completamente. Pero tengo dudas con el alcance que puede tener una aplicación que hace uso de las apis del sistema operativo. Eso está bastante alejado del Hello World, aunque seguramente eso ya está resuelto, y se trata de una tecnología para un uso muy particular. En cuanto a las aplicaciones web con WASM, estas suelen tener el "kernel" de la aplicación en WASM, que se descarga completamente en el navegador del cliente, y se sustituye la UI nativa por HTML, realmente, la UI importa poco. Este tipo de aplicaciones demoran más en cargarse, pero se ejecutan notablemente más rápido. Gracias Pelado!!! Ahora tengo algo más para aprender 😂
Es que nunca nunca nunca se usa la imagen del compilador como imagen final. Haces un build a dos pasos con la imagen con el compilador y luego copias binarios y ld hacia un Scratch o debían Slim mínimo... quedando imágenes con el compilado de 5mbs-100mbs Igualmente ese "far away from native speed" no se entiende. Una vez inicializado el filesystem todo funciona igual que en el host...
IMPRESIONANTE!!!!, Like por el video 👌👌👌, pero Dislike porque no hay camisa con sticker en el video de hoy, propongo algo como "Lost Children Will Be Taught The C Programming Language"
Si entendí correctamente, emcc compila a un objeto WASM binarios de C/C++. ¿Qué herramientas se pueden utilizar para generar artefactos WASM para otro tipo de lenguajes? (i.e: python, golang, c#, ....)
En el caso de Rust el mismo compilador se le puede indicar que se quiere un WASM y te da el resultado final. Diria que el 90% de las librerias de Rust son compatibles con WASM, eso no pasa en todos los lenguajes.
Más que compararlo con docker estaría bien compararlo con Java. A finales de los 90 Sun Microsistema nos taladro a todos la cabeza con el build once run anywhere de java. Wasm es una máquina virtual sin lenguaje, lo cual se agradece.
para una nueva version de pwa, pregunto: que pasa si tengo que hacer una actualizacion del software, tengo que reconstruir wasm en docker simplemente con dar un reset tendria la nueva version pero que interesante propuesta quien estará detras de este proyecto alguien quien su sustema operativo no es GNU/Linus o Mac, saludos desde la bella Guatemala, perdon uso docker y por el momento estoy muy contento con este
Docker no es malo en si mismo, tiene sus casos, pero Solomon Hykes en su momento (creador de Docker) dijo que si hubiera existido WASM/WASI en su momento el no hubiera creado Docker porque es justo lo que queria. Con respecto a las actualizaciones lo unico que necesitarias seria un registry, en este caso podria ser DockerHub, seria cuestión de subir tu imagen allí.
Muchas de las cosas que explicas no son correctas. No me malinterpretes, está bien divulgar estas nuevas tecnologías y es cierto que wasm parece que será el futuro... pero hay que ser rigurosos. Lo comento sin ánimo de ofender, solo por completar un poco la info y evitar el malentendido a quien le interese leer el comentario. Los programas no ocupan más en docker, otra cosa es que por comodidad no optimices la imagen y prefieras basarte en otra que viene cargadita de librerías y programas de sistema... pero puedes compilar ese mismo programa de ejemplo que pones con musl y ejecutarlo en scratch, ocupando seguramente menos de 1Mb (que es más que el wasm, pero claro, el runtime del wasm no va incluido). Si necesitas meter librerías porque tu programa las necesita si o si, el tamaño de la imagen crecerá, claro, pero también lo hace de igual manera el wasm si metes esas mismas librerías (suponiendo que sean compatibles, porque claro, algo que no mencionas es que para llevar un programa a wasm casi siempre tendrás que hacer código a medida, y las librerías que uses también deben de ser compatibles.) Tampoco es cierto que wasm sea más rápido que docker. Una imagen bien optimizada con solo un programa en nativo dentro, arranca antes que un wasm, que hay que compilar JIT, y además con optimizaciones de hardware, que posiblemente hagan que el programa vaya más rápido durante el resto de la ejecución. Además, si hablamos de tecnologías de contenerización , y esto es ya opinión mía, mencionar Docker vs WASM para comparar las dos "olas", es pasar de largo tecnologías de la "anterior ola" que cubren muchos de los puntos débiles de Docker. Recordemos que hay alternativas como podman que ni siquiera necesitan un demonio que gestione la ejecución ni tienen problemas de seguridad inherentes a la ejecución como root.
Dejo mis 2 centavos, WASM/WASI son una maravilla, ya he visto empresas que lo usan tanto para deployar backend como para hacer aplicaciones frontend y de escritorio. Salesforce implemento hace poco algo similar a Envoy y todos los plugins que tienen a capa de red funcionan con WASM. Si usas Telegram en el navegador e inspeccionas la red saldra que se carga mucho WASM. Solomon Hykes dijo una vez hace como 5 años que si hubiera existido WASM/WASI el no hubiera creado Docker, yo creo que tiene sentido lo que dijo. Permite hacer cosas muuy portables, sencillas, poco peso y con restricciones de seguridad sin virtualizar nada. Como dijiste en el video son multi architecture por defecto, lo que no es así es el runtime. Además permite darle nueva vida a proyectos C, C++ y Rust, sobre todo porque desde todos los runtimes de JS (Deno, Bun, Node, el navegador) se le esta dando soporte para ejecutarse. No quiere decir que desaparezca Docker o algo así, sino que se van a adaptar para que por ejemplo los pods puedan ser compatibles con WASM por ejemplo.
En aquel momento ya existían la JVM y el CLR que son análogos a WASI, así que no entiendo por qué "no hubiera creado Docker"... una puntualización, Docker no virtualiza, sólo aisla procesos.
@@alicewyanHay algunas ventajas que no se tienen en cuenta, algunas las dices en lo que dices. JVM y CLR no aislan, son relativamente ligeras pero pueden tener problemas, el caso de CLR por ejemplo da soporte parcial en OS fuera de Windows. Es verdad que JVM puede tener puntos de comparación pero la realidad es que era muucho más pesada, tiene cosas adicionales, GC y muchos estandares de Java por poner ejemplos, varia mucho dependiendo la versión que se utilice. Y además de eso el Bytecode sigue siendo menos eficiente que el codigo WASM. Por otro lado Docker no virtualiza como dices, también puede ser más pesado que la JVM y CLR, pero como consigue eso de aislar? Docker no virtualiza pero usa componentes que si requieren la virtualización, por eso si desactivas la virtualización de la BIOS Docker no funciona, creo que daba un mensaje de error el hypervisor
@@PhosphorusMoscu-code en Windows y macOS requiere virtualización porque necesita ejecutar una VM con Linux, pero ejecutándo nativamente no lo requiere. Aisla con mecanismos del kernel: chroot para el sistema de archivos, espacios de nombres para los procesos, y cgroups para definir los permisos de cada proceso. Por otro lado, la JVM es mucho más grande que un runtime de wasm típico, pero tiene mucha más funcionalidad. Sería una comparación más realista comparar la JVM con el navegador donde vas a ejecutar las aplicaciones wasm, y en este caso el navegador es muchísimo más pesado que el JRE completo. Si desactivas las opciones que no necesitas de la JVM y eliminas las clases que no vas a utilizar, se puede reducir también a un runtime minúsculo (tan pequeño que es capaz de correr en una tarjeta SIM).
Tiene potencial! Aunque si su principal ventaja es correr en diferentes plataformas e imágenes más livianas… con buildx y multistage ya lo teníamos. Pero dejemos que siga avanzando ❤
Es como el JVM de java. De el lado del servidor va a servir si de alguna manera se hace estándar y la gente empieza a construir cosas útiles con él. Sino solo va a quedar para el cliente.
hola pelado nerd puedes ayudarme en algo necesito agregar uuna variable en yaml de external secrets y al momento de daarle apply se va a crear el secrets ahora quiero que en ese secrets se cree la variabale es para una base de dato y necesito que sea multinamico ya que tengo muchas bases de datos porfa si alguien me puede ayudar porfa.
Un año esperando este video. "Gracias Pelado", tengo varias app migradas a WASM usando Tiny Golang y se ve claro que el camino es "WebAssembly", pienso que en los proximos años usaremos compiladores y framework que automaticamente generaran el compilado es WASM y sera trasparente para el desarrollador o la plataforma. ;)
Yo veo mucha utilidad en aplicaciones PWA con WASM (cliente) consumiendo lo necesario via API y otros servicios, tambien es la puerta a multiplataforma.
En mi experiencia: Rust y Kotlin tienen muy buena compatibilidad para WASM y ya llevan algunos años en prod… seguramente este sea el futuro del serverless por qué es básicamente lo mismo pero esta vez de forma Edge
Recuerdo hace 20 años en la universidad la revolución que fueron las JVM, build once run everywhere... Tambien Web Assembly no despegaba pero finalmente lo hara ... Que chingon
En la imagen de C estas incluyendo el compiler y buildeando el codigo, para despues ejecutarlo. Podrias simplemente copiar el binario y traer una imagen de un OS con lo minimo necesario para correr dicho binario.
Es lo que dijo con el multistage
Hay un error conceptual muy grande que no es relevante en el tiempo de ejecución que es lo que se dice en el video en 11:25. Un binario de docker es NATIVO desde la conceptualización del conteiner, mientras que en WASM hay un interprete que es una máquina virtual de webassembly.
El código que se genera en WASM es como el código que se genera en JAVA, un binario que se ejecuta en una máquina virtual arriba de la plataforma. Es una idea vieja y está muy optimizadoya que creo que lo utilizan hace un tiempo los compiladores internos del estandar ECMA en los navegadores (no estoy absolutamente seguro).
Entonces ¿porque resulta más rápido ejecutar una app wasm que en docker? por el entorno, dado que docker tiene que hacer una inicialización que wasm no necesita, pero si tenemos una aplicación muy grande escrita en wasm y la misma en C y tiene que hacer por ejemplo cálculo que no requieren interface con el sistema sospecho que se invertiran los resultados, porque C es compila a código assembly de la plataforma destino muy óptimo, por eso en docker es necesario especificar si es para x86, ARM, etc. En definitiva desde el tema speed es discutible y hay que afilar, pero la palabra NATIVA es acá lo incorrecto porque el binario generado en WASM es intérprete y no es nativo y en docker la aplicación es compilada y es nativa al entorno objetivo. Si se usa alpine en C con musl no sería extraño que le pase el trapo a wasm, pero no por mucho (siempre si hablamos de código pequeño, en aplicaciones de HPC habría que investigar) y para el caso del ejemplo creo que se puede hacer en unos pocos megas.
Gracias a wasam existe blazor y es de las cosas más bonitas que me han pasado como desarrollador C#, pude empezar mi propio emprendimiento de desarrollo de software, todo con solo C#
compila C# a WA en forma automática? sin intervención?
@@claudiojlf Si, escribes todo en C#, front y back, y corre joya, ahora mas, en net8, con el nuevo metodo de blazor
@CesarLP96 Hasta ahora, no he tenido ningun problema y con net8, aun mejor, mezclaron los dos tipos de blazor, wasam y server en uno solo
gracias tío por la info, estoy tan lleno de cosas que no llego a estos temas de webassembly, a la final será un intermediario pero que quizás nunca programaremos en él sino lo utilizaremos como herramienta y ya está
Pero hombre, son dos conceptos completamente diferentes.
Es un lenguaje de bajo nivel que está soportado en el navegador y node.
La eficiencia es muy alta porque tiene su propio sub entorno en el navegador.
Lo otro son máquinas emuladas, nada que ver...
Esta muy interesante WASM, pero no todo es compilable a WASM. Si tu aplicacion esta en c++ es candidato, pero no tiene la amplitud que tiene Docker u otras tecnologias de contenedores de poder "correr" cualquier aplicacion de cualquier lenguaje. Incluso para ser mas justo con la comparativa que propones From Skratch de wasm, yo hubiese hecho un multi-stage buildean con Docker From gcc y creando una imagen From Skratch solo con el binario de salida de gcc que seria practicamente igual de liviana de WASM. Desde mi humilde opinión veo a WASM como una evolución de lo antes era un Java Applet
Ya dijo que iba a hacer un video posterior eso que decis.
Muy buen video!!! Si bien docker permite entre otras cosas encapsular tu aplicación y hacer uso de puertos,volúmenes, etc quizá para el caso de uso de desarrollo web se ve súper pontente!!!
Pelado sos una bestia, inconmensurable, impresionante! Gracias por tanto
Dicho esto, salchicha voladora: esa forma de funcionar de wasm me hace acordar a la jvm
Agnóstico por naturaleza. Hermoso
No entendí la comparacion, Docker principalmente es para empaquetar sistemas completos, WASM más bien es un entorno de ejecución como la JVM no puedes tener un sistema para construir tu aplicación empaquetado en WASM o si?
Solo está comparando en base a lo que la gente dice, se enfoca al target de lo que ambos pueden hacer a nivel de navegador, es decir wasm puede correr código en navegadores y puede servirte aplicaciones para ser consumidas en navegadores, nunca dijo que sirvan los dos para lo mismo.
En realidad si se puede. Es verdad que vas a necesitar un runtime, algo similar a Docker Engine, pero dentro de eso puedes hacer si quieres un filesystem identico, no es necesario pero si quieres podrias compilar Linux a WASM.
Piensalo más bien como una runtime para ejecutar codigo cercano al binario, hay runtimes que no necesitan un OS propio, creo que Wasmer por ejemplo tiene una forma de ejecutar codigo sin OS.
lo veo excelente del lado del frontend, pero para aplicaciones back no se tengo mis dudas habria que comprobar rendimientos, pero pues es lo que hace la virtual machine de java eso si con compatiblilidad para varios lenguajes, seria interesante si sacaran un lenguaje universal intermedio tal vez sea wasm toca ver como se desarrolla
Gracias por el video, muy interesante, me gustaría saber si haz hecho pruebas con algo mas complejo, por ejemplo una app en Java o .Net con UI, como WASM trabaja con la experiencia de usuario y dado que estos lenguajes son interpretados como se genera el ensamblado y las dependencias, supongo que en este escenario el tamaño del archivo si va a ser mayor.
Lo tenia guardado este video para ver ...y ayer me comentaron que WASM ...remplazaría a Docker en el futuro (what ???) . Partiendo que el nombre que le pusieron apesta WASM WASI??? mamita ...mas alla de las ventajas que pueda tener sobre Docker ....el ecosistema que tiene Docker desde su creación es enorme hasta su integración en Kubernetes...y es una herramienta que funciona y funciona muy bien....y pensar (WASM ???) que esto lo pueda reemplazar ...ni empedo!!! ... Quizas se pueda acomplar en una parte del ecosistema de Docker (Development) y darle a docker más versatilidad aún de la que tiene.....pero reemplazarlo ...no me lo imagino ...Gracias @Pablo por siempre trayendonos última tecnogía . Abrazo groso!!!
Hacer el final largo... esta genial !!!! felicidades BRO
WebAssembly es un runtime, no digas que es un sistema de contenedores porque vas a liar a chicos que están empezando en la informática y te siguen.
Si vieses el video, te darías cuenta que eso queda claro.
Si esta contenirizando la aplicación. Docker es más completo y puede usarlo como backend
Hace apenas un par de años Docker agregó un nuevo runtime para correr contenedores de wasm, podman desde sus inicios siempre ha permitido correr contenedores de wasm, aquí podman lleva la delantera, en integración
thaks for the livestreaming this would be 24/7 in different topics
Las aplicaciones de Go se pueden ejecutar en contenedores sin usar una imagen base por lo que las imagenes pesan lo que pese el garbage colector. Si mal no recuerdo figma supero a adobexd por wasm
Como siempre me acabas de alegrar el día, gracias por todo Pelado
Recien ví este video, algo que pasa en Docker es que hay muchos CVE relacionados a dependencias (librerías, componentes base de linux, openssl por ejemplo) que fuerzan a que uno haga un update del contenedor, controlar la base de donde sale la misma, etc. ¿Cómo se aplica esto al archivo wasm?
Gran vídeo pelado!!! Gracias, saludos desde España 🇪🇸
Que bueno dos tecnologias que se complementas Gracias Pelado por este video
Me encanto el video. No dude ni un segundo en suscribirme.
No entiendo mucho pero, se puede correr cualquier app? Solo depende del compilador?
Es un título muy pretencioso
Hola, gracias, justo estaba viendo el tema de para experimentar con WASM
Muchas gracias! muy util el vídeo! Veremos como evoluciona esta tecnología pero me parece muy interesante
Excelente, al hacerlo con un binario se podria hacer con GO tambien, es interesante. En este caso, que tanta es la diferencia de performance en el navegadpr? Como podriamos hacer un benchmark de esto? Esta muy interesante, buen video!
Creeria que tiene algo de diferencia, el navegador es un runtime más complejo que para informar cosas por consola estoy seguro que tiene que serializar e informar mediante una API de JS.
Sigue siendo mejor que la opción de usar JS si lo que buscas es performance pero bueno, existe esa diferencia entre runtime dentro y fuera del navegador.
Por otro lado estan disponibilizando más APIs con el paso del tiempo. WASM tiene una desventaja que es que no provee garbage collector.
Tu podrías usar Go pero a diferencia de C, C++ y Rust el GC va a tener un costo adicional y en web el tiempo de carga suele influir, sobre todo por como gestiona los recursos el navegador.
@PeladoNerd, llamame loco, pero no veo el boton de "Guardar" para poder añadir tu video a "Ver mas tarde". No sé si es un error o es intencionado, pero para mi es esencial :')
Gracias!
Espero que la adopción de WASM se extienda y se convierta en estándar. Así cada uno con el lenguaje que más lenguste y que se compile a casi nativo :)
Ojo! Que sea nativo no significa que de los mismos beneficios, la mayoría de proyectos hechos en WASM son en C, C++ y Rust por el tema de que uno de los puntos fuertes era poder re utilizar codigo nativo del lado del navegador.
El tema es que en el navegador se castiga el tamaño de los binarios y WASM no tiene Garbage Collector en si. Cuando compilas otros lenguajes se incluye el GC justamente por ese motivo, entonces los binarios terminan teniendo un rendimiento similar al original, no seria taan cerca al binario, sin embargo tienes una performance identica.
Pero Kubernete ya soporta wasm? Que crees de podman y openshift?
Muy interesante video. Ésto me recordó otra tecnología que también es un salto en el paradigma, en este caso, de PHP. Me refiero a FrankenPHP. Con tu estilo creo que saldría un buen video que quedará como referencia. Te animo a hacerlo cuando sea posible (si no lo has hecho aún). Saludos!
increible como evoluciona todo esto que fantastico, no tiene limites !!!
Ahora quiero probar WASM y una torta de naranja. Gracias
"construir", Pelado, construir no "buildear". Muy lindo todo
Yo lo que quiero es que web assembly tenga acceso al DOM, para ver si podemos librarnos de Javascript como unico lenguaje del navegador y hacer a la web language agnostic
Genial explicación, eres El Crack como siempre
lo interesante seria acceder a funciones nativas del sistema operativo ya que es un codigo binario en C por ejemplo listar las impresoras instaladas para mandar a imprimir directamente desde el navegador, entiendo que no se puede debido a restricciones del mismo navegador web.
No es exactamente binario pero si, los runtimes de WASM proveen de alguna forma acceso a hardware.
El navegador es un runtime mucho más restringido pero debe de tener algunos casos, por ejemplo si necesitas usar la GPU desde el navegador estan estabilizando esa API en todos los navegadores.
¡Enhorabuena por tus vídeos! ¿No recuerda esto al concepto de JVM? WASI parece una JVM en esteroides
Es un poco eso, WASM en realidad no es un compilado final final, se dice que es cercano al binario pero puedes leerlo si te interesa, son prácticamente instrucciones bytecode.
¿Donde consigo un curso de WebAssembly?
Cada día estas más fachero pela gracias por el video sos crack.
Para cuando el video de NIX y NixOS?
Doom en wasm pa cuando?
Estaba pensando lo mismo 😅
ruclips.net/video/nnQ-6eAfWuw/видео.htmlsi=NV1YtDfBcdJKZld9
Que manera de reirme con el final 😂😂😂😂😂
Bienvenido al año 1995 cuando Sun/java aparecía con sus applets y java web start con su protocolo JNLP
Un genio Pelado, me encanto el video.
WASM no es lo mismo que solo web assembly. WASM es web assembly system modules. WASM es precisamente (aunque sobresimplifico) para que web assembly salga del mundo del navegador.
Pelado me estás queriendo decir que ya no necesito un hosting?
Se viene Cobol a la web? 😊
WASI también soporta un GC genérico, igual no se compara a los contenedores, sino a una app compilada, incluso podes correr un server de .NET en el navegador (sí, el server dentro del browser).. Lo vengo usando hace rato para cosas de high performance como IA dentro del browser, no reemplaza ni a docker ni a JS, lo complementa en performance. Me pondría cachondo verlo con docker compose jajaja
Ojo, si usas WASM en el navegador tiene una gran ventaja, WASM en los ultimos meses, se estaba trabajando para darle una API nativa a WebGPU desde el lado de WASM.
Entiendo que con esa API ya no tienes cuello de botella. Antes se hacia WASM se serializaba -> Se comunicaba con JS -> Js se comunicaba con WebGPU -> enviaba esa información a WASM.
Era ineficiente, esta nueva API va a potenciar mucho a WASM en el navegador, quizas para IA por dar un caso.
@@PhosphorusMoscu-codenaturalmente, desde WASM no tenías acceso directo a la GPU, tenías que volver a pasar por JS, supongo que con el tiempo le irán adicionando API. Ahí seguramente veamos videojuegos AAA o algunas cosas más locas en la web, como plataforma me parece la más avanzada y hasta diría que quien termine el reinado de las instalables ya que también hay API para caché (así se instalan las PWA), van a tener que mover mucho. De todas formas es un presentimiento mío, depende de cómo se termine vendiendo y las vueltas de la gente
todo esto tiene sentido para mac y windows, pero linux tiene docker nativo, es instantáneo y bien realizada la imagen puede ser únicamente el binario.
El tiempo de arranque con respecto a un contenedor docler tradicional es mucho mejor? Suena interesante para montar una arquitectura serverless.
De hecho se esta haciendo, es una gran ventaja el tamaño a la hora de distribuir, además el mismo runtime es sandbox, es bastante cercano a lo que seria Docker.
Ya… y? Alguna ventaja sobre Java applets? Es más seguro? Recordando que los JAR fueron descartados por ser la muerte…
Qué clase de brujería es esta. Esta excelente, me gustaría revisar cómo funciona con rust. Buen Video!
Con Rust es automagico te diria, al compilar codigo Rust el mismo compilador te da la opción de compilar a WASM, no necesitas una herramienta adicional.
A diferencia de otros lenguajes Rust esta muy pensado para que todo lo que escribas no necesite un OS en si mismo, puedes tenerlo pero no es obligatorio en muchos casos.
Rust al igual que C y C++ es uno de los candidatos perfectos para aprovechar todas las ventajas de WASM, diria que el catalogo de librerias es un 90% compatible con WASM por default.
Yo diría que más que como un contenedor es en realidad similar al cil de . Net, creo en realidad técnicamente dista de las jaulas chroot y se parece a ellas solo en el planteamiento del sandbox, el resto es casi una analogía del cil de .net en el browser.
impresionante! parece tener potencial. saludos desde Polonia.
Che Pelado, estuve buscando mucho por github y no encuentro que wasm soporte lenguages interpretados como python. Y claro como buen machine learning engineer, todo lo codeamos en python. En resumen, Hay alguna manera de compilar python y hacer que corra en wasm?
Estas fachero pela crack idolo
Entiendo que tendria que SER compilado no interpretado
Ese final maravilloso XD
Entiendo tu punto, completamente. Pero tengo dudas con el alcance que puede tener una aplicación que hace uso de las apis del sistema operativo. Eso está bastante alejado del Hello World, aunque seguramente eso ya está resuelto, y se trata de una tecnología para un uso muy particular.
En cuanto a las aplicaciones web con WASM, estas suelen tener el "kernel" de la aplicación en WASM, que se descarga completamente en el navegador del cliente, y se sustituye la UI nativa por HTML, realmente, la UI importa poco.
Este tipo de aplicaciones demoran más en cargarse, pero se ejecutan notablemente más rápido.
Gracias Pelado!!! Ahora tengo algo más para aprender 😂
Es que nunca nunca nunca se usa la imagen del compilador como imagen final.
Haces un build a dos pasos con la imagen con el compilador y luego copias binarios y ld hacia un Scratch o debían Slim mínimo... quedando imágenes con el compilado de 5mbs-100mbs
Igualmente ese "far away from native speed" no se entiende. Una vez inicializado el filesystem todo funciona igual que en el host...
Eso atrás a la derecha es un lightsaber? No lo había notado!!
Me encanta docker: es la forma más profesional de instalar jitsi, para poder re-instalar en caso de necesidad 👍🏽
Pero si usa muchos gigabytes
IMPRESIONANTE!!!!, Like por el video 👌👌👌, pero Dislike porque no hay camisa con sticker en el video de hoy, propongo algo como "Lost Children Will Be Taught The C Programming Language"
excelente gracias, sencillo y práctico
Funciona para el lenguaje natural de software Ag y adabas?
Gracias
Si entendí correctamente, emcc compila a un objeto WASM binarios de C/C++. ¿Qué herramientas se pueden utilizar para generar artefactos WASM para otro tipo de lenguajes? (i.e: python, golang, c#, ....)
blazor, utilizas c#
En el caso de Rust el mismo compilador se le puede indicar que se quiere un WASM y te da el resultado final.
Diria que el 90% de las librerias de Rust son compatibles con WASM, eso no pasa en todos los lenguajes.
seria interesante comparar esto con los applets Java o el Actionscript de Flash...
por ejemplo si tengo mi archivo hola.wasm como lo puedo desencriptar
Más que compararlo con docker estaría bien compararlo con Java. A finales de los 90 Sun Microsistema nos taladro a todos la cabeza con el build once run anywhere de java. Wasm es una máquina virtual sin lenguaje, lo cual se agradece.
y la seguridad?
Desde cuando necesitas el compilador para correr un programa en c
¿me pueden recomendar alguna documentación y/o programa para auditar nginx?
de pela a pela, se puede kubernetear?
Muchas gracias por tu contenido
para una nueva version de pwa, pregunto: que pasa si tengo que hacer una actualizacion del software, tengo que reconstruir wasm en docker simplemente con dar un reset tendria la nueva version pero que interesante propuesta quien estará detras de este proyecto alguien quien su sustema operativo no es GNU/Linus o Mac, saludos desde la bella Guatemala, perdon uso docker y por el momento estoy muy contento con este
Docker no es malo en si mismo, tiene sus casos, pero Solomon Hykes en su momento (creador de Docker) dijo que si hubiera existido WASM/WASI en su momento el no hubiera creado Docker porque es justo lo que queria.
Con respecto a las actualizaciones lo unico que necesitarias seria un registry, en este caso podria ser DockerHub, seria cuestión de subir tu imagen allí.
Se podrá compilar un vb5 en wasm?
Muchas de las cosas que explicas no son correctas. No me malinterpretes, está bien divulgar estas nuevas tecnologías y es cierto que wasm parece que será el futuro... pero hay que ser rigurosos. Lo comento sin ánimo de ofender, solo por completar un poco la info y evitar el malentendido a quien le interese leer el comentario.
Los programas no ocupan más en docker, otra cosa es que por comodidad no optimices la imagen y prefieras basarte en otra que viene cargadita de librerías y programas de sistema... pero puedes compilar ese mismo programa de ejemplo que pones con musl y ejecutarlo en scratch, ocupando seguramente menos de 1Mb (que es más que el wasm, pero claro, el runtime del wasm no va incluido).
Si necesitas meter librerías porque tu programa las necesita si o si, el tamaño de la imagen crecerá, claro, pero también lo hace de igual manera el wasm si metes esas mismas librerías (suponiendo que sean compatibles, porque claro, algo que no mencionas es que para llevar un programa a wasm casi siempre tendrás que hacer código a medida, y las librerías que uses también deben de ser compatibles.)
Tampoco es cierto que wasm sea más rápido que docker. Una imagen bien optimizada con solo un programa en nativo dentro, arranca antes que un wasm, que hay que compilar JIT, y además con optimizaciones de hardware, que posiblemente hagan que el programa vaya más rápido durante el resto de la ejecución.
Además, si hablamos de tecnologías de contenerización , y esto es ya opinión mía, mencionar Docker vs WASM para comparar las dos "olas", es pasar de largo tecnologías de la "anterior ola" que cubren muchos de los puntos débiles de Docker. Recordemos que hay alternativas como podman que ni siquiera necesitan un demonio que gestione la ejecución ni tienen problemas de seguridad inherentes a la ejecución como root.
Con esto ¿sería posible correr una aplicación exe con wasm en un contendedor y que al final se pueda ver la ejecución del exe en el navegador? 😮
IMPRESIONANTE
Tiene muy buena pinta
Dejo mis 2 centavos, WASM/WASI son una maravilla, ya he visto empresas que lo usan tanto para deployar backend como para hacer aplicaciones frontend y de escritorio.
Salesforce implemento hace poco algo similar a Envoy y todos los plugins que tienen a capa de red funcionan con WASM.
Si usas Telegram en el navegador e inspeccionas la red saldra que se carga mucho WASM.
Solomon Hykes dijo una vez hace como 5 años que si hubiera existido WASM/WASI el no hubiera creado Docker, yo creo que tiene sentido lo que dijo.
Permite hacer cosas muuy portables, sencillas, poco peso y con restricciones de seguridad sin virtualizar nada.
Como dijiste en el video son multi architecture por defecto, lo que no es así es el runtime.
Además permite darle nueva vida a proyectos C, C++ y Rust, sobre todo porque desde todos los runtimes de JS (Deno, Bun, Node, el navegador) se le esta dando soporte para ejecutarse.
No quiere decir que desaparezca Docker o algo así, sino que se van a adaptar para que por ejemplo los pods puedan ser compatibles con WASM por ejemplo.
En aquel momento ya existían la JVM y el CLR que son análogos a WASI, así que no entiendo por qué "no hubiera creado Docker"... una puntualización, Docker no virtualiza, sólo aisla procesos.
@@alicewyanHay algunas ventajas que no se tienen en cuenta, algunas las dices en lo que dices.
JVM y CLR no aislan, son relativamente ligeras pero pueden tener problemas, el caso de CLR por ejemplo da soporte parcial en OS fuera de Windows.
Es verdad que JVM puede tener puntos de comparación pero la realidad es que era muucho más pesada, tiene cosas adicionales, GC y muchos estandares de Java por poner ejemplos, varia mucho dependiendo la versión que se utilice.
Y además de eso el Bytecode sigue siendo menos eficiente que el codigo WASM.
Por otro lado Docker no virtualiza como dices, también puede ser más pesado que la JVM y CLR, pero como consigue eso de aislar? Docker no virtualiza pero usa componentes que si requieren la virtualización, por eso si desactivas la virtualización de la BIOS Docker no funciona, creo que daba un mensaje de error el hypervisor
@@PhosphorusMoscu-code en Windows y macOS requiere virtualización porque necesita ejecutar una VM con Linux, pero ejecutándo nativamente no lo requiere. Aisla con mecanismos del kernel: chroot para el sistema de archivos, espacios de nombres para los procesos, y cgroups para definir los permisos de cada proceso.
Por otro lado, la JVM es mucho más grande que un runtime de wasm típico, pero tiene mucha más funcionalidad. Sería una comparación más realista comparar la JVM con el navegador donde vas a ejecutar las aplicaciones wasm, y en este caso el navegador es muchísimo más pesado que el JRE completo. Si desactivas las opciones que no necesitas de la JVM y eliminas las clases que no vas a utilizar, se puede reducir también a un runtime minúsculo (tan pequeño que es capaz de correr en una tarjeta SIM).
Pregunta al pelado mas pelado, WASM aplica solo a C? Se puede usar con otros lenguajes compilados o interpretados? Mil gracias!
gracias por este video
Genial !
¡que interesante!
Próximamente, Minecraft en el navegador
Muy Bueno!!!!
Docker es mucho más escalable que WASM. Solo utilizaría WASM para cosas muy específicas.
Tiene potencial! Aunque si su principal ventaja es correr en diferentes plataformas e imágenes más livianas… con buildx y multistage ya lo teníamos.
Pero dejemos que siga avanzando ❤
Es como el JVM de java. De el lado del servidor va a servir si de alguna manera se hace estándar y la gente empieza a construir cosas útiles con él. Sino solo va a quedar para el cliente.
hola pelado nerd puedes ayudarme en algo necesito agregar uuna variable en yaml de external secrets y al momento de daarle apply se va a crear el secrets ahora quiero que en ese secrets se cree la variabale es para una base de dato y necesito que sea multinamico ya que tengo muchas bases de datos porfa si alguien me puede ayudar porfa.
Brutal!
Pela, solo me estás dando más ganas de aprender Rust jejejeje
Esto es magia
Crear el contenedor usando el compilador hace que la comparacion sea injusta, comparando peras con manzanas 🤔
7:55 Ya terminó de Compilar-C (:trollface:)
me puedes porfavor compilar mi cv en C tambien?