How WebAssembly Changes Software Distribution • Hacker News Board

Re: How WebAssembly Changes Software Distribution

#11

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

tester34 wrote: post #7

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…

>WASM has a long way to go before it is really useful. I disagree. I can already write decent C# applications that run in browser while using already existing C# libraries for e.g parsing text and it will run fine. So, WebAssembly allows me to use existing code C# and move it to the browser while developing in my fancy language instead of Javascript and I think it (dropping js) is very solid pros I just think tooling…

> I can already write decent C# applications that run in browser .. it will run fine.

It is undoubtedly technically possible, but not really practicable, unless you accept an exorbitant speed-down and much higher memory consumption than e.g. when running in DotNet. Personally, I don't find that attractive in any way, nor do I find it particularly efficient.

Re: How WebAssembly Changes Software Distribution

#12

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

NationalPark wrote: post #6

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…

I think you have the performance differences backwards, wasm is usually quite a bit faster than comparable javascript. While it's true that right now there are additional overhead costs for browser APIs, that's changing, but it's also misunderstanding the value proposition of wasm. You can write an entire front end web application if you want, but it really shines for library code and computationally expensive code.…

> wasm is usually quite a bit faster than comparable javascript

Even if true, it doesn't help much if you have to marshall through JS for nearly every call.

> You can write an entire front end web application if you want

One of the core benefit propositions was the possibility to write browser applications in any language, not just JS.

Re: How WebAssembly Changes Software Distribution

#13

Post by tester34 » Wed, Sep 09, 2020, 1:22 PM UTC

Rochus wrote: post #11

tester34 wrote: post #7

Earlier quoted context omitted.

>WASM has a long way to go before it is really useful. I disagree. I can already write decent C# applications that run in browser while using already existing C# libraries for e.g parsing text and it will run fine. So, WebAssembly allows me to use existing code C# and move it to the browser while developing in my fancy language instead of Javascript and I think it (dropping js) is very solid pros I just think tooling…

> I can already write decent C# applications that run in browser .. it will run fine. It is undoubtedly technically possible, but not really practicable, unless you accept an exorbitant speed-down and much higher memory consumption than e.g. when running in DotNet. Personally, I don't find that attractive in any way, nor do I find it particularly efficient.

I've been trying it on small CRUDs, so nothing impressive was happening on the front side, so I didn't really notice those problems.

I think DLLs size and lack of DOM access was the biggest problem at the moment I've been testing it

Re: How WebAssembly Changes Software Distribution

#14

Post by Rochus » Wed, Sep 09, 2020, 1:23 PM UTC

wffurr wrote: post #9

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…

It does feel like WebAssembly development has stalled after the initial release. There are proposals for reference types, garbage collection, and host bindings that would greatly expand a WebAssembly binary's capabilities, but they haven't been implemented in any browser, much less standardized yet. WebAssembly proposals tracker: https://github.com/WebAssembly/proposals WebAssembly reference types ( https://github.co…

That is also my impression.

And the fact that Mozilla has problems and has to realign is certainly not helping.

Re: How WebAssembly Changes Software Distribution

#15

Post by Rochus » Wed, Sep 09, 2020, 1:26 PM UTC

tester34 wrote: post #13

Rochus wrote: post #11

Earlier quoted context omitted.

> I can already write decent C# applications that run in browser .. it will run fine. It is undoubtedly technically possible, but not really practicable, unless you accept an exorbitant speed-down and much higher memory consumption than e.g. when running in DotNet. Personally, I don't find that attractive in any way, nor do I find it particularly efficient.

I've been trying it on small CRUDs, so nothing impressive was happening on the front side, so I didn't really notice those problems. I think DLLs size and lack of DOM access was the biggest problem at the moment I've been testing it

Try with a representative application where a whole JS based single page app is implemented in another language than JS (e.g. C++/Qt), which is one of the core benefit propositions made by WASM.

Re: How WebAssembly Changes Software Distribution

#16

Post by Rochus » Wed, Sep 09, 2020, 1:29 PM UTC

flohofwoe wrote: post #10

Rochus wrote: post #8

Earlier quoted context omitted.

