Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly adoption: Is slow and steady winning the race?

thenewstack.io

Post reply on HN
Print view View original

71–80 of 100 posts

Re: WebAssembly adoption: Is slow and steady winning the race?

#71

Post by mc_woods »

leptons wrote: post #63
chompychop wrote: post #29

Earlier quoted context omitted.

But isn't it really slow (like 20x or so) than native FFMPEG?

No, not for me. I'm not transcoding 8k videos with it or anything like that. My use case is extracting thumbnails and video color info, basically transcoding to raw 100px x 100px clips and grabbing color info from that. The user would rather it takes as long as it takes than have to charge them a subscription fee to host the transcoding in the cloud.

Yup. WASM lacks the "domain specific" acceleration available to native code. So you miss out on any hardware codec support. Same is true for openSSL, there is a bunch of encryption acceleration in modern CPUs that WASM can't access at the moment.

Re: WebAssembly adoption: Is slow and steady winning the race?

#72

Post by davidalayachew »

lxgr wrote: post #54
Traubenfuchs wrote: post #25

Earlier quoted context omitted.

> VMs like Python and Java require huge effort to embed. As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes. Mind y…

Let's please not justify bad/bloaty plugin/extension runtimes with "at least it's not as bad as Electron". A framework producing a Hello World application, even if it has a GUI, with a double- or triple-digit size in MB and memory consumption on the same order, is doing something very wrong.

The example in question is very much a "include-more-than-you-need-by-default" problem. So, bloat.

Java lets you include only the parts of the JDK that you need for your app. These parts are called modules.

Unfortunately, all modules MUST include the base module (java.base), which is ~22MB. And if you add a GUI (java.desktop), that's another ~13MB. And since the linked example uses Java FX, there is yet another layer on top of that.

Java is doing a lot of work to bring that number down by a lot. More to come.

Re: WebAssembly adoption: Is slow and steady winning the race?

#73

Post by Gormo »

kristiandupont wrote: post #40
darby_eight wrote: post #27

Earlier quoted context omitted.

I already answered re: slack above, but spotify is just slow, ugly, and doesn't conform to native interface expectations. Granted, this is also largely true of iTunes, but the issue is much less flagrant there.

Native interface expectations are only really a thing on MacOS at this point. I agree that they are often slower, but "ugly" is an opinion, one that I happen to disagree with. Native widgets feel primitive and dated to me.

> Native widgets feel primitive and dated to me.

Have you tried using a different theme?

Re: WebAssembly adoption: Is slow and steady winning the race?

#74

Post by fabrice_d »

marcosdumay wrote: post #70
robocat wrote: post #64

Earlier quoted context omitted.

I thought it was the DOM API that was glacially slow? Would WASM directly accessing the DOM be an improvement of more than say 5%

The DOM has two different APIs, a batch and a piecewise ones. The batch one is incredibly optimized in all the browsers, while the piecewise one usually do not receive any attention at all. Now, FFI the interface between WASM and JS is incredibly slow. That's by design. I guess the goal was to push every important API into WASM, and leave the FFI just for interfacing code, like on normal environments. People avoid pr…

> The DOM has two different APIs, a batch and a piecewise ones. The batch one is incredibly optimized in all the browsers, while the piecewise one usually do not receive any attention at all.

What are you talking about?

Re: WebAssembly adoption: Is slow and steady winning the race?

#75

Post by kristiandupont »

darby_eight wrote: post #66
kristiandupont wrote: post #40

Earlier quoted context omitted.

Native interface expectations are only really a thing on MacOS at this point. I agree that they are often slower, but "ugly" is an opinion, one that I happen to disagree with. Native widgets feel primitive and dated to me.

> Native widgets feel primitive and dated to me. Compared to what? I honestly don't know what other people consider state of the art interfaces if native apps are excluded.

Compared to the web. I consider apps like Linear to be ones spearheading UI paradigms at the moment.

Re: WebAssembly adoption: Is slow and steady winning the race?

#76

Post by kristiandupont »

Gormo wrote: post #73
kristiandupont wrote: post #40

Earlier quoted context omitted.

