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

Analyzing the Performance of WebAssembly vs. Native Code

arxiv.org

Post reply on HN
Print view View original

101–110 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#101

Post by NicoJuicy »

philo23 wrote: post #99
AJRF wrote: post #69

Earlier quoted context omitted.

You have been able to add to home screen since 11.3 iOS 12.2's main updates are with regards to state management and authentication flows for PWA's. https://hub.packtpub.com/apple-releases-ios-12-2-beta-1-for-...

It's been available much longer than 11.3, was this a typo for 1.1.3 when it was actually added?

No, PWA add to homescreen is since 11.3

https://dockyard.com/blog/2017/09/27/encouraging-pwa-install...

They do even auto-delete the PWA-apps

[Quote]

If the user doesn’t use the app for a few weeks, iOS will free up the app’s files. The icon will still be there on the home screen, and when accessed the app will be downloaded again.

Not very trustworthy for using a PWA on iOS it seems :)

Re: Analyzing the Performance of WebAssembly vs. Native Code

#102

Post by [deleted] »

int_19h wrote: post #38
obl wrote: post #34

Earlier quoted context omitted.

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.

[deleted]

Re: Analyzing the Performance of WebAssembly vs. Native Code

#103

Post by NicoJuicy »

crabl wrote: 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

If the user doesn’t use the app for a few weeks, iOS will free up the app’s files. The icon will still be there on the home screen, and when accessed the app will be downloaded again

So much for PWA's on iOS... Apple's willingness to embrace web technologies is a joke.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#104

Post by solarkraft »

johneth wrote: post #73
osrec wrote: post #68

Earlier quoted context omitted.

So that you can notify users even when they've closed their browser, like you would with a native app.

The last thing I want is for websites to send me notifications (or rather, endlessly nag me to enable notifications, as I'd never grant permission).

Okay. That's a different concern.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#105

Post by kevingadd »

shrimpx wrote: post #27
pier25 wrote: 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…

Honest question: does webassembly do anything about speeding up the Dom API? For example low-latency text input is non-existent in any browser engine today (short of rendering text using webgl). Does wasm do anything about this?

It makes it worse. Eventually it might make it slightly better via strong typing and reduced GC. Latency is largely a deficiency in the design of browsers (multiprocess rasterization, gc blocking the event loop, etc)

Re: Analyzing the Performance of WebAssembly vs. Native Code

#106

Post by solarkraft »

hpen wrote: post #55
NicoJuicy wrote: post #32

Earlier quoted context omitted.

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

Serious question: Do non iOS users actually add PWAs to there home screen?

Yeah. I made a few low-tech iot control panels this way.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#107

Post by shaklee3 »

johneth wrote: post #73
osrec wrote: post #68

Earlier quoted context omitted.

So that you can notify users even when they've closed their browser, like you would with a native app.

The last thing I want is for websites to send me notifications (or rather, endlessly nag me to enable notifications, as I'd never grant permission).

Just because you don't like something doesn't mean it's not useful to other people. Case in point: my mom and a lot of her friends don't know how to use smartphones, or don't have one at all. But they like to stay connected with people on Facebook. The problem is, they hardly ever go to Facebook specifically, so the chrome notifications are very useful for them.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#108

Post by heavenlyblue »

AsyncAwait wrote: post #93
heavenlyblue wrote: post #86

Earlier quoted context omitted.

Because every single website I visit today on my desktop shows me a popup asking me to enable their desktop notifications. Nah, useless functionality. I've got feedly if I'd like to keep track of their news. That being said I work in ad arbitrage, so I understand the presumed efficiency of these notifications. As they say our business is middle-aged Americans who can't use the Internet.

> Because every single website I visit today on my desktop shows me a popup asking me to enable their desktop notifications. I know what you mean, but that's usually traditional news sites and the like. Having the Spotify web app notify you of the currently playing song or a remainder app reminding you of an appointment is of course a different case, Hence the "web site" vs "web app" distinction I made.

I don’t know: frankly I find them incredibly annoying (that includes Spotify, email and the likes).

But besides the point: imo the semantics of these notifications severely differ between applications. Moreover, the usefullness of them heavily depends on the ability for someone to integrate them in the whole ecosystem.

Thus notifications from news websites fit right in: they don’t need a snooze button as it in for OS X Calendar app. But they are the least useful.

So we are back to square one: if you allow notifications, then what kind of? Do you allow any HTML payloads or only some?

That being said my reply is re. subj.: I understand why Apple doesn’t like them. Because they are generally useful only for a small amount of use-cases, 99% of which is spam. And an average user is going to blame Apple for allowing him to accept them in the first place.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#109

Post by ilikehurdles »

NicoJuicy wrote: post #101
philo23 wrote: post #99

Earlier quoted context omitted.

It's been available much longer than 11.3, was this a typo for 1.1.3 when it was actually added?

No, PWA add to homescreen is since 11.3 https://dockyard.com/blog/2017/09/27/encouraging-pwa-install... They do even auto-delete the PWA-apps [Quote] If the user doesn’t use the app for a few weeks, iOS will free up the app’s files. The icon will still be there on the home screen, and when accessed the app will be downloaded again. Not very trustworthy for using a PWA on iOS it seems :)

This applies to all apps, not just PWAs, and can be enabled/disabled. I don’t know what you’re quoting as it doesn’t appear in the link (apologies if it does, perhaps my ctrl+f is malfunctioning), so I don’t know if your source is claiming otherwise.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#110

Post by wlesieutre »

moreira wrote: post #94
wlesieutre wrote: post #88

Earlier quoted context omitted.

There's an add to home screen button, but it's buried deep in the share sheet and the average user doesn't know about it. We already have a "X company has an app" banner API on iOS, it seems fitting that webapps have an option to match. And the Safari provided "X company has an app" banner is a lot less annoying than any third party "HEY WHY AREN'T YOU USING OUR APP" banners in that it goes away when you scroll down…

Your example, though, directly contradicts the point you're trying to make. Apple does have a native feature for showing when there's a native app available, and -yet- we see those third-party banners. Having the native API to do something doesn't make the third-party crap banners go away.

Yes, not every site wants it to be unobtrusive, they view the nagging as a feature. But for sites that aren't assholes I think they should have a standardized option like the app store's smart banners.

I guess the real question is "If we didn't have smart banners, would even more websites use obnoxious full screen popovers and fixed position headers that pop back up every time you visit the page?" I think the answer is yes, fixed position headers are a really easy/lazy thing to tack onto a webpage, and not bothering to persist the fact that you already closed it 10 times is easier than saving that preference and checking it.

If you want people to consider doing it the nicer way you have to make it just as easy.

Post reply on HN