5 ms·

WASM will be ready when GNU Hurd succeeds in running the desktop linux of the year. Already 10 years since WASM ... HTML, CSS and JavaScript all had a huge infl

WASM will be ready when GNU Hurd succeeds in running the desktop linux of the year. Already 10 years since WASM ... HTML, CSS and JavaScript all had a huge influence. WAS simply has not done so yet.

boomskats 2mo ago
Ready for what? WASM is already running in production at a whole bunch of financial services orgs and government infra. The thing is, it's not running anywhere near HTML, CSS or JavaScript. It's running serverside, mostly on Wasmtime - which, as it happens, is what this post is all about.
- troupo 2mo ago
  why.... why would financial services orgs and government infra run anything on wasm serverside?
  - boomskats 2mo ago
    It's lightweight, capability-secured, services start up way faster, smaller overhead than VMs, better isolation than containers, faster replication, etc. The original Wasmtime 1.0 blog post explains it all really well: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...
- alex_suzuki 2mo ago
  > it's not running anywhere near HTML, CSS or JavaScript There’s plenty of usage in the browser environment as well, plenty of client-side SDKs for things like e.g. video editing, barcode scanning, etc. use it.
torginus 2mo ago
Yeah, WASM has been a disappointment, and I guess there's a good reason for that. If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead. Native Client, which ran native x86 (but statically verified) code in the browser, basically fit all the criteria, except it wasn't platform agnostic. I'm not married to their approach, but I refuse to believe that this can't be done in a safe and peformant manner. I guess WASM turned out to be a sandbagging rather than sandboxing technology. But I eagearly await the arrival of concern trolls who can explain why WASM is slower than JS, and why native threading support is impossible to do securely without imposing limitations, that made sites like itch turn it off, so it might as well not exist.
- hypendev 2mo ago
  > If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead. Working on that! I'm building hypen.space which is platform agnostic language & SDK for building native crossplatform apps. It's a WASM engine at it's core, and while currently it doesn't have "package this app as wasm" capability but supports streaming/local apps only, that capability is currently being developed - together with WASI layers for all of the platforms. That way your app can run either as a browser (DOM) app, browser canvas app, native desktop or native mobile app. It's still early, but moving fast - I just added accessibility support, and the animation framework will be out this week. Regarding the WASM disappointed, when I started building this about 6 years ago, WASM was in a terrible (barely usable without wasting a ton of time) state. Now that WASI 0.3 is out and LLMs have sped up development by a large margin, it's in a quite usable state to ship things to production without fear.
  - mckee_plus_plus 2mo ago
    Crediting LLMs with advancing wasm is a disservice to the best-in-industry bytecodealliance community & org.
    - hypendev 2mo ago
      You might have misread me - I meant in a time when LLM's are speeding up development in general, as now you can write giant interfaces and implementations without having to manually deal with glue code.
- ttd 2mo ago
  There's a big gap between WASM has issues/limitations, and WASM "might as well not exist." NaCL was also Chrome-only IIRC, whereas WASM is a successful web standard (no small feat).
  - pjmlp 2mo ago
    PNaCL was published with a standard and tooling, it was Mozzilla that refused to adopt it, and push asm.js instead. Ironically, if it was today, Google could have pushed PNaCL without any problem.
bobajeff 2mo ago
I'm not sure why people are claiming wasm isn't ready. It's just a compiler target like asm.js was. And that's been in use pretty much from the start when they got Unreal Engine, Unity, ffmpeg ported to it. Personally I've run Python + Sympy, Xcas/Giac and Maxima in the browser through this amazing tech.

WASM will be ready when GNU Hurd succeeds in running the desktop linux of the year. Already 10 years since WASM ... HTML, CSS and JavaScript all had a huge influence. WAS simply has not done so yet.

boomskats 2mo ago

Ready for what? WASM is already running in production at a whole bunch of financial services orgs and government infra. The thing is, it's not running anywhere near HTML, CSS or JavaScript. It's running serverside, mostly on Wasmtime - which, as it happens, is what this post is all about.

troupo 2mo ago
why.... why would financial services orgs and government infra run anything on wasm serverside?
- boomskats 2mo ago
  It's lightweight, capability-secured, services start up way faster, smaller overhead than VMs, better isolation than containers, faster replication, etc. The original Wasmtime 1.0 blog post explains it all really well: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...
alex_suzuki 2mo ago
> it's not running anywhere near HTML, CSS or JavaScript There’s plenty of usage in the browser environment as well, plenty of client-side SDKs for things like e.g. video editing, barcode scanning, etc. use it.

torginus 2mo ago

Yeah, WASM has been a disappointment, and I guess there's a good reason for that. If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead. Native Client, which ran native x86 (but statically verified) code in the browser, basically fit all the criteria, except it wasn't platform agnostic. I'm not married to their approach, but I refuse to believe that this can't be done in a safe and peformant manner. I guess WASM turned out to be a sandbagging rather than sandboxing technology. But I eagearly await the arrival of concern trolls who can explain why WASM is slower than JS, and why native threading support is impossible to do securely without imposing limitations, that made sites like itch turn it off, so it might as well not exist.

hypendev 2mo ago
> If WASM would've worked as advertised, allowing fully fledged apps to run easily and natively in the browser with no fuss and 90% native perf, then basically all app stores would've been dead. Working on that! I'm building hypen.space which is platform agnostic language & SDK for building native crossplatform apps. It's a WASM engine at it's core, and while currently it doesn't have "package this app as wasm" capability but supports streaming/local apps only, that capability is currently being developed - together with WASI layers for all of the platforms. That way your app can run either as a browser (DOM) app, browser canvas app, native desktop or native mobile app. It's still early, but moving fast - I just added accessibility support, and the animation framework will be out this week. Regarding the WASM disappointed, when I started building this about 6 years ago, WASM was in a terrible (barely usable without wasting a ton of time) state. Now that WASI 0.3 is out and LLMs have sped up development by a large margin, it's in a quite usable state to ship things to production without fear.
- mckee_plus_plus 2mo ago
  Crediting LLMs with advancing wasm is a disservice to the best-in-industry bytecodealliance community & org.
  - hypendev 2mo ago
    You might have misread me - I meant in a time when LLM's are speeding up development in general, as now you can write giant interfaces and implementations without having to manually deal with glue code.
ttd 2mo ago
There's a big gap between WASM has issues/limitations, and WASM "might as well not exist." NaCL was also Chrome-only IIRC, whereas WASM is a successful web standard (no small feat).
- pjmlp 2mo ago
  PNaCL was published with a standard and tooling, it was Mozzilla that refused to adopt it, and push asm.js instead. Ironically, if it was today, Google could have pushed PNaCL without any problem.

bobajeff 2mo ago

I'm not sure why people are claiming wasm isn't ready. It's just a compiler target like asm.js was. And that's been in use pretty much from the start when they got Unreal Engine, Unity, ffmpeg ported to it. Personally I've run Python + Sympy, Xcas/Giac and Maxima in the browser through this amazing tech.