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

81–90 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#81

Post by ourmandave »

zapzupnz wrote: post #40
baroffoos wrote: post #18

Earlier quoted context omitted.

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 t…

tl;dr; Running an app monopoly is expensive.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#82

Post by vorticalbox »

osrec wrote: post #63
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

I don't think that's right. Apple are consistently late to the party as far as Safari goes. I mean, they don't even support web push notifications yet, while other browsers have been supporting them for years. It's down right annoying.

can iPhone play webms yet?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#83

Post by zurn »

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

Worthwhileness would depend on your motivation for doing it.

I guess a very tiny microcontroller could be a use case, where it's a good tradeoff to save some memory (=cost) by eliding the JIT even if execution is slow. Even then you could just replace this with offine binary translation.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#84

Post by mgamache »

WASM will be the default for any non-trivial web apps in the next few years (assuming the DOM access gets addressed). Why would you ship JavaScript of the internet to then get compiled locally? I know there's arguments for JIT, but I don't think they make sense for JavaScript. Also devs hate JavaScript! Okay, I know we don't all hate it and I know it's popular, but really why does TypeScript exist? It's just a rational way to produce JS that hides the silly nature of JS. Now you don't need JS (or TypeScript) choose the language that works best.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#85

Post by osrec »

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

I think it's laughable that you differentiate between the notifications of an app vs the notifications from a web app. Both are opt-in, with web apps being even more explicit about the opt-in process, in my opinion. Also, once you disallow notifications, the web app will not be able to request permissions again. Why do you feel this is problematic?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#86

Post by heavenlyblue »

AsyncAwait wrote: post #80
johneth wrote: post #73

Earlier quoted context omitted.

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

I'd say there's a difference between a 'web site' and a 'web app'. If there's a web app for which you'd allow notifications if it was a native app, why wouldn't you do so for the web app?

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.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#87

Post by Octoth0rpe »

untog wrote: post #14
forrestthewoods wrote: post #9

Earlier quoted context omitted.

> can't even show a add to home screen native banner. That sounds like a feature.

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.

My biggest objection to PWAs is that a significant part of the value of the app store is the constant scanning for various kinds of malware. I'm not sure that there's a way around that, and that makes the various app stores infinitely better in my book.

That's all assuming you trust the efficacy of the app store scanners of course, and my trust in google on that is pretty low.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#88

Post by wlesieutre »

moreira wrote: post #47
Jedi72 wrote: post #43

Earlier quoted context omitted.

What?? This makes no sense.

It's just about showing a banner to add to home screen, and the person is not wrong — there is no technical necessity for it. There is already, and always has been, an "Add to home screen" button in Safari. Since the very start. Having said that, if PWA support in iOS moves forward I wouldn't be surprised if that API is added to iOS, since then it'd be part of a bigger-picture thing.

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 instead of being fixed to the top of your screen. If a native feature can keep people from making a shittier version and sticking it all over, then I vote yes.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#89

Post by StavrosK »

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

It doesn't matter. What matters is that web apps aren't on parity with mobile apps, which was the point here.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#90

Post by greiskul »

zapzupnz wrote: post #40
baroffoos wrote: post #18

Earlier quoted context omitted.

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 t…

You know that in Android, if you as a developer use in app purchases, you have to pay a cut to the play store, right? But the thing is, you can also do payments on your own (although users are much less likely to trust you), in which case there is no cut. This is why I can buy a book in Kindle on my android phone, but no on my dad's ipod.

That's what people are asking for. If you want to provide services, sure, charge for them, but also allow developers to not use your services in this case.

Apples monopoly enforcement in both this and in html rendering is one of the biggest causes of stagnation in tech right now.

When I run a web app, sure, I need to pay lots of different middle men. But I get to choose which ones I use.

Post reply on HN