Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Facebook's native mobile app faster using HTML5

sencha.com

Post reply on HN
Print view View original

131–140 of 166 posts

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

#131

Post by RandallBrown »

marknutter wrote: post #23
tterrace wrote: post #22

They take offense to Zuckerburg's "HTML5 isn't quite there yet" comment but in order to keep their implementation quick they had to build a custom iframe framework in addition to their TaskQueue and AnimationQueue implementations to replicate the fb timeline. It seems like that was part of Zuck's point - why would a company with a deadline take on all that technical debt to replicate things that you essentially get f…

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.

you also need to write two (or more) web apps too. Each OS has dramatically different user interface paradigms. Sure, you can run an iOS looking app on Android or Windows Phone, but it's going to be awkward and out of place.

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

#132

Post by joshtynjala »

TeeWEE wrote: post #130

Good work. But they are cheating in one main spot: - they use a proxy to cut down data transfer Good choice, but comparing it with the orignal app is not valid anymore (its not really html5 that is making it faster) Anyway its still a very fast mobile app, and html5 is sometimes the best choice to make. Because it is very expensive to write a different app for all platforms currently. However, currently, it is also v…

> comparing it with the orignal app is not valid anymore

Facebook could have done the same thing with their app too, so I don't see how this affects validity.

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

#133

Post by macspoofing »

blub wrote: post #123
macspoofing wrote: post #118

Earlier quoted context omitted.

With HTML-native-apps you get free cross-platform support, and you get to work within a very-well supported, constantly improving and performant framework. Furthermore, if you're building a SASS-type app (e.g. where your content is primarily hosted online) then using a WebView-type component will let you instantly "upgrade" your clients and you never have to worry about old versions of your app in the wild. You bette…

Please don't listen to this person, webdev is hard and you don't get anything for free. Actually, it depends if you prefer learning from painful experience or simple advice...

Dev is hard.

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

#134

Post by untog »

macspoofing wrote: post #111
andybak wrote: post #102

Earlier quoted context omitted.

Why not?

It's a very strange comparison to me. JS is intrinsically tied to the DOM, HTML and Web technologies, the underlying VM has widely used open-source implementations (V8, WebKit, Gecko), and JavaScript is not controlled by any single company.

JS is intrinsically tied to the DOM, HTML and Web technologies

Not really. That just happens to be the most common use of it.

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

#135

Post by rakkhi »

brianchu wrote: post #11

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…

Wrote this in 2010 still seems valid:http://www.rakkhis.com/2010/10/rich-vs-thin-client-20-native...

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

#136

Post by eblade »

It started with the implementation of an Infinite List Component that handles items with unknown sizes. Only a very small set of DOM nodes is actually created to fill in the actual visible screen area. They will then be constantly recycled to render next / previous data on-demand. As a result, memory footprint is kept minimal, regardless of the amount of data in the Store. Making this work is the easy part. Making it fast with the complexity and variety of items such as News Feed stories is the real challenge. The bottleneck lies within the core processes that a browser has to perform: layout and compositing.

I wished jQuery Mobile has Infinite List Component that handles the list item recycling the last time I used it. It is the equivalent of UITableViewCell's dequeueReusableCellWithIdentifier.

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

#137

Post by millstone »

ttt_ wrote: post #93

I'll be saying this as a user. I wish most developers would turn to HTML5 today, like right now, and avoid native apps at all cost unless there is really no alternative. Why? Because I remember the browser wars and how much it was a terrible idea and the terrible experience it made for users who simply could not experience the internet from a single starting point. This time it's not simply a matter of downloading an…

You moved effortlessly from "app" to "content I want to consume," as if apps are mere passive content delivery channels. But they're not: they're tools. A well crafted tool is a pleasure to use, while a bad tool can make any task miserable.

Tools matter even for content delivery! Hulu recently migrated their PS3 app from native to something that's apparently based on web technologies, and the experience became much worse in almost every way: slower loading, laggy scrolling, more confusing interface. Hulu ships on many devices and I think they hope to share aspects of their front-end, but with their new app, watching TV became more difficult and less pleasant.

I don't believe you when you claim to not care, that you would rather live on the lowest common denominator in perpetuity than be faced with a transient zero.

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

#138

Post by millstone »

marknutter wrote: post #96
ttt_ wrote: post #93

I'll be saying this as a user. I wish most developers would turn to HTML5 today, like right now, and avoid native apps at all cost unless there is really no alternative. Why? Because I remember the browser wars and how much it was a terrible idea and the terrible experience it made for users who simply could not experience the internet from a single starting point. This time it's not simply a matter of downloading an…

Well put. The worst usability problem an app can have is simply not existing.

Is an app that you have to fight with really better than no app at all? If it didn't exist, at least you wouldn't have gotten in a fight!

There's many sites that I consciously avoid on my phone because they work so poorly that I don't even want to bother. These sites do mobile users no service by existing. An app or website has to at least meet the "user will tolerate it" bar.

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

#139

Post by u2sonderzug »

Looking at this from a different point of view maybe altogether, one of the big issues I think concerning HTML5 mobile web apps (not used in a native app wrapper to get included in the appstore) is discovery.

Where do I actually find compelling mobile web app user experience when I am trying to solve a problem in my web browser as a user when I search using a search engine?

I noticed a few years ago that Google cut out their mobile only results option - and now when you search for anything on a smart phone you get a mish mash of mobile friendly and conventional web optimised results. For a little while there Google would put a little mobile icon next to mobile optimized results - but that has gone too. I know perhaps the point of mobile is moot now - since we have a sizeable amount of tablets accessing websites too. But just in my own personal research all my friends who aren't techy say they much prefer sites that look right on their 'touch' (be it mobile or tablet). For instance, is there even such a thing as a 'mobile web app store' out there?

If consumers had an easier way of finding great mobile web apps perhaps this would grow this channel? I'd be interested in perspectives on this - maybe I'm looking at it the wrong way.

I'd also like to make the case that I think HTML5 will continue to make a very important contribution moving forward - why? Because as we get more devices, it's really starting to get silly how many apps I constantly need updated and feel like I need syncing. I think as prices come down we will find ourselves with several devices for home, out and about and at work - using the 'fat client' model of installing all these apps just gets annoying.

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

#140

Post by dotborg »

jbail wrote: post #37
level09 wrote: 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…

The idea of HTML5 is to avoid using JS in your app.
Post reply on HN