Live data from Hacker News

Pay attention to WebAssembly

harshal.sheth.io

71–80 of 251 posts

Re: Pay attention to WebAssembly

#71

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

SPIR is special purpose and can't be compared. JVM in the browser might be a similar comparison, but back then we didn't have the threats we have today. We now have closed hardware, closed operating system, and even closed browsers. The browsers are just extensions of these closed companies. We now more than ever need an open computing stack untethered from the underlying chips, devices, operating systems, etc.

Re: Pay attention to WebAssembly

#72

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?

I doubt JavaScript will ever be fully replaced here. JavaScript is a pretty good language for these use cases, and it has a huge ecosystem.

But if you want to use a front end framework that compiles to warm then you can do that today. Rust, Go, C# and more all have libraries (only Rust really makes sense though, as the others involve shipping a huge runtime). Just don’t expect it to be any faster than JS.

Re: Pay attention to WebAssembly

#73

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

> WebAssembly is full of potential. Eh... from what I can tell from a mostly casual glance at it (enough for a half-hearted half-complete attempt at writing my own VM for it), I'd say that it is almost a good idea. A lot of the base concepts show a lot of potential, but I feel like the implementation is full design-by-committee derp. Why are there only 32 and 64 bit types? Why are there parametric instructions at all…

Even if it's weird and designed by committee, at least we have agreement with all browsers. IMO, WebAssembly has got over the biggest hurdle: agreement in a format to feed an abstract processor to program it to do math. Nothing more, nothing less. In the web ecosystem, the most powerful thing right now is agreement. The design might be ugly or weird, but it works and it's done. Lets build on top of it.

Re: Pay attention to WebAssembly

#74

I am surprised there is no isolation schema for binaries. WASM may look lite and fast compared to Docker, but its still painfully slow compared to AVX or Neon enabled assembly. We went from VMs to Containers. From Containers to WASM. Now, I guess, we just need to learn how to properly isolate simple binaries.

> Now, I guess, we just need to learn how to properly isolate simple binaries.

I think unikernels are appealing as a solution. Every program is "the operating system" running in something like Firecracker on a baremetal host.

Re: Pay attention to WebAssembly

#75
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.

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

Re: Pay attention to WebAssembly

#76
post #41

Earlier quoted context omitted.

WebAssembly itself is independent of the web or the browser. Therefore it is impossible for it to depend on Web Workers or SharedArrayBuffers. Rather it is the browser implementation of WASM (the embedder) that uses these technologies you seem to hate. Just think about it, you even mentioned serverless cloud apps. Are these cloud apps going to run inside a browser and therefore use Web Workers for threading? The answ…

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?

Re: Pay attention to WebAssembly

#77
post #75
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.

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.

Re: Pay attention to WebAssembly

#78
post #23

Cross-language interactions suck. We need WebAssembly components and good code generators for a critical mass of languages before people actually start to use Wasm across different languages. Unpopular opinion: Users will eventually realize that the lowest common denominator between languages is ... a BYTE STREAM (e.g. JSON/CSV/HTML), or what I think of as shell / Unix / Web -style composition. IDLs and code generato…

I don't think it is unpopular at all. I started writing some emacs plugin in the past, then ported the whole thing to the browser, and since then I have a hard time thinking in any other terms as byte stream, even though I like to call it buffer.

Re: Pay attention to WebAssembly

#79

Earlier quoted context omitted.

> WebAssembly is full of potential. Eh... from what I can tell from a mostly casual glance at it (enough for a half-hearted half-complete attempt at writing my own VM for it), I'd say that it is almost a good idea. A lot of the base concepts show a lot of potential, but I feel like the implementation is full design-by-committee derp. Why are there only 32 and 64 bit types? Why are there parametric instructions at all…

Even if it's weird and designed by committee, at least we have agreement with all browsers. IMO, WebAssembly has got over the biggest hurdle: agreement in a format to feed an abstract processor to program it to do math. Nothing more, nothing less. In the web ecosystem, the most powerful thing right now is agreement. The design might be ugly or weird, but it works and it's done. Lets build on top of it.

Frankly, fuck the web. It's a warzone where Google throws its weight around to enhance the ability of advertisers to make our lives terrible. I was more interested in WASM as a universal VM for all platforms, but it doesn't fit nearly as well for that as it could because of some of the strange decisions this web-focused committee made.

At least Java was also designed to run on not-the-web.

Re: Pay attention to WebAssembly

#80
post #22

WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?

Why not .NET? Surely Microsoft is better than Oracle

Surely being eaten by a shark is better than torn apart by a hyena.
Post reply on HN