Live data from Hacker News

Safari Vs Chrome iOS JavaScript Benchmark

pastebin.com

11–20 of 42 posts

Re: Safari Vs Chrome iOS JavaScript Benchmark

#12
While third-party browsers won't be able to compete with Safari on iOS due to the technical limitations, I still prefer Chrome on my iPhone because it ties in with my Google account, syncing everything for me. The loss in per-page performance is somewhat mitigated by the fact that I have to load fewer pages than before thanks to features such as Chrome to Mobile and syncing of tabs, bookmarks, and passwords.

Also, Chrome is so well designed for mobile as on my Galaxy Nexus that it is difficult to switch to any other browser. The way they handle tabs is the best I've seen. Incognito mode also offers an easy way to simulate a second browser session without switching to another browser app, something I as a web developer cannot live without.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#13
post #6

It looks better and feels snappier, so these tests are surprising...

It wouldn't surprise me to discover that Google's team did lots of their own performance tweaking and tuning to compensate for their disadvantage. I do love the responsiveness. Now their Gmail app on the other hand was painful for me to use.

Yeah I could never really tell how that even made it to the App Store. Some stupid wrapper around the web page, but the Chrome app is definitely more along the lines of what I'd expect from Google.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#14
post #6

It looks better and feels snappier, so these tests are surprising...

It wouldn't surprise me to discover that Google's team did lots of their own performance tweaking and tuning to compensate for their disadvantage. I do love the responsiveness. Now their Gmail app on the other hand was painful for me to use.

The latest update to the GMail app for iOS is vastly improved.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#15
post #6

It looks better and feels snappier, so these tests are surprising...

These tests are only JavaScript benchmarks and don't reflect real-world usage well. Chrome for iOS has a custom network stack and (like someone else said) page prefetching among other things.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#16
What is the point of UIWebView, if it's meant to help developers write Javascript "native" apps, and yet it's 3x slower than a web app would be inside Mobile Safari? Doesn't that kind of defeat the purpose of UIWebView existing?

I'm pretty sure Apple is leaving this as it is on purpose so Javascript apps don't start to compete on performance with ObjectiveC apps, and the security excuse they give is just the lazy one to get them off the hook, just like Microsoft is saying "WebGL poses security issues, so we won't even try to add it".

Well guess what. A lot of stuff poses security issues. But you have to balance that out with the features and usability you want to give to the user, and if there are some good and "logical" features you could add like setting other browsers as default, or letting UIWebView apps be as fast as web apps in Safari, then you just have to add them and make sure the security is as tight as possible. Add a sandbox if necessary and so on. Don't take the easy way out.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#18

While third-party browsers won't be able to compete with Safari on iOS due to the technical limitations, I still prefer Chrome on my iPhone because it ties in with my Google account, syncing everything for me. The loss in per-page performance is somewhat mitigated by the fact that I have to load fewer pages than before thanks to features such as Chrome to Mobile and syncing of tabs, bookmarks, and passwords. Also, Ch…

I am also happy to take the performance hit in stride in exchange for the sync features. The "request desktop version" feature is also nicely implemented.

Re: Safari Vs Chrome iOS JavaScript Benchmark

#19

Can someone explain how an application developer with access to webkit+Nitro could cause problems? Would the developer have to write a malicious app, or would a maliciously crafted webpage be able to exploit the OS?

If the JIT engine in Nitro had a JIT Spray vulnerability and Nitro was a shared library could it allow an attacker to inject code into other applications that also use Nitro?

Not that shared libraries are a problem, just that JIT'ing introduces a new attack vector that is hard to secure.

http://en.wikipedia.org/wiki/JIT_spraying

Post reply on HN