Live data from Hacker News

Analyzing the Performance of WebAssembly vs. Native Code

arxiv.org

31–40 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#31
post #14

Earlier quoted context omitted.

Not really. Progressive Web Apps are a much better model for users than the App Store because they get to use the app immediately then decide later whether they want to keep it on their home screen or not. We've all become very used to the App Store but honestly the experience is pretty crappy.

Web apps are inherently mediocre on every platform. There’s enough advantage from being accessible via URL, usable on any device, live updating, etc. to compensate that for many uses. But using web apps daily for any serious work is a huge loss in resource use, usability, polish, ... The one that makes me saddest though is that web apps seem to be getting worse over time. For example most of Google’s suite of web app…

On the web the apps are barely usable for the users because the users are acceptable bystanders, not clients. The clients are data hoarders, advertisers, and trackers. In fact a tuned web app focusing on user experience and performance, with the current state of ES, DOM, HTML5, CSS3, and general performance of web browsers would be mindblowing.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#32
post #17

Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666

They won't add functionality that would compete with the app store.

Add to home screen is a good example

Re: Analyzing the Performance of WebAssembly vs. Native Code

#33
post #17

Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666

Safari imo is the worst offending browser when it comes to bugs/not implementing standards.

It's the new IE, I'm constantly implementing workarounds for Safari.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#34
post #3

I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web tec…

What's the point of using this for native applications ?

I mean yeah, it might be a little easier to distribute but it's kind of absurd to agree to throw away 20% performance for a bit of convenience and then sched tears on how the latest intel chips only delivered 5% improvement over the previous ones.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#35
post #34
post #3

I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web tec…

What's the point of using this for native applications ? I mean yeah, it might be a little easier to distribute but it's kind of absurd to agree to throw away 20% performance for a bit of convenience and then sched tears on how the latest intel chips only delivered 5% improvement over the previous ones.

you don't have to deal with the distribution issues related to the app store, you can easily roll out changes quickly, you can create "shareable applications" (URLs!) quite easily.

You can also build hybrid apps, where you can take advantage of web tech for certain presentational stuff and still go fast for stuff in the backend

Re: Analyzing the Performance of WebAssembly vs. Native Code

#36
post #34
post #3

I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web tec…

What's the point of using this for native applications ? I mean yeah, it might be a little easier to distribute but it's kind of absurd to agree to throw away 20% performance for a bit of convenience and then sched tears on how the latest intel chips only delivered 5% improvement over the previous ones.

20% performance or, as I like to say, 20% battery life.

Anyways, there are good uses for WASM even outside browser. Plugins and when you have multiple architectures you need to deal with.

Sandboxing and deterministic memory consumption is a great fit in certain applications. I'd like to use WASM on relatively small embedded devices (even as small as 64 - 256 kB RAM), to provide extendibility, for example.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#37
post #17

Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666

They won't add functionality that would compete with the app store. Add to home screen is a good example

I think that "add to home screen" is a stupid browser API, serving no genuine technical necessity. Feature creep of browsers must be forcefully stopped.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#38
post #34
post #3

I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web tec…

What's the point of using this for native applications ? I mean yeah, it might be a little easier to distribute but it's kind of absurd to agree to throw away 20% performance for a bit of convenience and then sched tears on how the latest intel chips only delivered 5% improvement over the previous ones.

By the same token, writing native apps in anything other than C++ is a waste of performance, sometimes much more significantly so... but we still do it.

Performance just doesn't matter all that much in so many cases.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#39
I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#40
post #14

Earlier quoted context omitted.

Not really. Progressive Web Apps are a much better model for users than the App Store because they get to use the app immediately then decide later whether they want to keep it on their home screen or not. We've all become very used to the App Store but honestly the experience is pretty crappy.

Its not about whats a better experience for the user its about what gives apple more money and control. Apple gets to pick which apps make it on to the app store and they take a huge cut of all sales on apps.

I really get annoyed when I see people talking about the "huge cut of all sales on apps" in isolation, as though hosting high-traffic downloads, handling financial transactions (purchases, in-app purchases, subscriptions, credit card handling, fraud investigation, etc.), and occasional spots of marketing and publicity when an app does particularly well or is featured in the Stories cost nothing.

It's not like these things are cheap, and plenty of developers wouldn't have a shot of successfully delivering an app without the infrastructure in place to support them.

It should come as a surprise to absolutely nobody that the vendor wants their cut.

If we are having an honest conversation about who gets a cut of what, we have to realise that web apps still have bills to pay and people getting their cut of something — credit card handlers, payments systems, web hosting (and that ain't cheap, especially when demand rises) on top of the cost of hosting an API and databases, and plenty of other costs.

Post reply on HN