WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?
Not owned by shit for brains Oracle.
Pay attention to WebAssembly
11–20 of 251 posts
Re: Pay attention to WebAssembly
#12I’m waiting for a Docker container with a WASM runtime. Wait, maybe someone’s already done that… /s PS - actually, originally I was being sarcastic, but there probably are some very good security use cases for it.
You joke, but this is a thing: https://krustlet.dev/
Re: Pay attention to WebAssembly
#13I’m waiting for a Docker container with a WASM runtime. Wait, maybe someone’s already done that… /s PS - actually, originally I was being sarcastic, but there probably are some very good security use cases for it.
This is Liam, co-founder of wasmCloud, founder of Cosmonic, and co-chair of the CNCF Cloud Native Wasm Day.
I don't think this is actually as crazy as it sounds - when we designed the messaging around CNCF, container, and WebAssembly we deliberately went with a better together story.
Why? In a large enterprises you have huge systems that each represent a variety of concerns - security, compliance, governance, reputation, etc, etc. These systems show up as stakeholders in software development like gates in CI/CD.
Starting with something like wasmCloud inside a container today lets enterprises leverage their existing benefits while still achieving _many_of the benefits of WebAssembly and wasmCloud. wasmCloud publishes docker containers, helm charts, and integrations with service mesh for that reason.
Start where your users are today and take them where you want to go.
Re: Pay attention to WebAssembly
#14WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?
> garbage collection
The draft WASM garbage collection proposal is partially implemented in Chromium, you can try it by enabling the enable-experimental-webassembly-features feature flag.
> DOM access
WebAssembly will never have direct access to the DOM, but at least with Rust the wasm-bindgen+web_sys crates make interacting with the DOM as simple as it is from JavaScript.
Re: Pay attention to WebAssembly
#15Re: Pay attention to WebAssembly
#16WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?
yep was my thoughts too, WASM solves some problems well. But it isn't and can't replace general containers like Docker does, for some specific workloads sure but not a general solution. And yeah i don't quite think everyone talking about WASM understands its not just 'faster javascript' but a totally different world where you have to for example, BYO GC (or manage memory yourself if you like!).
Re: Pay attention to WebAssembly
#17Re: Pay attention to WebAssembly
#18There are many things to love about WebAssembly, but let’s not forget it’s downsides. Like it’s threading model relies on Web workers and SharedArrayBuffers and is a royal pain in the … to work with. Not to mention that you’ll need to become COOP/COEP compliant to mitigate side-channel attacks.
Then there is the plain fact that it requires a compilation step, which is OK for large apps. But it makes me wonder if wasm really is the natural replacement for JavaScript in serverless cloud apps (aka “FaaS”).
So yes, WebAssembly has potential and is almost without an alternative for in-browser apps that do some heavy compute. But I am less convinced about server-side. Time and again, we’re told how great portability across architectures supposedly is. And time and again, the only cloud architecture that matters is x86-64. Maybe ARM or even RISC-V in some cases, but let’s not fool ourselves about these niche platforms.
Re: Pay attention to WebAssembly
#19I'm paying attention, but we are still in the hype phase.
"near-native performance" yeah a few seconds per hour. With all the jit and garbage collection, it's way too unreliable for anything that needs real-time performance and more than a pittance of CPU power.
Also, there's a canyon of difference between proper TensorFlow and its browser lite variant. Like the wasm backend chokes on 256x256 px background segmentation while xnnpack easily handles 200fps on CPU only.
For everything that can be inefficient, emscripten was already good enough. For stuff that needs efficiency, Wasm is not reliable enough yet.
Re: Pay attention to WebAssembly
#20WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?
* Already in all the browsers natively, without plugins or similar third-party optional components, and
* Already widely supported as a compilation target, and not just for special languages targeting the platform