Hacker News Reader

Comment by joaomacp | Hacker News Reader

Maybe it's a foolish thought, but it occurred to me that maybe in 10/20 years AAA game titles will have a 'web' version, as well as the PC and game console ones. Or maybe they let you play a demo for free on the browser, with real gameplay mechanics and graphics made with wasm or similar tech.

View on HN

In 10 years there won't be any difference between a web-app and a desktop app precisely because of WebAssembly-like tech. Imagine WebAssembly being the new JRE or .NET runtime (or maybe more like JavaFX, but supported by everyone). You can run it in a browser, but you don't have to. All native stuff will be accessible to you, like Vulkan, OpenAL etc.

Sounds like my worst nightmare. Browsers won't and should never have the full capabilities of native APIs. It's certain that many more applications will shift into web apps, but there are limits to what I'll want my browser to do.

It's more like you won't need to develop for two-three targets, like today with desktop, web and mobile. Instead you will use the same runtime, though there might be some restrictions on each platform you'd need to take into account (like handling permissions properly) and make sure your code would work on any platform that provides the capabilities you require.

Java promised that, but we got write-once, debug anywhere. Those different features, bugs, permissions, etc, mean you'll still have to test the platforms, build up different UIs for each platform, etc. About all you'd end up gaining is a stylesheet-based rendering engine, but you'd get that with something like XAML as well.

Java doesn't support compiling C/C++ to their runtime. So that's not really comparable to this.

There is a currently dead project that does that https://github.com/davidar/lljvm . So I'd argue it is comparable.

Like you said it's dead. Hypotheticals don't matter here only real tools we can use today.

WebAssembly is much simpler than Java, and harder to get wrong. The DOM isn't, but I would hope non-web targets for WebAssembly would use different (and simpler) APIs.

This battle was lost decades ago, along with semantic markup and needing to enable Javascript to see any text. I don't like it either, but the market took the shortest available path to what it was seeking and now there is no way anyone will roll it back.

Yes there is, iOS, Android and UWP.

How well are Android and iOS running in your desktop?

You forgot UWP from my list, and that runs just fine.

As for desktop as such, my tablets are also fine with an external keyboard and the right set of native apps.

I deliberately didn't ask about UWP because then I would have had to ask "how well does UWP work on a Unix desktop".

Not everyone cares about UNIX desktops, specially looking at changes at Apple and their sales.

When the topic discussed is software that can run on any platform, you have to care about UNIX desktop, otherwise you're cheating - or at least not providing a solution to the problem as was stated.

No, the topic being discussed is

"Browsers won't and should never have the full capabilities of native APIs. It's certain that many more applications will shift into web apps, but there are limits to what I'll want my browser to do."

Which given the increase in mobile OS across the planet and their use of native apps, is something I wish will turn the tide.

Once you run WebAssembly as a virtual machine providing a core API without a windowing system, it barely counts as a browser anymore.

There's nothing in its essence that makes it different from the virtual machines in Java or C# or Python, other than having several alternate working implementations, available in every device that runs a modern browser (true, the latest wouldn't count as "native", but nothing stops you from running a headless WebAssembly instance directly on the metal without the intermediate application layer).

The solutions you proposed (iOS, Android and UWP) may count as native, but they definitely don't count as "universal" in the same way that WebAssembly would.

There is a big difference from all other VMs, a lowest common denominator UI/UX across all devices, even the JVM does better in regards to integration with the host OS.

This has not changed since the HTML5 is going to change the world kind of thing, and I doubt WebAssembly will change that.

Simple stuff like Web Components are still pretty much a Chrome thing and WIP everywhere else, let alone more specific OS APIs.

Uh? Why would that make it any different from providing an "official" GUI API with the virtual machine, like Java Swing and MS XAML (or whatever Microsoft calls its current View stack nowadays)?

Are you talking about implementations not being there (yet, though that could change with time) or is there a fundamental difference in the platform architecture that I'm unaware of?

I am talking about the full stack from the lower layers all the way up, integration with peripherals, audio engines,GPGPU, 3D that doesn't look like Glide demos, ability to fully utilize any kid of wireless communication,composition engine, GUI components, security, 2D acceleration that is guaranteed to always work, ...

Doesn't UWP also try to provide all of that? The only difference I see is that HTML5 comes with a formally defined standard, so it is possible to build more than one implementation by different parties, while UWP is proprietary.

