Running WASI binaries from your HTML using Web Components
runno.dev
runno.dev
WebAssembly, WASI, like WebRTC/WebGPU/WebXR/WebAudio, just makes webdev, gamedev + native/networking very very interesting in this phase of technology where js frameworks are culty bloated/verbose and apps are the main thing for marketing/tools. Web apps + tools are opening up with wasm/wasi.
Runno (https://runno.dev/ + https://runno.dev/wasi) is a great idea and helps make interesting native stuff in a sandbox locally. Running all this directly without having to mash into assembly is a great idea. Awesome job on this!
> Runno helps you make runnable code examples that can be embedded in web pages. This is very handy for educational tools, it means:
> - You can make code examples that don't need users to install scary tools.
> - No need to run a server, it all runs client-side in the browser.
> - Your users can edit and re-run any code examples you make.
> - The examples are extremely customisable with HTML, CSS and JavaScript!
Or the Unreal Engine 3.0 citadel demo, also in 2011, for Flash/CrossBridge.
It seems the only thing usable is running ShaderToy demos, and 3D views on ecommerce sites.
No wonder studios rather bet on streaming than a tech that will never deliver.
That's also why it was such a security nightmare. It was a complete escape from the browser sandbox.
Hence why the gaming industry is focusing on streaming instead.
Mobile, handhelds and cloud streaming, is where the indie party is going on.
I bet WebGPU is going to be equally the same, ShaderToy and 3D commerce visualisation tools will be updated for it, and that is it.
Specially given that it made the same mistake of WebGL, lagging 10 years behind native APIs.
(NaCl was better in those areas, but required to stamp out one binary for each target CPU architecture)
I still find it amazing that this game never made with this in mind, the web tech at the time on the OnePlus One was nowhere near able to run this in browser and it works perfectly today!
What blows my mind with this technology is little things: porting the game to the browser gave me a half-working mobile port basically for free (had to implement touch input handling in Neverball). On top of that, thanks to SDL2 and the game controller web API, I can attach a game controller to my phone and play the game in the browser on my phone with a game controller. It just seems unreal that this combination of technology just works.
A video game of this caliber you are discussing is typically entitled to:
- have a dowload and installation process that might span over say 20min or more
- load slowly, because it needs to push a ton of assets through
- demand a ton of resources such CPU, GPU, threads, memory etc. to achieve amazing graphics and simulation
- being the primary foreground process or possibly the only one
None of these things apply to the typical web. Quite the contrary: most web devs would get fired or ridiculed if they demanded these resources.
So I assume that browsers optimize for the typical usage, which is hypertext.
As it stands, everyone is going with cloud streaming instead.
Still uses a browser.
Even though WebGL and WebGL2 are implementations of the GLES2 and GLES3 APIs you usually can't just take a non-trivial GLES2/3 code base and expect it to work without hickups on WebGL, what's going on under the hood is just too different.
It is definitely true though that you need to employ old-school batching tricks to get any sort of performance out of WebGL, but that's also not surprising, because WebGL is only a GL by name, internally it works entirely different (for instance on Windows, WebGL implementations are backed by D3D).
Usually a good excuse why the tech doesn't get uptake.
Nobody has figured out so far how to make money with high quality games on the "open web" to get the same return on investment like simple ad-driven 2D games running on closed platforms like Facebook which can technically be cobbled together by 3 dudes in their mom's basemement (exaggerating a bit here of course).
E.g. no matter how you approach it, the Citadel demo wouldn't have led to a web game that would make the same profit relative to the development cost like a simple ad-driven Tetris style game.
After a decade Web 3D keeps having spectorJS as the only alternative.
Naturally there are also some masochists that enjoy debugging the browser 3D stack on RenderDoc, while trying to figure out what belongs to their application.
According to here GLES3.2 support on Android is currently sitting at 80%, while with GLES3.0 you would reach about 95%, and with GLES2 100%.
https://developer.android.com/about/dashboards#OpenGL
If I would try to ship a native app on Android I would still at least try to only use GLES3.0 features to get that extra 15%.
You enthusiastic charactization of Android debugging tools isn't exactly how I would describe the situation ;)
Even if we consider GL ES 3.0, native comes out winning, due to missing features on WebGL 2.0.
Not only has Android the GPU debugger from Google, that beats anything available for Web, each mobile GPU vendor has their own set of graphical debuggers.
import sqlite3
>>> db = sqlite3.connect("data.db")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
sqlite3.OperationalError: unable to open database file
>>> open("data.db", "w+").close()
>>> db = sqlite3.connect("/data.db")
>>> db
<sqlite3.Connection object at 0x8b3fd8>Regular Python doesn't need me to create the file first, I wonder why this works differently.
I wonder if this is practical, or just a gimmicky way to use a computer...
There are other projects that are targeted more at this kind of thing if you want dynamic access to the DOM from Web Assembly (sorry I don't know them off the top of my head).
Runno is really cool as it will also lets me support intepreted languages like Python and maybe even golang(assuming i can have a wasi binary produce another wasi binary).
From docs: Currently @runno/wasi supports running only unstable and snapshot-preview1 WASI binaries. The snapshot-preview1 standard is more recent, and preferred.
Where does one see what's part of snapshot-preview1? My google-foo is failing me.
It's pretty unreadable though!
Preview 2 looks like it will be a big change, and is just being finalised at the moment. I'd expect that when preview 2 is available there will be an improvement in the quality of documentation. I'm not sure how long it will take after release for tools to start switching to it. I'd expect Preview 1 will still be the main target at least for the rest of this year.
A suggestion for runno's website, though : when I clicked on the link posted on HN, I did not expect to download that much data. Maybe you could find a way to offer pre-rendered examples and give the user who visits your site a (very visible) option to really download and run things ?
Is it possible to output to markup from these programs ?
It would be cool if python wsgi programs in this could work somehow.
You might be interested in WAGI: https://github.com/deislabs/wagi
And to catch up on WASI: https://xeiaso.net/talks/unix-philosophy-logical-extreme-was...
If it's on the blog post, it sounds like your browser doesn't support `SharedArrayBuffer` (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) or you've disabled Cross Origin Isolation somehow. It might be because you have an old browser (there was a period where it was disabled) or you have disabled Cross Origin Isolation yourself (maybe a security setting?).
(Not working in Firefox for me)