Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pay attention to WebAssembly

harshal.sheth.io

Post reply on HN
Print view View original

191–200 of 251 posts

Re: Pay attention to WebAssembly

#191

Post by flohofwoe »

robertlagrant wrote: post #186
astlouis44 wrote: post #77

Earlier quoted context omitted.

Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.

The problem I see here is more that this will just allow Microsoft to undermine one of the few competitors it hasn't yet managed to.

It's really more about "undermining" Apple's app store monopoly ;)

Re: Pay attention to WebAssembly

#192

Post by flohofwoe »

eezurr wrote: post #104
astlouis44 wrote: post #77

Earlier quoted context omitted.

Thoughts on gaming’s role to play with WebAssembly..? My team and I are current working on Unreal Engine WASM support, with WebGPU integration on the way. Personally, I believe native games on the web is going to disrupt Steam and the app stores and enable a whole new distribution channel for developers, especially indies. No 30% cut, works on any device with a browser.

When people purchase the game, will they have a digital copy on their hard drive? Or will they be beholden to the company staying in business and keeling the servers running?

That train has left the station for at least 15 years. Your 'digital copy' is useless if the DRM servers are down (GoG's DRM free games are a notable exception).

Re: Pay attention to WebAssembly

#193

Post by goombacloud »

You lose the regular Linux process you are used to and the interaction you can have between processes: start new ones to offload a small task, pipe data, trace them with strace or debug them with gdb. I think this convenience also held back people from moving to Unikernels.

Re: Pay attention to WebAssembly

#194

Post by flohofwoe »

goombacloud wrote: post #193

You lose the regular Linux process you are used to and the interaction you can have between processes: start new ones to offload a small task, pipe data, trace them with strace or debug them with gdb. I think this convenience also held back people from moving to Unikernels.

Security considerations aside, if you control the WASM runtime (for instance if WASM is used for a plugin/extension system) you can expose most of this functionality to the WASM code through your own runtime API.

Re: Pay attention to WebAssembly

#195

Post by badsectoracula »

flohofwoe wrote: post #192
eezurr wrote: post #104

Earlier quoted context omitted.

When people purchase the game, will they have a digital copy on their hard drive? Or will they be beholden to the company staying in business and keeling the servers running?

That train has left the station for at least 15 years. Your 'digital copy' is useless if the DRM servers are down (GoG's DRM free games are a notable exception).

Might be a notable exception but i have almost a thousand of those exceptions :-P. Also while Steam itself is needed for the initial download, some games can just be copied to another place and work fine, especially indie games that do not bother with DRM. A bigger issue is the Steamworks APIs but if you only care about singleplayer games there are drop-in replacements like Goldberg's emulator[0] which is opensource (LGPL).

(also there are more places to buy DRM-free games than only GOG - e.g. itch.io, Zoom Platform, GamersGate and Humble Store to name a few - though GOG has most of the games)

[0] https://gitlab.com/Mr_Goldberg/goldberg_emulator

Re: Pay attention to WebAssembly

#196

Post by kaba0 »

the_duke wrote: post #182
kaba0 wrote: post #154

Earlier quoted context omitted.

With all due respect, do you know anything about Java? What do you think it is? https://docs.oracle.com/javase/specs/jvms/se7/html/ And no, Java is absolutely not a huge runtime - it is a simple stack-based vm with garbage collection made originally for goddamn TV set-top boxes, so it has an absolutely small instruction set. It just happens to be so good for multitudes of reasons that the biggest implementation (yes,…

I am (somewhat) familiar with the JVM. Yes, it's also a stack based VM that is relatively small, at least superficially. It's really not that simple though. Things like GC, exception handling, a whole class model with constructors and methods, ... All of that brings countless implicit requirements that are only passingly mentioned in the spec. Plus the whole host of complexity needed in practice for supporting the Ja…

> the lack of AOT until recently (in open source implementations)

The gcc project had a now discontinued AOT java compiler 2 decades ago.

Java is as open as it gets, with a standard, that can be changed through a community process. I feel the web is much less open with behemoths having basically infinite veto powers like google apple microsoft.

> In fact, GraalVM already supports Webassembly, including WASI! So in certain sense Wasm is already more general.

And teavm can run java byte code both in js as well as wasm :D

Re: Pay attention to WebAssembly

#197

Post by monk_e_boy »

CharlesW wrote: post #94
astlouis44 wrote: post #85

Earlier quoted context omitted.

What’s your point? All of that can be done on the web, besides it isn’t really targeting the Steam audience at the end of the day. Think the mobile audience, but on the web. You can do a Sims or PUBG in HTML5 today, and all that’s required is a hyperlink to share it with others. Same strategy that made Wordle go viral and get acquired today for over $1M.

> What’s your point? He's addressing the problem with your hypothesis that "native games on the web will disrupt Steam" by pointing out that you're comparing apples (a technology platform) and oranges (a distribution channel). Steam doesn't exist because games don't use WASM.

There's all that stuff on other platforms. Reddit subreddit indie games would be neat if I could just open the post and play the game.

I can't imagine I'd use Steam much after that. (And I guess facebook would do the same.)

As for payments, I already pay mostly through Google pay or through paypal. Steam isn't adding a huge amount of value.

Re: Pay attention to WebAssembly

#198

Post by johannes1234321 »

SquibblesRedux wrote: post #147
pie_flavor wrote: post #113

Earlier quoted context omitted.

Java failed because - it depended on an installation outside the browser, poorly versioned - and a plugin too, which was extra noise for the user, and not nearly so pain-free as Flash's was - it was not , under any circumstances, performant (this was before HotSpot) - AWT was truly, thoroughly, god awful (this was before Swing) Finally, it was caught between two realms. Clunkier than JS and more difficult to work wit…

In the 1990s I was building, among other things, web-based controls (in Java) for backend systems. People were completely blown away with what could be done. (The major competing technology was HTML forms and HTTP PUT with Perl CGI.) With the exact same language I was also able to build a high-performance peer-to-peer file sharing system for backend systems. (2+GB files to personal workstations across a large geograp…

A big difference: As a user I could "feel" whenever a Java Applet was loaded. Suddenly everything became slow and only rarely the GUIs were acceptable. That diminished reputation in users, aside from security problems etc.

With WASM the user doesn't notice it. Without looking at dev tools you can't tell if some of the functionality is coming from wasm or JavaScript/typescript/..

In consequence users won't develop the "yikes, Java" reaction.

wasm got the chance to slowly creep into stacks.

Re: Pay attention to WebAssembly

#199

Post by the_duke »

kaba0 wrote: post #196
the_duke wrote: post #182

Earlier quoted context omitted.

I am (somewhat) familiar with the JVM. Yes, it's also a stack based VM that is relatively small, at least superficially. It's really not that simple though. Things like GC, exception handling, a whole class model with constructors and methods, ... All of that brings countless implicit requirements that are only passingly mentioned in the spec. Plus the whole host of complexity needed in practice for supporting the Ja…

> the lack of AOT until recently (in open source implementations) The gcc project had a now discontinued AOT java compiler 2 decades ago. Java is as open as it gets, with a standard, that can be changed through a community process. I feel the web is much less open with behemoths having basically infinite veto powers like google apple microsoft. > In fact, GraalVM already supports Webassembly, including WASI! So in ce…

> Java is as open as it gets, with a standard, that can be changed through a community process.

Isn't the JCP also controlled by a hand full of corporations? Seems pretty much the same to me.

> And teavm can run java byte code both in js as well as wasm

Hah! I didn't know TeaVM had a WASM target, that's actually great to know.

Re: Pay attention to WebAssembly

#200

Post by usrbinbash »

Chris2048 wrote: post #189
usrbinbash wrote: post #177

WebAssembly will not displace Server Side languages. "oh but it compiles once and then runs everywhere!!!!"...ceased to be an argument over 15y ago, when it became clear that the "backend" is synonymous with linux, and almost every machine has the same architecture. Plus, the time required by the compilation step is not prohibitive in a CI/CD pipeline.

I understand that compilation is not an issue, but WDYM by the other stuff? Even python is a bit of a PITA to package and run where interpreters already exist, not all distros are the same - The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much. JS, in virtue of being properly sandboxed, seems to be in a position to prevent coupling outside expected interfaces, and…

> Even python is a bit of a PITA to package and run where interpreters already exist

That's mostly a result of everything and everyone having a different opinion where python modules should live in the filesystem, and the default behavior of a lot of package managing software to replace python installations between versions instead of shoving them into different packages and be done with it.

> The advantage of a VM or vm-like container is exactly that you don't need to care about that stuff as much.

The same advantage exists for compiled languages, provided that dependencies are either staticaly compiled, unambigously listed, or shipped with the software as a package.

A similar effect is achieved in Python Projects by virtualenving everything, essentially stuffing all dependencies, including the correct version of the interpreter, in one location as a single package.

Post reply on HN