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

101–110 of 251 posts

Re: Pay attention to WebAssembly

#101

Post by charcircuit »

>There’s good reason to believe that Wasm represents the future of containerization. Compared to Docker, it has 10-100x faster cold start times, has a smaller footprint, and uses a better-constrained capability-based security model. Making Wasm modules, as opposed to containers, the standard unit of compute and deployment would enable better scalability and security.

I don't see how these are "big" wins over containers. The services I run don't have to worry about cold start times. It takes much longer than starting a container for my services to be ready anyways. I also don't see how it has a smaller footprint. The application needs to be stored somewhere. While containers may only have coarse capability based security using namespaces I'm not sure having super fine grained capability based security would make it be worth switching over to wasm.

Re: Pay attention to WebAssembly

#102

Post by cornstalks »

maga wrote: post #96
chrismorgan wrote: post #87

Earlier quoted context omitted.

You’re still missing much the point of the article: WASM isn’t for the browser only . WASI, for example, is a full environment you can run stuff in without any such interoperability cost. But even inside something like Node.js or the browser, most of these sorts of benchmark attempts are of converting only small parts of a system, so that message passing or format shifting ends up a comparatively large fraction of th…

> You’re still missing much the point of the article: WASM isn’t for the browser only. WASI, for example, is a full environment you can run stuff in without any such interoperability cost. Of course, but we are not arguing about the point of the article, I'm contesting the exact claim that "WebAssembly is almost always faster than JavaScript". Admittedly, not because it's such a big mistake on the author's part, but…

I think part of the pushback you're getting here is that you're contesting "WebAssembly is almost always faster than JavaScript" (which IMO is correct and appropriately couched) with "WASM + JS can be slower than just JS" (which is also correct), but the way you're communicating it comes across as "WASM is just slower than JS" (that's obviously not literally what you're saying, but that's how it's coming across).

If we're going to be pedantic and nit-picky about claims, please use more precise counterclaims. It only takes a few extra words to clearly state you're talking about WASM + JS, which is an important distinction since many† people here are interested in WASM-only, without the JS (with the alternative in their mind being JS-only, without the WASM).

†In the spirit of pedantry, I mean many. Not all. Maybe not even a majority. But reasonably many.

Re: Pay attention to WebAssembly

#103

Post by chrismorgan »

smitop wrote: post #14
ramesh31 wrote: post #3

WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?

> garbage collection The draft WASM garbage collection proposal is partially implemented in Chromium, you can try it by enabling the enable-experimental-webassembly-features feature flag. > DOM access WebAssembly will never have direct access to the DOM, but at least with Rust the wasm-bindgen+web_sys crates make interacting with the DOM as simple as it is from JavaScript.

> WebAssembly will never have direct access to the DOM

I haven’t been paying much attention to WASM proposals for the last few years, but I thought that direct DOM access (avoiding JavaScript trampolining) was one of the driving goals of the reference type, interface type and garbage collection proposals. https://github.com/WebAssembly/proposals/issues/16 mentions “call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript”, and WASM’s high level goals document https://github.com/WebAssembly/design/blob/main/HighLevelGoa...> lists “access browser functionality through the same Web APIs that are accessible to JavaScript” (not “through JavaScript”, but “through the same APIs”). Am I misunderstanding things?

Re: Pay attention to WebAssembly

#104

Post by eezurr »

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.

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?

Re: Pay attention to WebAssembly

#105

Post by astrange »

wrnr wrote: post #24
ramesh31 wrote: post #3

WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?

GC is the job of the language, Rust doesn't need it

It does if it wants to interoperate with JS, unless you want to pin all memory when it's in the other runtime.

Re: Pay attention to WebAssembly

#106

Post by astrange »

tester756 wrote: post #42
labrador wrote: post #25

Why not LLVM intermediate representation (IR)? Why do we need a whole new assembly language?

I don't know but you can generate LLVM IR and then use wasm-ld in order to generate WASM :P

LLVM IR is not an executable target, it is a compiler IR. It is not safe, machine-independent, or even specified.

Re: Pay attention to WebAssembly

#108

Post by azakai »

charcircuit wrote: post #98
duskwuff wrote: post #90

Earlier quoted context omitted.

> [WASM is] still painfully slow compared to AVX or Neon enabled assembly. There's an open proposal to add SIMD intrinsics to WASM. https://github.com/WebAssembly/proposals/issues/1

That's an issue from 2018 with no replies to it.

For current status ("phase 3" as that link says is maybe not obvious enough), there is a solid spec and multiple implementations, see the "Fixed-width SIMD" line here:

https://webassembly.org/roadmap/

And here is an overview of this spec:

https://github.com/WebAssembly/simd/blob/master/proposals/si...

Re: Pay attention to WebAssembly

#109

Post by Ecco »

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?

Re: Pay attention to WebAssembly

#110

Post by hsheth2 »

syrusakbary wrote: post #26

Hey, I'm Syrus From Wasmer [1]! I'm really happy to see more people bringing their attention to the Wasm ecosystem. There are tons of opportunities on this space. Regarding WAPM [2] and how its development had become a bit dormant, expect news about it soon. Can't wait to share what we have been working on! [1] https://wasmer.io [2] https://wapm.io

Hey Syrus, that's great to hear - I'm excited to see what WAPM has in store!
Post reply on HN