Native interface expectations are only really a thing on MacOS at this point. I agree that they are often slower, but "ugly" is an opinion, one that I happen to disagree with. Native widgets feel primitive and dated to me.

> Native widgets feel primitive and dated to me. Have you tried using a different theme?

I use MacOS so I don't think that's possible (unless you mean "dark mode"). But in any case, I am not talking about colors but general fidelity.

Re: WebAssembly adoption: Is slow and steady winning the race?

#77

Post by bobbylarrybobby »

fabrice_d wrote: post #74
marcosdumay wrote: post #70

Earlier quoted context omitted.

The DOM has two different APIs, a batch and a piecewise ones. The batch one is incredibly optimized in all the browsers, while the piecewise one usually do not receive any attention at all. Now, FFI the interface between WASM and JS is incredibly slow. That's by design. I guess the goal was to push every important API into WASM, and leave the FFI just for interfacing code, like on normal environments. People avoid pr…

> The DOM has two different APIs, a batch and a piecewise ones. The batch one is incredibly optimized in all the browsers, while the piecewise one usually do not receive any attention at all. What are you talking about?

I'm going to go out on a limb and guess that they mean that if you want to modify the DOM with JS, you cannot batch your updates into an atomic transaction; every modification is applied immediately. However, presumably there is something, somewhere, that can collect modifications and apply them concurrently, because this would be such an insanely obvious optimization to miss for non-JS-driven updates to the DOM (such as initial page load).

Re: WebAssembly adoption: Is slow and steady winning the race?

#78

Post by emporas »

lxgr wrote: post #52
LunaSea wrote: post #16

Earlier quoted context omitted.

Really? I can't think of a mainstream (as in used daily) site that uses WASM. Do you have some in mind?

Lichess and Chess.com use it for local position evaluation and playing against the computer (in analysis).

Yep, they compiled Stockfish to wasm. Now everyone has access to the best chess engine in the world, right there in the browser, no need to install anything. Really nifty.

Re: WebAssembly adoption: Is slow and steady winning the race?

#79

Post by dmingod666 »

Traubenfuchs wrote: post #25
01HNNWZ0MV43FF wrote: post #9

Earlier quoted context omitted.

I have high hopes for wasm on the desktop for app plugins. Loading a whole binary DLL/SO is such a risk. VMs like Lua don't give you enough performance. VMs like Python and Java require huge effort to embed. Once the SIMD stuff is in, it may even have enough performance for music plugins. wasm codecs would be real cool too. Nobody likes having to build and install ffmpeg. `ffmpeg-4.0.wasm`... just imagine.

> VMs like Python and Java require huge effort to embed. As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes. Mind y…

very good alternative is wails

6-10mb single binary

use any frontend js tech you want

automatically go functions exposed to the js side so you don't need to think about making endpoints, it makes and uses a websockets between the binary and the ui

uses WebView2 and not chrome

Re: WebAssembly adoption: Is slow and steady winning the race?

#80

Post by emporas »

pjmlp wrote: post #59
lxgr wrote: post #53

Earlier quoted context omitted.

> if one needs performance it is better served with GPU code than WebAssembly What? No! Would you suggest replacing e.g. the Linux kernel (parts of which are very performance critical) with GPU code too? WebGPU is great for, well, GPU-like compute! That's not nearly all performance-critical compute. One example: Stockfish, a top chess engine, is exclusively CPU-based, and runs perfectly in WASM. > At least we got the…

Linux kernel isn't supposed to run in the browser. Indeed WASM is nothing like yet bytecode being capitalised by startups, in search of the next Java goldmine, by folks that enjoy bashing about it. /s App servers bad, Kubernetes with WASM, "oh boy that is soooo cool!".

"Write once, run everywhere" is pretty important goal to achieve. When a project has to be written for a platform, and then ported to other platforms, then some ports or all of them turn out to be pretty bad.

Essentially the program runs only on one platform well. The ports also may turn out to be a significant burden depending on the size of the project, which usually grows over time.

Take Adobe as an example. It's port of Linux was pretty much unusable, only many years later to be revealed that only 2 programmers were responsible for maintaining the codebase.

Post reply on HN