Live data from Hacker News

Running WASI binaries from your HTML using Web Components

runno.dev

41–50 of 73 posts

Re: Running WASI binaries from your HTML using Web Components

#41
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 ?

Re: Running WASI binaries from your HTML using Web Components

#42
post #6

Earlier quoted context omitted.

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)? (Not working in Firefox for me)

SPA sense. It’s cobbled together because I just have fun with it. Not sure why it’s temperamental, haven’t bothered investigating.

Re: Running WASI binaries from your HTML using Web Components

#43

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 ?

Thanks for the feedback! It’s also cost me about $15 so far. I don’t think I’ll do that again, but it was fun as a demo!

Re: Running WASI binaries from your HTML using Web Components

#45
post #2

G’day, if anyone has any questions about this I’m happy to answer them here.

Unfortunately this page doesn't load in Firefox on Linux

Also just tested in Chromium, doesn't seem to work for me on Fedora Linux. Just locks up the browser

Re: Running WASI binaries from your HTML using Web Components

#46
post #27

Earlier quoted context omitted.

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.

The unreal citadel demo was running in a browser without flash in 2014: https://blog.mozilla.org/en/mozilla/mozilla-and-epic-preview...

3 years to catch up with 2011 tech, and a decade later nothing better to show.

Re: Running WASI binaries from your HTML using Web Components

#47
post #40
post #27

Earlier quoted context omitted.

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.

Apple has been slowing down WebGL I think. See eg people complaining in https://developer.apple.com/forums/thread/696821 and https://discourse.threejs.org/t/horrible-3d-three-js-perform...

80% of the browser mobile market belongs to Google, plenty of customers, even better when looking at the desktop market.

Usually a good excuse why the tech doesn't get uptake.

Re: Running WASI binaries from your HTML using Web Components

#48
post #34
post #29

Earlier quoted context omitted.

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…

A browser also has the baked in expectation of you interacting with hypertext. 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 pri…

Problems that can be sorted out, if there was any industry interest.

As it stands, everyone is going with cloud streaming instead.

Still uses a browser.

Re: Running WASI binaries from your HTML using Web Components

#49
post #32

Earlier quoted context omitted.

If we hadn't lost a decade with what Flash and PNACL already offered us in 2011... No wonder studios rather bet on streaming than a tech that will never deliver.

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.

Re: Running WASI binaries from your HTML using Web Components

#50
post #29
post #27

Earlier quoted context omitted.

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…

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.

Post reply on HN