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!
Yet I am still waiting to see a game with the same capabilities of Infinity Blade, that Apple used in 2011, as an example of a game showing of the newly acquired OpenGL ES 3.0 capabilities of iDevices.
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.
That expectation is off by nearly a decade. WASM games in terms of performance are closer to 2000 than 2010. Here's an open source indie game from 2003 that I ported to WASM [1]. It struggles to hit 60 FPS on devices that were released a good 15 years after the game itself. Browsers sometimes struggle to animate simple lines at 60 FPS still to this day, because they're just hugely massive platforms with thousands of moving parts with no room for big, complex apps on top of them.
Glancing at the project, one area where things could go terribly wrong is the translation layer from GL 1.x to WebGL. For instance 'tricks' that are common on native GL implementations like buffer orphaning are actually harmful on WebGL and may cause lock stalls which would cause exactly the issues you describe (e.g. struggling to hit a consistent frame rate despite extremely low CPU and GPU load).
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.
A couple of years back I also wrote a pure WebGL renderer for Neverball levels [1]. No physics, no translation to WebGL, just the 3D renderer part in direct WebGL. It also has a surprisingly low performance ceiling. I'd say I managed even worse than what the gl4es translation layer does for Neverball. By far the biggest performance boosts were instanced arrays and vertex array objects - basically just reducing the number of calls into WebGL. Seems to me that WebGL has a lot of overhead with or without a translation layer.
I did some GL benchmarking for simple draw calls (on desktop) a couple of years ago, and while it's true that WebGL came out lowest, the difference between native drivers were much bigger. I basically checked how many trivial draw calls (16 bytes uniform update + draw call) were needed on Windows before the frame rate drops below 60 fps, and for WebGL in Chrome this was around 5k, Intel native was around 13k, and NVIDIA topped out at arond 150k (not all that surprising, since NVIDIA has traditionally the best GL drivers).
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).
Let's be clear what Flash was though. It was a native binary that would paint to a region owned by the browser. So yes, it was performant because basically the only thing it was doing differently than any other native application was how it was hosted by the browser.
That's also why it was such a security nightmare. It was a complete escape from the browser sandbox.
It was a great development experience, destroyed by pitch forks and lanterns by the folks that a decade later have failed to deliver a sound alternative.
Hence why the gaming industry is focusing on streaming instead.
Flash was destroyed by Apple, which had no interest in improving the web either. The iOS platform turned out to be a pretty good replacement for Flash though.
Sure, but what's the point if it's not supported by Safari. Adobe Air was at best a porting aid to get your old Flash code wrapped in an iOS app, but the writing was on the wall and nobody in their right mind would start new Flash projects.
PNaCl was a joke though, it suffered from much longer client-side compilation times than both asm.js and WASM ever had, and performance was at most on par with asm.js.
(NaCl was better in those areas, but required to stamp out one binary for each target CPU architecture)
There's definitely something strange going on here. I'm getting about 3x as much CPU load on the WASM version as compared to native. Still low enough for a solid 144fps on my machine, but there shouldn't be this much overhead.
The number of calls needs to be lower for a WebGL application. You have to use as much instancing as possible. The security layer makes the calls the slowest part of the pipeline. That's why you see amazing things in shadertoy. When the whole shebang is in the shader it runs smooth.
Devtools or F9 while in game. Type a famous magic word in the title screen to access all levels. Not sure how to do this on a phone which is what I was referring to - but framedrops are pretty obvious.
I've done a quick test and it runs very smoothly on my original OnePlus One from 2014 (so 11 years after the game). This is on latest Chrome, Android 11 (LineageOS 18.1).
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!
To be fair my reference browser is Firefox, WebGL is a fair bit slower there.
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.
My hypothesis is that monetization on the web is harder so there are not as many resources spent on games in browsers. If anyone is willing to spend a lot of time on the game they are probably willing to install it, people arent conditioned to pay up front for websites, the UX around microtransactions isn't at all smooth.
These are mostly business issues. If the business problems would be solved, the games would be built, despite any technical limitations of the web platform (which are not much different than limitations on low-end Android mobile devices).
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.
No they aren't, at least low end Android devices support GL ES 3.2 and have proper debugging tools.
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.
A kludge to work around lack of tooling for the past decade, and when doing that, no need to WASM anyway.
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.
I can imagine how a new style of web-only terminals be possible. The filesystem is realistically _any_ url, and you can load any wasi programs (via a shell, which is also just another wasi program).
I wonder if this is practical, or just a gimmicky way to use a computer...
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
Presumably that operation failed because there isn't a writable virtual filesystem. Would it be possible to provide one?
Might be this particular build of Python, or might be that I implemented one of the `fd` functions in a way Python/SQlite is surprised by. I'll have a look into it some time!
Hi,
I already support typescript execution in http://chatcraft.org/ via wasm esbuild.
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.
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.
I wouldn't put it in prod, but it would be possible. You'd need a JS binding layer that dealt with the output and wrote it to the page, but it could be minimal.
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).
Hello, thank you for this work as it shows great creative potential.
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 ?
Yeah of course! They've got STDIN/STDOUT/STDERR and I've built a Virtual Filesystem. But if you're using WASI binaries locally they don't have that restriction.
Is this on the blog post, or are you trying it out yourself?
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?).
It is a nice proof-of-concept, but a pity that runno uses firebase. Any software with built-in SaaS services from advertisement agencies are a no-go area for me.
It's a bit temperamental on some browsers sorry (I've seen it fail on Arc). I implemented my own front-end router and I have done a bad job. I've seen it work today on Chrome, Firefox and Safari.
Why is it temperamental? When you say frontend router do you mean in the SPA sense (eg, React/Angular) or do you mean like your own load balancer (eg ALB/HaProxy/Nginx)?
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!