5 ms·

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 (th

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?

cmelbye 14y ago
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.
- myko 14y ago
  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&hl=en 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).
0x0 14y ago
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".
marknutter 14y ago
Nitro is disabled in UIWebviews due to security concerns.
idspispopd 14y ago
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.
- freshfunk 14y ago
  Proof? Is it slower simply because they have to deliver more information (rendered UI in the form of html as opposed to json)?

cmelbye 14y ago

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.

myko 14y ago
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&hl=en 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).

0x0 14y ago

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

marknutter 14y ago

Nitro is disabled in UIWebviews due to security concerns.

idspispopd 14y ago

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.

freshfunk 14y ago
Proof? Is it slower simply because they have to deliver more information (rendered UI in the form of html as opposed to json)?