> but this doesn't make sense anywhere else either But that's exactly what happens when you draw into an SDL raster window. Even when you have vector drawing operations on higher level, eventually pixels are modified; you can of course combine drawing operations and transport a patch of the screen to the host, but this still goes through an impressive machinery with a lot of copying. > All of this combined makes the…

SDL also does other weird things (or at least did), like rendering each 2D sprite in its own draw call. The way to handle something like setting unique pixels is to keep a pixel buffer in memory on the WASM side, set the pixels in there, and then once per frame copy this pixel buffer into a WebGL texture and render this through a single WebGL draw call, or blit the pixel buffer to a 2D canvas if WebGL is not an optio…

Unfortunately with WASM we don't have so many other ways to migrate a desktop GUI application at the moment. If I have to redesign the whole existing GUI application to run on WASM, the technology is not really attractive.

Re: How WebAssembly Changes Software Distribution

#17

Post by NationalPark » Wed, Sep 09, 2020, 1:29 PM UTC

Rochus wrote: post #12

NationalPark wrote: post #6

Earlier quoted context omitted.

I think you have the performance differences backwards, wasm is usually quite a bit faster than comparable javascript. While it's true that right now there are additional overhead costs for browser APIs, that's changing, but it's also misunderstanding the value proposition of wasm. You can write an entire front end web application if you want, but it really shines for library code and computationally expensive code.…

> wasm is usually quite a bit faster than comparable javascript Even if true, it doesn't help much if you have to marshall through JS for nearly every call. > You can write an entire front end web application if you want One of the core benefit propositions was the possibility to write browser applications in any language, not just JS.

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 shipping wasm write their source code in) makes people more confident that their complex code works.

Outside of a few hobbyists, nobody is writing entire web applications in wasm. We already have great frameworks for dealing with UI/DOM stuff.

Re: How WebAssembly Changes Software Distribution

#18

Post by Rochus » Wed, Sep 09, 2020, 1:34 PM UTC

NationalPark wrote: post #17

Rochus wrote: post #12

Earlier quoted context omitted.

> wasm is usually quite a bit faster than comparable javascript Even if true, it doesn't help much if you have to marshall through JS for nearly every call. > You can write an entire front end web application if you want One of the core benefit propositions was the possibility to write browser applications in any language, not just JS.

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 silly idea of some hobbyists.

Re: How WebAssembly Changes Software Distribution

#19

Post by gameswithgo » Wed, Sep 09, 2020, 1:44 PM UTC

Rochus wrote: post #12

NationalPark wrote: post #6

Earlier quoted context omitted.

I think you have the performance differences backwards, wasm is usually quite a bit faster than comparable javascript. While it's true that right now there are additional overhead costs for browser APIs, that's changing, but it's also misunderstanding the value proposition of wasm. You can write an entire front end web application if you want, but it really shines for library code and computationally expensive code.…

> wasm is usually quite a bit faster than comparable javascript Even if true, it doesn't help much if you have to marshall through JS for nearly every call. > You can write an entire front end web application if you want One of the core benefit propositions was the possibility to write browser applications in any language, not just JS.

>Even if true, it doesn't help much if you have to marshall through JS for nearly every call.

If your particular front end code is dominated by many calls to the DOM, then WASM may be a net performance loss currently, yes.

In cases where you are doing something computationally heavy then periodically updating the dom with results, then WASM can be a huge win.

In cases where the performance is fine either way, being able to use one language server and client is a huge win. I am already doing useful things with WASM and Rust. It is a very very nice workflow.

Re: How WebAssembly Changes Software Distribution

#20

Post by maxgraey » Wed, Sep 09, 2020, 1:46 PM UTC

wffurr wrote: post #9

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…

It does feel like WebAssembly development has stalled after the initial release. There are proposals for reference types, garbage collection, and host bindings that would greatly expand a WebAssembly binary's capabilities, but they haven't been implemented in any browser, much less standardized yet. WebAssembly proposals tracker: https://github.com/WebAssembly/proposals WebAssembly reference types ( https://github.co…

> but they haven't been implemented in any browser, much less standardized yet.

Reference types already implemented. GC is not really needed for non-managed languages like C++ or Rust. Interface types in progress.

See this: https://webassembly.org/roadmap