I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea.

> I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea.

It is not that is a terrible idea, it is that it will never happen, thus always being a 2nd class UI/UX.

I am still waiting for a version of WebGL that can actually fully use my graphics card, WebGL 2.0 surely isn't it yet.

Or for web components to be ready across devices and multiple browsers. How many years has Google been talking about them at Google IO now?

Never happen? Unreal Engine has been ported to WebAssembly. Sure it's not part of the standard, but it runs on the platform. I'm sure Vulkan could get the same treatment.

Once you have a development stack with a good toolchain and widely available on many platforms, many people will be interested , and it will grow. Having a standardization body that will incorporate the best is a good thing to have, but it's not a requirement for the platform to get the tech support by third parties (see what happened with Flash or Silverlight, which required a separate unsupported engine as a plugin). Having a single target will surely accelerate development?

WebAssembly in browsers hasn't progressed all that much over the last 5-6 years (~2011 was The Big HTML5 Hype Year =) .. if it's out of preview in another 10 that'll be plenty!

Current spec is extremely limited in capabilities anyway for the full RIA spectrum of needs (strings, objects, dom), at this stage practically useful mostly for numeric calculations and such. Certainly there are loftier goals and a lot of optimism with regards to implementation timelines, "buuut"...

Well, that's just not true. WebAssembly (not to be confused with asm.js) only started in 2015. Browser preview period started in late 2016 and ended very recently, and we're now on the way to stabilization.

Are you talking about asm.js or something other than WebAssembly? WebAssembly was announced in 2015.

Crikey, seems like my off-the-top-of-my-head memory did fail me here!

If you have a fast enough internet, you can right now stream games to your PS4 just like Youtube. In 10-20 years time, we'll be able to stream games running directly on publisher's server farm somewhere.

Latency will always be a consideration though; the fidelity might get there in terms of audiovisuals, but you can't engineer around the speed of light.

If we can get closer though, I suspect most people wouldn't be bothered.

It would basically double the current latency (about 100ms) by adding a 50ms trip to both receiving and sending. (And that's being generous -- it could easily add 100+ms to each trip.)

I use a LiquidSky cloud gaming PC as my main games machine. For Overwatch, I have a ping of 1ms, as it's next to the OW servers, 40ms total ping from my home to LiquidSky. it's kind of amazing and works wonderfully

> Latency will always be a consideration though

And it will always be way too high for VR.

They could stream a spherical texture (with depth map). Locally you would only have to render the sphere from the view point of the eyes.

Oh. Nice. How do we plan on increasing the speed of light to make the latency low enough?

Onlive went bankrupt.

> In 10-20 years time, we'll be able to stream games running directly on publisher's server farm somewhere.

Nvidia has a game streaming service that does this already. I've only tried it briefly but it worked great.

http://www.geforce.com/geforce-now

I don't think this will ever happen, for most games. AAA games don't generally have much headroom for waste. And even if they do, supporting yet another platform is expensive.

AAA games are much more about content than the code that displays the content.

As someone who used to work on AA/AAA stuff that is way off the mark.

One supports the other and both need to be incredibly efficient and compact.

And that content would have to be downscaled and probably converted to another texture format, too, unless you can get people to be okay with waiting for gigabytes of data to be downloaded. Along with this comes extra costs for managing the additions to the asset pipeline that this incurs. Supporting another platform isn't just about code, it's about content creation, asset management, and testing, too.

At 1Gbps (125MB/s), a gigabyte takes 8 seconds to download, less than most AAA games take today just to load from disk. There are videos of Google Fiber users getting ~40MB/s downloads from Steam, so I wouldn't be surprised if at least some users reach that in the near future. And if you rely on a fast internet connection, you only have to send the assets necessary for one level at a time.

That exists, with unity and unreal engine in the browser.

Which AAA game titles are using that right now?

I don't know if this qualifies as "AAA", but the BananaBread demo is a must-see:

https://kripken.github.io/BananaBread/wasm-demo/index.html

That's a goal post shifting subjective distinction, isn't it?

It doesn't exist at the AAA level he's describing, to fit the limitations of WebGL the web versions of those engines are based on their stripped-down mobile renderers.

We need a next generation WebGL with features comparable to DX11 before web graphics can catch up with the state of the art in native PC/console graphics.

Those things are achievable once you get a stable platform with wide adoption.

Reply on news.ycombinator.com