can someone tell me why HTML view apps are that slow on iPhone? I thought with all the money and time that has gone into the development of Webkit and Nitro (the JS engine?) we would be up to the speed of native now. Is this a rendering issue or just lack of bandwidth?
I've heard from Android users that their app (which uses the same techniques) is quite bad as well. A lot of my friends just use the mobile site through their Android phone's web browser.
Yes it's just as bad on my iPhone 4 as it is on my GNex. On Android I typically use a 3rd party client like Flipster (https://play.google.com/store/apps/details?id=com.flipster&#...). I think it's available for iOS as well but I haven't tried it on there (typically only used for development).
Well, for one, when you're embedding UIWebViews in your own app, the JS engine disables JITting to native code.
Apple will not sign and grant 3rd party apps write+execute memory permissions, making it impossible to build a JITter. So only "MobileSafari.app" get "native javascript performance".
Other than JS performance being downgraded when the app is built this way. It appears that the actual facebook servers that serve the customised content are also slower (read: much slower.)
The speed experienced can't be attributed to JS alone, there simply isn't enough JS being processed when many of the 'slow' encounters are being felt, additionally the speed fluctuates through the day/week which would be consistent with server load rather than a small JS not loading and running quickly enough.
But a lot of it was the fact their HTML5 views were not well cached, used XML and a mix of other formats for data interchange, and in fact were generally poorly made.
In short: their caching blows giant monkey balls. It regularly loses the like icon, or even the stylesheet entirely. But still manages to cache the wrong profile icon for the wrong person.
As primarily a web developer, it saddens me how much truth there is to this statement from the article:
The current version of the app is essentially an Objective-C shell with a Web browser inside. When it comes to speed, this is like putting the engine of a Smart Car in the body of a Ferrari.
11 comments
[ 2.8 ms ] story [ 23.8 ms ] threadApple will not sign and grant 3rd party apps write+execute memory permissions, making it impossible to build a JITter. So only "MobileSafari.app" get "native javascript performance".
The speed experienced can't be attributed to JS alone, there simply isn't enough JS being processed when many of the 'slow' encounters are being felt, additionally the speed fluctuates through the day/week which would be consistent with server load rather than a small JS not loading and running quickly enough.
But a lot of it was the fact their HTML5 views were not well cached, used XML and a mix of other formats for data interchange, and in fact were generally poorly made.
The current version of the app is essentially an Objective-C shell with a Web browser inside. When it comes to speed, this is like putting the engine of a Smart Car in the body of a Ferrari.