[ramses0]

So..... think of it this way:

HTML was built for the "internet", but works just as well for plain local files (eg: file:///one.html => file:///two.html).

JS was added to HTML, and much gnashing of teeth ensued.

JS (minified), HTML (generated), CSS (compiled), Flash, Java Applets, etc... move away from the "original" internet (Hyper-Text DOCUMENTS) into Web2.0 "Apps" and Web3.0 "Walled Gardens".

What if instead of shipping `my_application.html`, we could ship `my_application.exe`, and "break free" of needing the UI's being written in HTML, JS, CSS, etc.

What some of this WASM/WASI/etc... seems to be trending towards is building up enough of a foundation amongst interoperable _CLIENTS_ that have ZERO dependency on HTML, JS, CSS, and instead you get much closer to:

    curl 'https://example.com/one.html'
       => curl 'wasm://example.com/one.app'

...to the extent that "the internet" has hit a complexity wall of what's possible (manageable, maintainable) with HTML+JS+CSS, the people tackling WASM seem to be saying:

Forget trying to coerce a buggy browser into running my `for ...` loops (and rendering my graphics) correctly, and you can't realistically decompile or hand-edit the HTML+JS+CSS for 99.9% of the stuff your browser is rendering... how can we _skip_ the HTML,JS,CSS and get directly at "the VM" and run what we actually want.

Secondarily (but importantly, and interestingly): How can we make 'webapp.wasm.exe' support everything that a "native" app would need (eg: GL, GPU, Bluetooth, Local Files, USB devices, Camera, Sensors, etc...)

There's likely mega-trillions (no exaggeration!) of effort that's been poured into tooling for "the internet", what is the unifying effort/effect that would unlock that for local app development? How can I get `msword.exe` to run "on the internet" for free? How can I get `make clean ; make install ; make wasm` working for any internet connected client?

As a thought experiment, we're almost there! We could technically have `win95.img + bochs86vm.wasm + autorun.inf + msword.exe` wrapped in a "browser evaluator" that could conceivably run `msword.exe` transparently to the user, but still allow you to use `msword.exe` indistinguishably from the "original" native app (bridging the local filesystem, exposing virtual devices, etc).

See also https://www.destroyallsoftware.com/talks/the-birth-and-death... ... circa a decade(!) ago!

[dns_snek]

> As a thought experiment, we're almost there! We could technically have `win95.img + bochs86vm.wasm + autorun.inf + msword.exe` wrapped in a "browser evaluator"

I looked into this and... holy crap! We are there. Not for modern programs quite yet, sure, but this is amazing. You can use Windows 2000 from your browser, running inside an x86 emulator for WASM.

https://copy.sh/v86/?profile=windows2000

[ramses0]

Yup! ...and noodling around with their `wordpad.exe`, you could pretty easily imagine `My Network => My Workgroup => ...etc...` to samba-share in your local filesystem (provided by the bochs86vm "container") ....... or since it's turtles all the way down, just map your local computer drive as `D:\...` and let the VM "think" it has access to all your files on the vm-local disk.

[crq-yml]

As it is, I already run a Debian VM locally to seal off the "development" stuff from my primary desktop.

Is is kinda heavy? Yeah. The hard disk footprint is substantial. But it works fine for writing some Python, compiling a few dependencies and bringing up a browser to test stuff. Even on a six-year-old laptop, it runs OK.

If the client application needs 1990's capabilities, "chuck it in a VM" will work today, and it will only be limited by protocol support, I/O access, and OS integration. There are substantial accessibility problems presented by VMs - seemingly basic things like clipboard support are disagreeable and require a "smart emulator" inserting itself to provide that feature.

Perhaps the right direction to take is to develop MAME to contain every accessibility feature. It already emulates all the old hardware.