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

41–50 of 100 posts

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

#41

Post by pjmlp »

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 doing a fine job being a home for WebForms and Silverlight refugees, how far it will stay relevant remains to be seen.

On my job I have zero reasons to suggest it, given the split between FE and BE teams.

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

#42

Post by triyambakam »

dcode wrote: post #19
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 Perhaps from a C++ perspective, say a monolith with kilobytes of bindings driving a canvas. Yet > the original purpose of Wasm includes, as per the charter, "and interoperate gracefully with JavaScript and the Web", which is far from complete and, thanks to WASI and the Component Model, hardly improving. I guess it will remain a mystery how WASI could basically replac…

Can you elaborate on why you think WASI and the Component Model is ruining that? I am only vaguely familiar with the state of WASM and squinting from this distance it seemed that WASI and the CM were meant to really improve a lot of problems. I'm not familiar with WebIDL bindings

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

#43

Post by azakai »

dcode wrote: post #19
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 Perhaps from a C++ perspective, say a monolith with kilobytes of bindings driving a canvas. Yet > the original purpose of Wasm includes, as per the charter, "and interoperate gracefully with JavaScript and the Web", which is far from complete and, thanks to WASI and the Component Model, hardly improving. I guess it will remain a mystery how WASI could basically replac…

> Perhaps from a C++ perspective, say a monolith with kilobytes of bindings driving a canvas.

I get the desire for something more "elegant/clean" in this space, but JS is just very hard to beat on the bindings/glue side. I believe that's why approaches like WebIDL bindings did not turn out to be more efficient. I measured that on both code size and speed in Emscripten, for example, back in the day, and JS was good enough.

With WasmGC it is today possible to ship very small binaries, and the size of the bindings alongside them is generally not an issue, from what I hear from WasmGC-using toolchains like Java, Kotlin, and Dart. In fact they benefit a lot from the flexibility of those bindings, e.g. by being able to pull in random JS things (like strings support, RegExp, etc.).

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

#44

Post by coldtea »

falcor84 wrote: post #24
darby_eight wrote: post #17

Earlier quoted context omitted.

Why would someone use this for desktop applications if you aren't obligated to target a web browser? The only benefit this brings is access to browser rendering, which is a pretty terrible desktop experience (see e.g. slack, spotify).

Slack is terrible? In what sense?

Slow, memory hog, and incredibly bloated for what it does (not much different to what IM clients did 25 years ago on 1/100 the resources).

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

#45

Post by pjmlp »

I really don't see much of a value outside the browser, other than an avenue for startups to resell yet another bytecode based platform, as if we haven't had enough since UNCOL (1958).

The ongoing attempts to bring back application servers, but with Kubernetes, WASM and plenty of YAML, is a kind of tragic irony.

And on the browser, if one needs performance it is better served with GPU code than WebAssembly, other than bringing existing libraries into the browser.

At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.

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

#46

Post by coldtea »

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.

Sure, if one is easily satisfied and has low expectations, it's perfectly satisfying!

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

#47

Post by marcosdumay »

01HNNWZ0MV43FF wrote: post #9
iwillsayit wrote: post #8

The real value in Wasm is in the Web use case: bring to the most popular platform software that was impossible (or very difficult) to bring before. Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ... Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attemp…

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.

Well, it's possible that we can only create a serious application-aware OS security layer by forcing people to write an emulator for some random VM... But I'd expect it to be easier to go and write application-aware security on your OS.

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

#48

Post by orra »

useerup wrote: post #35
HdS84 wrote: post #6

Earlier quoted context omitted.

What about dotnet? Irc it was even there before rust?

The first .NET Blazor "webassembly" was the .NET runtime ported to Webassembly, but where developer code would actually be the same type of IL (Microsoft's Intermediate Labguage) as .NET runs on Windows and Linux. Unlike those platforms however, the IL was actually interpreted by the ported .NET runtime. Only the runtime was actually running as WASM. To this day this is still the default, but now you can use a compil…

Just to add to this answer, here's [1] how to do .NET with AOT compilation, without needing Blazor.

[1] https://devblogs.microsoft.com/dotnet/use-net-7-from-any-jav...

Such an app needs to download a megabyte of runtime. This isn't tiny. Yet, for corporate apps I think it's okay? Apps start reasonably quickly, although not instantly, maybe 2 seconds.

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

#49

Post by lxgr »

dartos wrote: post #13
lxgr wrote: post #10

Earlier quoted context omitted.

> Wasm on the Server is a fad Why? Or rather, what's the alternative?

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).

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

#50

Post by kamikazeturtles »

callahad wrote: post #20
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?

Figma has been powered by WebAssembly for the past 7 years.

What parts of Figma though? Is it just used for cpu intensive operations like triangulation of svgs to render in webgl or is the site's core logic all done is wasm?

I'm sorry, I don't use Figma but I'm really curious about its tech stack

Post reply on HN