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

61–70 of 100 posts

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

#61

Post by lxgr »

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!".

I think many people like the idea of bytecode, but not the implementation of Java/the JVM (especially if they have an existing codebase or don't want to start a new one in Java), and I think that's pretty fair.

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

#62

Post by leptons »

darby_eight wrote: post #27
leptons wrote: post #23

Earlier quoted context omitted.

Not sure why you claim it's a "terrible desktop experience"? What's wrong with it, please explain.

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.

>ugly, and doesn't conform to native interface expectations

These are not strictly a result of targeting browsers for desktop applications, it's strictly down to design decisions that have nothing to do with how its implemented. I've seen plenty of wonky desktop/native applications that took way too many liberties with design whimsy that end up being a worse user experience than any webpage.

I also can't complain about Slack being slow because it doesn't seem slow to me and I'm part of a very large organization. I also use VS Code which is based on browser tech, and it's working really well. And I love that VS Code also works in the web applications I create. YMMV.

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

#63

Post by leptons »

chompychop wrote: post #29
leptons wrote: post #21

Earlier quoted context omitted.

Running FFMPEG in the browser through WASM is a game changer for me.

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.

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

#64

Post by robocat »

bsder wrote: post #58
azakai wrote: post #11

This quote from the end of the article is good: > With this in mind, maybe Wasm is mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis. I think that's correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In t…

> the Web side is largely complete and successful Can WASM access the DOM? Or do you still have to go through a glacially slow Javascript export shim?

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%

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

#65

Post by dartos »

lxgr wrote: post #49
dartos wrote: post #13

Earlier quoted context omitted.

Regular… servers? Wasm is currently an alternative nobody asked for.

Seems like you’re jumping from “I didn’t ask for it” to “nobody asked for it”. What if you want to run your unmodified executable on various architectures? The JVM kind of does that, but not nearly every language can compile to that as a target, and if you want WASM-like sandboxing you need to deal with security managers, which is no fun at all (and I’ve never seen it done successfully for any non-Java software).

When I’ve tried writing programs targeting wasm (in assemblyscript and rust) and platforms for them to run on, special care had to be taken to treat each language differently (how they encode strings differently for example.)

This means that not only do I need to take special care that my code can compile to wasm, but the platform devs (also me, in this case) needs to take special care to support a variety of different design choices in various wasm toolchains.

I’d rather just use SELinux containers and let the OS handle security.

Maybe Firecracker VMs like AWS lambda does.

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

#66

Post by darby_eight »

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.

Compared to what? I honestly don't know what other people consider state of the art interfaces if native apps are excluded.

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

#67

Post by darby_eight »

leptons wrote: post #62
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.

>ugly, and doesn't conform to native interface expectations These are not strictly a result of targeting browsers for desktop applications, it's strictly down to design decisions that have nothing to do with how its implemented. I've seen plenty of wonky desktop/native applications that took way too many liberties with design whimsy that end up being a worse user experience than any webpage. I also can't complain abo…

> These are not strictly a result of targeting browsers for desktop applications, it's strictly down to design decisions that have nothing to do with how its implemented.

It's not "strictly" down to this; even if you want to implement interfaces that fit in with native ones, web browsers simply don't expose many native features via the DOM/CSS. It's a question of actual capabilities, not of this hypothetical design process that doesn't care about native integration.

(Of course, there will always be terrible native interfaces. Arguably Apple is the worst offender here!)

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

#68

Post by lxgr »

dartos wrote: post #65
lxgr wrote: post #49

Earlier quoted context omitted.

Seems like you’re jumping from “I didn’t ask for it” to “nobody asked for it”. What if you want to run your unmodified executable on various architectures? The JVM kind of does that, but not nearly every language can compile to that as a target, and if you want WASM-like sandboxing you need to deal with security managers, which is no fun at all (and I’ve never seen it done successfully for any non-Java software).

When I’ve tried writing programs targeting wasm (in assemblyscript and rust) and platforms for them to run on, special care had to be taken to treat each language differently (how they encode strings differently for example.) This means that not only do I need to take special care that my code can compile to wasm, but the platform devs (also me, in this case) needs to take special care to support a variety of differe…

That's of course an option if you're fine with your deployables being architecture- and OS-dependent, and very often that's the case.

But for when it's not, I think a platform-independent and language-agnostic bytecode standard is a valuable thing to have.

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

#69

Post by mardifoufs »

DarkNova6 wrote: post #15
austin-cheney wrote: post #7

Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a J…

But Blazor seems to do a fine job replacing JS with C#? If you really want go to all-native JS because it has advantages, sure you can do. But what I see are bloated SPAs written in a language not designed for large software, based on an environment that likes to change and break things. It's abstractions upon abstractions get a hold of this mess. I don't see why WASM couldn't compete.

Blazor is peak corporate software. It's fine for internal apps but a nightmare for users that aren't forced to use something (ie, not internal apps). Blazor WASM in particular is the slowest web framework around, the layout is always broke and even on websites that are created to showcase blaze it absolutely is riddled with layout bugs the moment you use it on mobile.

React and other JS native frameworks, as much as they are looked down at from back end (especially dotnet devs) are miles ahead in terms of user experience and even actual development experience (good luck doing more than forms and basic stuff on blazor wasm for example).

It's for c#/dotnet devs that have a single hammer and hate learning new things so they will use csharp everywhere.

As to your point, can you show me a single user facing, non demo app or blazor related website that actually runs on blazor (especially wasm blazor) ? I'm curious to see why you think it's actually replacing or capable of replacing js on the front end.

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

#70

Post by marcosdumay »

robocat wrote: post #64
bsder wrote: post #58

Earlier quoted context omitted.

> the Web side is largely complete and successful Can WASM access the DOM? Or do you still have to go through a glacially slow Javascript export shim?

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 problems with it by batching their data and interfacing as few times as possible, but just like on the JS DOM interface, this is a severe constrain on your code.

Post reply on HN