Live data from Hacker News

Analyzing the Performance of WebAssembly vs. Native Code

arxiv.org

51–60 of 179 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#51
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

> Add to home screen is a good example

You mean the thing that's been there since iPhoneOS 2.1? (https://appleinsider.com/articles/08/10/03/latest_iphone_sof...)

Or are you just whining about other implementors not adopting Chrome's proprietary crap wholesale?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#52
post #47
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.

The banner is relevant to those users who haven't figured out that they can do that.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#53
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…

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

Still won't be a panacea for the Chromium runtime.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#54
post #27
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?

Are you talking about textarea and input being high latency?

Re: Analyzing the Performance of WebAssembly vs. Native Code

#55
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

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

Re: Analyzing the Performance of WebAssembly vs. Native Code

#56
post #2

Seems like the tl;dr is that v8 and spidermonkey need to work on adding more optimization tiers to their wasm piplines

Most performance spec for WASM are not even finished (SIMD, Thread, ...). Doing a benchmark will be interesting when at least SIMD as been properly finished and implemented.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#57
post #55

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?

I have 3. But I guess that doesn't say much.

Websites can show a 'add to homescreen' button.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#58
post #47
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.

> Since the very start.

Technically not quite the very start (but it was added in iPhoneOS 2.1 so close enough).

Re: Analyzing the Performance of WebAssembly vs. Native Code

#59
post #56
post #2

Seems like the tl;dr is that v8 and spidermonkey need to work on adding more optimization tiers to their wasm piplines

Most performance spec for WASM are not even finished (SIMD, Thread, ...). Doing a benchmark will be interesting when at least SIMD as been properly finished and implemented.

[deleted]

Re: Analyzing the Performance of WebAssembly vs. Native Code

#60
post #37

Earlier quoted context omitted.

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.

I'm with you. The potential for websites to add themselves is far too dangerous; the web being open, wild, and dangerous, adding a website to the home screen should only ever be a browser-based task. And no, asking the user for confirmation is never sufficient to stop unsuspecting people from accidentally causing their own compromise. It's a trust thing. Once they trust one dialogue from a legit website, they'll trus…

As far as I’m aware this Add to Home Screen API you’re describing controlled by the website doesn’t exist, adding a PWA is a process controlled by the browser which occurs according to its heuristics, on Chrome it’s something to do with repeated visits to the same site. The only control the website has is a manifest, which sets the icon, loading screen colour, and whether the website can run without browser chrome.

Edit: It looks like Chrome may have changed this, what I’m referring to above was the initial implementation. I think it’s a reasonable objection to say this should be under the control of the browser. But Safari could just implement the former without the latter.

My main gripes with Safari at least with my use of webapps is that it doesn’t allow users to install PWA’s without the browser chrome, and its implementation of service workers is subtlely broken. Those are the biggest usability issues.

If a user goes out of their way to go to the share menu, scroll along and click ‘add to homescreen’ why not allow them to specify to use what is clearly an app-like link without browser chrome? And why implement Service Workers but not according to the standard?

Post reply on HN