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

111–120 of 251 posts

Re: Pay attention to WebAssembly

#111

Post by hsheth2 »

squidsoup wrote: post #34

This article mentions inflection points, but doesn’t delve into clientside apps significantly (e.g. SPAs). How far away are we from transitioning from component based JavaScript frameworks like react, to something which compiles to wasm?

Agree with sibling comment - the JS ecosystem has a huge momentum behind it and probably isn't going away anytime soon.

On the web, Wasm has currently found the most success with compute-intensive applications, since the JS Wasm bridge is still pretty expensive. There are already some Wasm-based frameworks like https://platform.uno/ that work on the web, but things like React/React-native and Flutter have a huge head start.

Re: Pay attention to WebAssembly

#112

Post by Jdl7 »

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.

No post body was provided.

Re: Pay attention to WebAssembly

#113

Post by pie_flavor »

SquibblesRedux wrote: post #83

Reading the article, I felt like I was back in 1996 reading about the Java bytecode compiler and the JVM plugin for the browser. Java had such great promise for web page-hosted code, that would be portable, performant, and safe. Why would one think WebAssembly will succeed where Java failed? (Well, Java did not exactly fail, but its purpose and typical usage radically changed over the years.)

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 with than Flash, it tried to do both and ended up doing neither.

So, why should WASM succeed where Java failed? Well, for pretty much every actual reason Java failed. There's really no places to compare them. WASM is implemented in-browser (and the runtime is very small), it's got a ~1.5x slowdown compared to the 2.5x-3x of the big clunkers like Java and C#, and most importantly it knows its place: low level computation. It does not try to do GUI, but leaves that up to the environment; it does not try to do a high level object model, but leaves that up to the language being compiled for it. What reason do you see that Java failed that's also applicable to WASM?

Re: Pay attention to WebAssembly

#114

Post by dataangel »

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…

Only because this is a bad demo. Do the whole thing in WASM without marshalling and it'll smoke JS.

Re: Pay attention to WebAssembly

#115

Post by hsheth2 »

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.

From a technology perspective, I think you're totally right that Wasm and WebGPU support is super exciting for game engines like Unreal/Unity. The ease of distribution could be a game-changer.

That said, I'm not super familiar with the world of game development and distribution. While web-based games have great distribution, the "best" technology or product doesn't necessarily win. Steam has massive power as an incumbent in the space, it does provides a useful service of facilitating discoverability for indie games, and there's definitely some scenarios where web-native games don't make sense [1].

[1] https://news.ycombinator.com/item?id=30157817

Re: Pay attention to WebAssembly

#116

Post by tyingq »

staticassertion wrote: post #76
hankman86 wrote: post #61

Earlier quoted context omitted.

Oh, I have implemented wasm multi-threading both in-browser and on a node server. On the latter, it uses node's "Worker threads" API, which is very similar to in-browser Web workers. In either case, `SharedArrayBuffer` serves as the backing store for the (shared) `WebAssembly.Memory`. Wasmer is different and more like what WebAssembly should offer as part of the standard. Alas, that's not how wasm works in-browser. B…

> the very fact that threading isn't fully covered by the core wasm programming model Does any assembly language have a concept of threading?

WASM is in many ways a virtual machine and not just an ASM dialect. Things like built-in garbage collection are in the plans.

Re: Pay attention to WebAssembly

#117

Post by orangecat »

dragonwriter wrote: post #67
russtrotter wrote: post #35

Earlier quoted context omitted.

To continue the Java bytecode prior comment, at one point, java was in all browsers of the time (i.e. Applets). However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. Java also enjoys multiple HLLs that target its bytecode (Scala, Kotlin, Groovy, Jython, etc) and there's nothing in the runtime capabilities that tie it to any kind of constrained platform (threading, IO,…

> To continue the Java bytecode prior comment, at one point, java was in all browsers of the time No, it wasn't. > (i.e. Applets). Applets required (1) installing Java on the system, and (2) installing a plugin for Java in the browser. The capacity to run them was not built in natively to any major browser. > However, it lost, and seemingly removed with extreme prejudice with no nods to backwards compatibility. It pr…

The capacity to run them was not built in natively to any major browser.

It was at first. In the early days of Java, Netscape and Internet Explorer had their own embedded JVMs.

Re: Pay attention to WebAssembly

#118

Post by dataangel »

maga wrote: post #52
azakai wrote: post #40

Earlier quoted context omitted.

At a glance, the bindings for wasm copy the data, https://github.com/zandaqo/iswasmfast/blob/54bbb7b539c127185... If the running code is short enough then that copy might easily make the wasm version much slower. That is indeed a known downside of wasm (calls to JS are somewhat slow, and copying of data even more so - wasm shines when you can avoid those things, which certainly limits where it makes sense!). If it's…

Yep, that's it. And the data marshalling overhead is even more pronounced with the native addon example (N-API Addon). But that's the thing, it's not "WASM always faster than JavaScript" as the author presents it. And on top of that, JS engines are no slouches either, you can optimize JS code to be pretty competitive in terms of performance even for computationally heavy tasks. WASM is _predictively_ performant, bein…

It is pretty much always faster though. The same code completely written in JavaScript replaced by the same code written in Rust and compiled to WASM will nearly always be a speed up if you haven't screwed up and made the comparison apples to oranges by introducing copying or something like that. What's not always faster is mixing because of conversions. But this is just a reason to use more WASM :)

Re: Pay attention to WebAssembly

#119

Post by MR4D »

hectaman wrote: post #13
MR4D wrote: post #10

I’m waiting for a Docker container with a WASM runtime. Wait, maybe someone’s already done that… /s PS - actually, originally I was being sarcastic, but there probably are some very good security use cases for it.

This is Liam, co-founder of wasmCloud, founder of Cosmonic, and co-chair of the CNCF Cloud Native Wasm Day. I don't think this is actually as crazy as it sounds - when we designed the messaging around CNCF, container, and WebAssembly we deliberately went with a better together story. Why? In a large enterprises you have huge systems that each represent a variety of concerns - security, compliance, governance, reputat…

Thanks for the comment, Liam. In honesty, I was only thinking about the simple security use cases, but your comment makes it obvious that this will become a huge marketplace very quickly. You are clearly much closer to the puck than I am !

Re: Pay attention to WebAssembly

#120

Post by evmar »

Ecco wrote: post #109
evmar wrote: post #62

> Figma makes use of a low-level C++ library called Skia for 2D graphics rather than building their own graphics engine This is not quite right. The bulk of Figma rendering is Figma-custom GPU code. It's true that Figma uses Skia, but only for some specific graphics algorithms in Skia, not as a general purpose rendering library. Source: I work on this code.

What do you mean by GPU code? Do you mean some code that calls WebGL?

Yes, sorry! I should've written GL, not GPU, but it's too late to edit it to fix. ...though there are some shaders involved.
Post reply on HN