How WebAssembly Changes Software Distribution • Hacker News Board

Re: How WebAssembly Changes Software Distribution

#21

Post by jkelleyrtp » Wed, Sep 09, 2020, 1:48 PM UTC

Rochus wrote: post #18

NationalPark wrote: post #17

Earlier quoted context omitted.

I think you're just misunderstanding what wasm is. Writing browser applications in any language was never a "core benefit proposition", it was just something that you could do with the tooling. The value has always been in the library/platform layer. Objectively pure wasm is faster than pure javascript, subjectively the additional type safety from writing in Rust (which is practically speaking what most people shippi…

To quote from https://webassembly.org/ : "Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." So did they mean only GUI-less client applications? EDIT: also e.g. this source https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... makes it clear that porting e.g. C++ GUI applications is an intended feature, not just a…

Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when providing computationally expensive features.

My favorite example is Rapier http://rapier.rs/, check out the 3D demos. It blows every JS physics engine out of the water, and it’s using Conrod, a native gui library which has a webgl backend.

Re: How WebAssembly Changes Software Distribution

#22

Post by MayeulC » Wed, Sep 09, 2020, 2:00 PM UTC

I am wondering if it would be a huge project to create an "http server" kind of Wasm binary. With php, rails or whatever server-side scripting a given project is using. I guess it would still require some quite extensive changes to the served HTML and js.

My use-case would be to create single instances of a server-side project, for demonstration purposes, or serverless operation. Things like providing a webapp for https://kanboard.org or NextCloud.

As a bonus, this could be combined with webtorrent, or other distributed mechanisms to let multiple "servers" interoperate seamlessly, regardless of their server/client usage. Of course, this can already be done today, but the Fediverse usually relies on DNS and certificates, while few server-side apps are completely distributed. This could provide an incentive, and ultimately make it easier to self-host (maybe even ultimately running the Wasm binaries instead of docker containers).

Re: How WebAssembly Changes Software Distribution

#23

Post by joshum97 » Wed, Sep 09, 2020, 2:01 PM UTC

I think Wasm outside the browser could benefit package managers. As far as I know, Rust and some other compiled languages distribute their crates/packages in source code form, which then have to be compiled before use. If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Plus, you’d get safety guarantees to make sure a package isn’t doing anything it hasn’t been permitted to do.

Re: How WebAssembly Changes Software Distribution

#24

Post by qppo » Wed, Sep 09, 2020, 2:16 PM UTC

joshum97 wrote: post #23

I think Wasm outside the browser could benefit package managers. As far as I know, Rust and some other compiled languages distribute their crates/packages in source code form, which then have to be compiled before use. If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Plus, you’d get safety guarantees to make sure a package isn’t doing anything it hasn’t…

I dont think it would help at all for compiled languages actually. The reason that they distribute source instead of binaries is mostly due to feature flags and conditional compilation.

Seems a bit off track too. WASM is a very lossy compile target and that's not acceptable for most compiles languages which need explicitness and assumptions about the target machine for their optimizations (ones written by the programmer, not the compiler). And the security concerns are tricky - sand boxing is always expensive.

Re: How WebAssembly Changes Software Distribution

#25

Post by CyberDildonics » Wed, Sep 09, 2020, 2:17 PM UTC

Rochus wrote: post #2

Despite the author's obvious enthusiasm: WASM has a long way to go before it is really useful. From my humble perspective there was not much progress since the 1.0 release. As long as every access to the host (especially the GUI) is tunneled via JavaScript, one shouldn't be surprised about the low performance and the enormous memory consumption. See what happens behind the scenes when you set a pixel in the SDL API w…

> low performance and the enormous memory consumption

That has not been what I've seen from it. People have made video editors and ported game into web pages. You make a lot of claims in this thread about speed and memory but don't back any of them up.

Re: How WebAssembly Changes Software Distribution

#26

Post by Rochus » Wed, Sep 09, 2020, 2:19 PM UTC

jkelleyrtp wrote: post #21

Rochus wrote: post #18

Earlier quoted context omitted.

To quote from https://webassembly.org/ : "Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." So did they mean only GUI-less client applications? EDIT: also e.g. this source https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... makes it clear that porting e.g. C++ GUI applications is an intended feature, not just a…

Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when…

Thanks for the link. I tried the cubes 3d demo which takes about 45 seconds on my laptop until no cube moves anymore (around step 590); probably not the expected performance; if I find time I will run the Rust version locally.

Re: How WebAssembly Changes Software Distribution

#27

Post by dmitriid » Wed, Sep 09, 2020, 2:20 PM UTC

joshum97 wrote: post #23

I think Wasm outside the browser could benefit package managers. As far as I know, Rust and some other compiled languages distribute their crates/packages in source code form, which then have to be compiled before use. If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Plus, you’d get safety guarantees to make sure a package isn’t doing anything it hasn’t…

> If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them.

Why though? For compiled languages it would make significantly more sense to distribute them in LLVM intermediate representation than WASM.

Re: How WebAssembly Changes Software Distribution

#28

Post by Rochus » Wed, Sep 09, 2020, 2:22 PM UTC

CyberDildonics wrote: post #25

Rochus wrote: post #2

Despite the author's obvious enthusiasm: WASM has a long way to go before it is really useful. From my humble perspective there was not much progress since the 1.0 release. As long as every access to the host (especially the GUI) is tunneled via JavaScript, one shouldn't be surprised about the low performance and the enormous memory consumption. See what happens behind the scenes when you set a pixel in the SDL API w…

> low performance and the enormous memory consumption That has not been what I've seen from it. People have made video editors and ported game into web pages. You make a lot of claims in this thread about speed and memory but don't back any of them up.

Here are some examples: https://www.qt.io/qt-examples-for-webassembly ; some of them don't even start on my 32 bit machine because more than 2GB RAM would need to be allocated.

EDIT: I'm using Firefox 78.0.2 on Linux i386.

Re: How WebAssembly Changes Software Distribution

#29

Post by ralphc » Wed, Sep 09, 2020, 2:27 PM UTC

Rochus wrote: post #2

Despite the author's obvious enthusiasm: WASM has a long way to go before it is really useful. From my humble perspective there was not much progress since the 1.0 release. As long as every access to the host (especially the GUI) is tunneled via JavaScript, one shouldn't be surprised about the low performance and the enormous memory consumption. See what happens behind the scenes when you set a pixel in the SDL API w…

Google seems to think it is currently useful. They have a WASM back end to tensorflow.js to use when WebGL isn’t available and you only have CPUs to run on https://blog.tensorflow.org/2020/03/introducing-webassembly-...

Re: How WebAssembly Changes Software Distribution

#30

Post by CyberDildonics » Wed, Sep 09, 2020, 2:33 PM UTC

Rochus wrote: post #26

jkelleyrtp wrote: post #21

Earlier quoted context omitted.

Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when…

Thanks for the link. I tried the cubes 3d demo which takes about 45 seconds on my laptop until no cube moves anymore (around step 590); probably not the expected performance; if I find time I will run the Rust version locally.

I tried the same thing and it took 4 seconds on my 8 year old computer.