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

31–40 of 100 posts

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

#31

Post by 6510 »

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?

The client was specifically designed for browsing web pages. It has all kinds of features for it. A chat client would be quite different. The file menu would load and save chats. The context menu would have chatty things in it. You have to close the application to lose any application state. We've kinda forgot how nice it is to have a desktop application. 30-35 years ago function keys where cool. I cant remember the last time I've used one. I also cant remember the last time I've used the top menu with alt keys. The browser also has to limit functionality for safety reasons.

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

#32

Post by azakai »

LunaSea wrote: post #16
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…

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

Sure, many major sites use it, such as Zoom, Google Sheets, and Photoshop. As the article mentions, you wouldn't know they are using Wasm under the hood unless you open the devtools and inspect the details.

Many more examples, such as those mentioned in this talk about Wasm usage in Google:

https://www.youtube.com/watch?v=2En8cj6xlv4

They mention Google Photos, Google Meet, Google Earth, TensorFlow.js, Ink, CanvasKit, Flutter, etc. And that is just inside Google - many other companies are using it, big and small, such as Figma, Unity, Adobe, etc.

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

#33

Post by 6510 »

darby_eight wrote: post #26
falcor84 wrote: post #24

Earlier quoted context omitted.

Slack is terrible? In what sense?

I mean, it's slow, it uses about ~500x more memory than my irc client does, the interface doesn't meld with the rest of the OS, the options for end-users to actually customize how the app works are direly limited... I'm probably missing gripes but thankfully I haven't had to use it for a couple of years.

It's hard to list all the differences. Say, file association is quite useful.

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

#34

Post by CharlesW »

LunaSea wrote: post #16
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…

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

uBlock Origin first used Wasm in 2018: https://www.ghacks.net/2018/12/03/ublock-origin-performance-...

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

#35

Post by useerup »

HdS84 wrote: post #6
aquova wrote: post #4

> “While obviously C/C++ and Rust came to the ecosystem early on, other languages seemed to slowly put a ‘toe in the water’, first having limited support and then gradually investing more as usage takes off.” This is the biggest limitation for me. I like WASM fine, but anytime I want to use it I have to turn back to Rust. I like Rust fine, but without support in other languages, it's not necessarily worth diving into…

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 compiler to compile from IL to WASM, and then run full WASM code in the browser. This toolchain is a bit slower on build, but the code will run much faster.

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

#37

Post by maxcoder4 »

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.

It's loading untrusted python different from loading untrusted dll/so? Unless your use some dedicated sandbox, I think they're equally insecure. I guess a bigger problem with native plugins is that they're not (usually) platform independent.

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

#38

Post by eviks »

6510 wrote: post #31
falcor84 wrote: post #24

Earlier quoted context omitted.

Slack is terrible? In what sense?

The client was specifically designed for browsing web pages. It has all kinds of features for it. A chat client would be quite different. The file menu would load and save chats. The context menu would have chatty things in it. You have to close the application to lose any application state. We've kinda forgot how nice it is to have a desktop application. 30-35 years ago function keys where cool. I cant remember the…

How do you rename files?

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

#39

Post by eviks »

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…

But all of Chrome doesn't take 6 seconds to start

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

#40

Post by kristiandupont »

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.

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.
Post reply on HN