I have just finished a mobile app in HTML5. Although it works fine on iOS and Android 4.x, it caused many problems on Android 2.x. As Android 2.x still has more than 50% of Android market share it is a platform we cannot ignore. I am sticking to native development for now.
Making Facebook's native mobile app faster using HTML5
81–90 of 166 posts
Re: Making Facebook's native mobile app faster using HTML5
#82Why do we see plenty of articles saying that HTML5 can be as good or better than native code and no actual applications doing it? Facebook and Google tried and miserably failed, LinkedIn and Twitter are probably the ones closest to actually doing it, but users still prefer the native version, why? One I think is a big reason is clearly visible in the video: scrolling physics are different. It's annoying and feels wro…
>> One I think is a big reason is clearly visible in the video: scrolling physics are different.
From the article:
"In the native app, scrolling doesn't stop for about 3s. We decided to increase friction and reduce the animation duration to 1.4s. This not only makes content ready to read faster, it also provides extra idle time for the app to buffer more items while the user is still reading existing content."
Re: Making Facebook's native mobile app faster using HTML5
#83To me the most impressive thing is that Sencha Touch can run at any reasonable performance level. Has anyone used the framework? iirc there's >1mb debug JS, randomly-generated element IDs, a mess in general. The thing would hang my chrome for a couple moments just to parse the js. Obviously this is solved with minification/dynamic script loading, but Sencha's kitchen-sink approach really doesn't seem to help much in…
You're supposed to use the build tools to generate a file with only the subset you need for your project.
By the way, the download time for the native app is also non-zero. With appcache you pay the framework's download cost only once. Admittedly it still needs parsing to load, but i haven't had this seconds-long parsing experience myself in my sencha touch app.
Re: Making Facebook's native mobile app faster using HTML5
#84Earlier quoted context omitted.
Why so angry? Google's current iOS apps are great, the previous releases, the ones with heavy HTML use, were definitely not. I don't think they would be shocked by this, a guess supported by the fact that they have new, completely different ones. It's wrong for Sencha to force the bounce where it doesn't belong, but that's not what I was referring to and the physics are wrong on iOS too.
I'm not angry, you're just confused. >Google's current iOS apps are great, the previous releases, the ones with heavy HTML use, were definitely not I'd check again (they're still largely html5). >but that's not what I was referring to and the physics are wrong on iOS too. Right, but that's because they're completely hijacking the scroll behavior to be able to do the "fancy" inertial and bounce scrolling...
>I'd check again (they're still largely html5).
I like how you two make claims with no data to back them up. You both don't know how "native" or how "html5" the app is.
Re: Making Facebook's native mobile app faster using HTML5
#85Earlier quoted context omitted.
Everyone hated it. There's a tech community confirmation bias at work here. I can't see what the ratings were like before the most recent version, but Gmail has a 3.5/5 rating on the App Store right now. I suspect that a lot of "ignorant" non-tech users found it to be fine.
The ratings were particularly low before it went native. I know because I have a Gmail account in Mail.app and didn't use it because of this. It's one thing not to listen to MG Siegler complain. It's another to excuse everyone else who complains on the App Store. They may not know the reason but they know the effect.
Ratings are far from a scientific way of deducing an app's value.
Re: Making Facebook's native mobile app faster using HTML5
#86I ran the HTML5 app on my iTouch 4G running iOS 6 (roughly equivalent to iPhone 3GS) and compared it to the native FB app. The HTML5 app had noticeable lag in the swipe transitions. It also crashed once when loading a photo (only once though). Not to mention that they implement almost everything differently and leave out 90% of FB's features. That being said, it was really smooth on my iTouch 5G. The demo HTML5 app a…
Even when browsers are powerfull enough the mess what is trying to shoehorn technologies created for hyperlinked text into apps development will still be a mess. It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks. As for the appeal "run everythere"—that's just some more quirks. Good luck with th…
>trying to shoehorn technologies created for hyperlinked text
Genetic fallacy. For 75% of its development, HTML has been taregeted at greater things than hyperlinked text.
>It may appeal for those who know only the said technologies, but frankly, they would be better of by just learning the native instead of spending time traying to fight quirks.
I would say the opposite is true. Native doesn't protect you from quirks. On the contrary, it makes them worse. If you use HTML5, you're (eventually) dealing with standards that you can rely on so that you know your app will still work years down the road. Point your modern browser at the website for the movie Space Jam, and it works exactly the same today as it did in 1996.
But with native frameworks, you have no such security as a developer. The "standard" is defined as "whatever the documentation currently says". Apple or Google released a new OS version, and now your native app doesn't work? They phased out a feature without deprecating it first? Sorry, that's not a bug. Your software is outdated, and you need to fix it yourself.
And that's to say nothing of the power that you lose when you write native apps in today's world of walled garden app stores. Did Apple decide that your app "contains duplicate functionality" or "is very blue, and I don't like blue today"? Well I guess you could always sell your app on ... oh that's right, there's no viable way to sell your iOS app outside of the App Store, and it won't run on any other platform.
Re: Making Facebook's native mobile app faster using HTML5
#87Earlier quoted context omitted.
I'm not angry, you're just confused. >Google's current iOS apps are great, the previous releases, the ones with heavy HTML use, were definitely not I'd check again (they're still largely html5). >but that's not what I was referring to and the physics are wrong on iOS too. Right, but that's because they're completely hijacking the scroll behavior to be able to do the "fancy" inertial and bounce scrolling...
>I'd check again (they're still largely html5). I like how you two make claims with no data to back them up. You both don't know how "native" or how "html5" the app is.
Haha. Jesus this whole thread was a disaster I should've stayed away from. It's a bunch of people who don't know what they're talking about spewing years old tropes about HTML that aren't even true.
Gmail, Google+ are both HTML wrappers on iOS. I'm not sure what to tell you, those are well known facts, easily confirmed with half an ounce of Googling.
Re: Making Facebook's native mobile app faster using HTML5
#88Why do we see plenty of articles saying that HTML5 can be as good or better than native code and no actual applications doing it? Facebook and Google tried and miserably failed, LinkedIn and Twitter are probably the ones closest to actually doing it, but users still prefer the native version, why? One I think is a big reason is clearly visible in the video: scrolling physics are different. It's annoying and feels wro…
We've yet to see a web app that meets or exceeds the experience offered by native desktop apps.
Natively built apps are almost always "better" because they're closer to the OS and implement the native UI conventions. At the same time, web apps are almost always cheaper, because you don't have to develop for each platform from scratch (or suffer a lowest common denominator experience by using a cross-platform non-web dev framework.)
Mobile has the same dynamic. Mobile web apps can get away with being worse, as long as they are "good enough" and available on all platforms. The app store's ease-of-shipping bonus has delayed this, but the shift to mobile web apps is pretty much inevitable because of the cost of development and the ease of deployment.
Re: Making Facebook's native mobile app faster using HTML5
#89Looks and functions terribly in Internet Explorer 10 on Windows Phone 8 unfortunately.
Sencha's wp8 support is in beta, it doesn't ship until next year.
Re: Making Facebook's native mobile app faster using HTML5
#90Earlier quoted context omitted.
I'm not sure I understand the connection to data caps. HTML5 allows you to cache apps and data locally, and wrappers like Trigger.io and Phonegap allow you to run an HTML5 app completely on the client without any reliance on data from an outside network.
> HTML5 allows you to cache apps and data locally In theory, yes. In practice: after all that shamanic dance trying to get all this to work you will wonder, what's the point. Native is just much much simpler to develop and more performant to run. Yes, you loose the cross-platorm appeal, but which will appeal more to your potential user: an app crafted to run on a few platforms (and therefore alien on all of them), or…
Building a well-made hybrid app requires a lot more work than developing an equally performant pure native app, I agree (assuming your standards for 'well-made' are sufficiently high; a vanilla PhoneGap app doesn't quite cut it).
There's a trade-off, though: a hybrid app is a lot more work, but in return you generally get much shorter dev times when creating new content. It's not always the right design decision to make, but there are use cases where it's worth the investment.