Live data from Hacker News

Making Facebook's native mobile app faster using HTML5

sencha.com

41–50 of 166 posts

Re: Making Facebook's native mobile app faster using HTML5

#41

Earlier quoted context omitted.

I think it's a mix of FUD and reality. It's true that for most older devices HTML5 apps just don't perform very well, but they are slowly disappearing from the market. Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them.

>Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them. Maybe I'm mistaken but Google released an official Gmail app on iOS that was basically HTML. Everyone hated it. The same goes for the situation with GMaps. Virtually n…

I've never actually been able to get a confirmation one way or the other oh which of Google's native apps are "hybrid" apps and just how much of those apps is done in HTML5. The previous version of their gmail app seemed to employ a lot of HTML5 because you could see the main inbox list re-render occasionally. That app performed perfectly well for me. Unless we hear from Google officially about the new app we'll never know. It could be that it's full native, or it could be that they've perfected the HTML5 code to make it feel completely native. Who knows.

Re: Making Facebook's native mobile app faster using HTML5

#42

Earlier quoted context omitted.

You're forgetting one small point: you have to write two (or more) native apps once you go that route. Hence the reason Facebook's Android native app came out roughly 6 months after their iOS native app did.

That's true but wouldn't you (as of today) still be much more comfortable going that route with a non-trivial project? Less time spent on the cutting edge battling the idiosyncrasies of the platform and more time building your app.

It depends on the resources available. If I were a CEO and the company was flush with cash, I'd just brute force it by hiring native developers across all platforms or farm it out to specialized native dev shops. If was a CEO of a smaller company tight on cash with a bunch of web developers, however, I'd go the HTML5 or hybrid route because it'd be the best utilization of my company's time and resources. This isn't a black and white issue.

Re: Making Facebook's native mobile app faster using HTML5

#43

HTML5 is cool and you can do a lot with it, but it has some very real drawbacks - like Android. Also, if you are doing a bunch of optimizations to make it fast on HTML5, then you're basically doing the same work as writing a native app, so what are you gaining by doing a HTML5? Seriously, at some point you can get a better user experience, have better access to native API's and can really leverage the full abilities…

But this argument makes no sense. When you go native, you have to write N number of apps for N number of platforms you want to support. The point is that making a great mobile app is hard no matter what stack you choose to use. It's also a bit disingenuous to say you are forced to optimize every HTML5 app. The whole point of Sencha's blog post is to advertise the fact that they've abstracted away all those optimizati…

Maybe people that make this argument only care about supporting one (or two) platforms.

Re: Making Facebook's native mobile app faster using HTML5

#44
post #10

Why 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…

I believe the scrolling physics can be updated. In the Bonus Points section they mention:

> Also, you may notice a difference in the scrolling deceleration time between the native iOS app and Fastbook. 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

#45
I'd like to clarify one thing. The "native" Android app that was tested, isn't actually native. Native newsfeed shipped in Facebook for Android 2.0, but 1.9.2 was used in the comparison. Thus, the comparison was between two html5 implementations of newsfeed. That said, I'd love to see a side by side video with Facebook for Android 2.0.

Re: Making Facebook's native mobile app faster using HTML5

#46

I 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 that. I am very experienced web developer and probably know html, css, js and all that jazz better than I do know Objective-C and Cocoa Touch, but building mobile apps with web technologies is the last thing I want to do.

Re: Making Facebook's native mobile app faster using HTML5

#47

Earlier quoted context omitted.

>The future is bright for HTML5 apps, clearly. There will come a time when everyone's phone is fast enough to run apps like the FB clone Sencha made and the need for native apps will start to diminish. I believe you're wrong. The question isn't whether HTML can keep up with what exists today but what is offered in the future natively. We are already living in a world with data caps and it will be so for the foreseeab…

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 an app crafted with a specific platform in mind? Not many predict that desktop apps will be replaced by web apps soon, but for some reason this a popular view regarding mobile. But it is backwards: on desktop you have much more room to manoeuvre.

I think it is more likely we will see the web going a bit back to its roots with a more pronounced cloud-web gaining prominence, basically backend servers talking to apps (and browsers) API calls and JSON exchange.

Re: Making Facebook's native mobile app faster using HTML5

#48

Earlier quoted context omitted.

>Google hasn't "miserably" failed, they use the same basic strategy that LinkedIn does; namely, a they make hybrid mobile apps where they mix both native and HTML5 components to get the best performance and flexibility. It's worked quite well for them. Maybe I'm mistaken but Google released an official Gmail app on iOS that was basically HTML. Everyone hated it. The same goes for the situation with GMaps. Virtually n…

I've never actually been able to get a confirmation one way or the other oh which of Google's native apps are "hybrid" apps and just how much of those apps is done in HTML5. The previous version of their gmail app seemed to employ a lot of HTML5 because you could see the main inbox list re-render occasionally. That app performed perfectly well for me. Unless we hear from Google officially about the new app we'll neve…

I assume the current Gmail is mostly written in native code because it is faster and there are elements in it that don't exist on the web site.

The original was just a wrapper for the web site which had unusually high negatives from users and reviewers alike. I never used it since I read the reviews before I actually downloaded it.

Re: Making Facebook's native mobile app faster using HTML5

#49
post #37
post #27

This is cool, however, I'd say HTML5 has a bright future regarding web-based apps, or apps with a specific use case where you pull some data and display it in a list/table view etc .. HTML5 will never be as capable as native if you have many other use cases (ex: image/video processing, music recognition ) ..

"HTML5 will never be as capabable as native..." I think its very possible to imagine a world where HTML5 can be just as good as native. It comes down to two things: 1) HTML5 needs more JavaScript APIs to access hardware like camera, contacts, etc. It's is not very difficult to imagine HTML6 (if you will) supporting this in much the same way that it supports geolocation today. 2) Improved JavaScript performance. It's…

3) ditch javascript and replace it with a better language...

Re: Making Facebook's native mobile app faster using HTML5

#50
post #10

Why 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…

Because end users couldn't care less if an app is build using native sdk or web technology; is it multi-platform or not. All they care is how it works. As for developers: some only know web tech and are not willing to learn native—their loss. Some buy an idea of developing universal web-tech based app for two or three platforms will save them time. I doubt that very much. Either you get a crappy app on all platforms, or you spend more time polishing it than it would take to go native for all platforms from the very beginning.
Post reply on HN