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

181–190 of 251 posts

Re: Pay attention to WebAssembly

#181

Post by fxtentacle »

echelon wrote: post #129
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? Why you expect your Unreal-to-WASM product to succeed when Epic Games can simply build your entire product as a feature of the engine? You are building on their platform and not an open web stack, after all. Despite having an open web, most people have elected to use platforms. At some point, people will defer revenue for simplicity.

I think OP is working on the Epic team. They already have workable emscripten support in UE4

Re: Pay attention to WebAssembly

#182

Post by the_duke »

kaba0 wrote: post #154
the_duke wrote: post #133

Earlier quoted context omitted.

There are fundamental differences here. Webassembly is a small stack machine based on an open standard. It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback. There already are a multitude of different implementations. (the three browsers, the W…

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 Java Platform.

Core Webassembly has nothing of that.

But to be fair: Webassembly is also growing more and more complex (SIMD, reference types, GC, interface types, module linking, tail calls, exceptions, ...)

Can the JVM be what Webassembly is? Or the CLR, for that matter? Technically: of course.

My point was really more about the ecosystem as a whole. JVMs were never really intended as a general purpose, multi/cross language ecosystem of generic computation. And everything around it is noticeable. In the build tooling, in the libraries, in the development process and focus, the lack of AOT until recently (in open source implementations), ....

Sure, that's changing now with GraalVM and a focus on cross language support. There are some extremely cool things happening there.

I'd still much rather bet on an ecosystem based on an open standard with lots of interest from different parties.

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

Re: Pay attention to WebAssembly

#183

Post by echelon »

fxtentacle wrote: post #181
echelon wrote: post #129

Earlier quoted context omitted.

> What’s your point? Why you expect your Unreal-to-WASM product to succeed when Epic Games can simply build your entire product as a feature of the engine? You are building on their platform and not an open web stack, after all. Despite having an open web, most people have elected to use platforms. At some point, people will defer revenue for simplicity.

I think OP is working on the Epic team. They already have workable emscripten support in UE4

I don't think so. The Discord in his HN profile points directly at his startup:

https://www.theimmersiveweb.com/

This appears to be a 3rd party attempt to bring UE4/5 to the web.

I'd love to hear OP's take on how they think they can outpace or complement Epic on their own internal implementation. At face value I don't see how this isn't a f.lux vs. Night Shift type situation, where the official feature destroyed the market for third parties.

Re: Pay attention to WebAssembly

#184

Post by Seb-C »

maga wrote: post #30

> “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime. Yeah, nah: https://github.com/zandaqo/iswasmfast JS is about 10x faster than wasm in simple linear reg…

I actually tried wasm a couple of months ago with Golang in the browser, and was very disappointed.

It is indeed way slower that JS (and yes, I tried to care about performance and understand what was going on, removed any data exchange with the browser and even ran the tests without any dev tools opened - just in case).

Not even mentioning the fact that to use it, you need to include and hardcode a dubious JS file that does not even integrate properly with npm or any build system. And that the standard wasm way to exchange variables and events is not supported (instead you are forced to use some automagic and slow DOM bindings).

The performance with alternative compilers (tinygo) was a bit better on the performance side, but the integration was still disappointing and unsatisfying.

Re: Pay attention to WebAssembly

#186

Post by robertlagrant »

astlouis44 wrote: post #77
hsheth2 wrote: post #75

Earlier quoted context omitted.

Thanks for the correction - I'll update my post shortly.

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.

Re: Pay attention to WebAssembly

#187

Post by detaro »

robertlagrant wrote: post #185

> Just as Docker could not replace virtual machines entirely I keep seeing this. Docker in no way replaces virtual machines. Can someone explain?

Previously: "We want to deploy apps as isolated units we can have variable amounts of instances of, so we make VM images and deploy them to AWS/our VMWare cluster/...". Now: "..., so we make Docker containers and deploy them to AWS/our Kubernetes cluster/...". Hence, Docker replaced virtual machines in a way.

Re: Pay attention to WebAssembly

#188

Post by flohofwoe »

greggman3 wrote: post #97
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.

I think it depends Problems with *traditional* games via WASM/WebGPU in the browser * Many games are 10-100gig+ in size. The browser provides no good way to store this data for your game and the fact that you had to wait 15mins to multiple hours means you gain no advantage. Further, browser have a balance to keep between letting any site put gigs of data on your machine vs not. And on top of that, the browser provide…

> Many games are 10-100gig+ in size.

For web games it doesn't really matter how big the entire game is, only how much data it consumes per second of game play, the local storage is just another caching layer not meant to hold the entire game but just the data that's most likely needed next. As long as the user's average bandwidth is higher than what the game needs to keep the 'disc cache' filled it's fine.

Of course this means the entire asset-streaming, and probably the whole game needs to be designed around this 'number of bytes per second to be presented to the user' limitation, but that's not a new thing. In the past, games were designed around CD-drive bandwidth and seek times.

As to your other points, I mostly agree, the browser is a too unstable platform, and the people building the web APIs (other than WASM and WebGL/WebGPU) usually don't care much about games.

But there's a huge space below what's called "AAA" which still can make absurd amounts of money (and provide absurd amounts of fun), and for which the tech limitations in browsers are okay-ish. Those games need to be designed from the ground up for running in the browser, porting existing modern games will mostly not work.

Re: Pay attention to WebAssembly

#189

Post by Chris2048 »

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 hence reduces the scope for compatibility creep. maybe? ...

Re: Pay attention to WebAssembly

#190

Post by flohofwoe »

maga wrote: post #64
chrismorgan wrote: post #57

Earlier quoted context omitted.

Yeah, that repository is measuring performance of a WASM/Node.js hybrid, and not straight WASM. Interoperability costs can certainly dominate in such cases, where straight WASM can bypass much of the cost. Such a hybrid is what you want to measure often, but certainly not always, and a large part of what this article is talking about is the potential of pure WASM unshackled by Node.js.

And how is the data going to reach the "unshackled" WASM in the browser, for example? I'm not aware of any way for the web page to interact with WASM other than through the JS land with the said overhead. The article explicitly mentions usage inside the web page and presents WASM as a performant alternative.

It's quite obvious and simple: by reducing 'context switches' between JS and WASM. E.g. don't call from JS into WASM for a simple computation, but instead batch thousands of computations into a single call. Also works the other way around. When calling from WASM into web APIs, think of those calls as expensive 'syscalls' which need to be minimized.
Post reply on HN