Hacker News Reader

Comment by samps | Hacker News Reader

This article suggests that the new iteration of the Facebook app for iOS is written mainly with Web technologies and the fronted runs in a WebView, which explains why it sucks so much more than the previous version. Has anyone else noticed lots of really sluggish content loading, occasional hangs, mysteriously empty panes, etc? While the app is polished enough to seem native (kinda), it seems to be an argument that Web technologies are not yet ready to be an alternative to native UIKit development -- on iOS, at least.

View on HN

Yep. I've spent some time investigating the possibility of using web views to replace some native Android/iPhone views (e.g. ListViews), and I assure you it's not easy. We didn't do anywhere near as much stuff as Facebook did (of I read that right, they bundle a version of WebKit with their app, and write client side compilers from JavaScript to native languages for phones with bad or no JavaScript environments). It's getting there, but web still hasn't quite arrived as the write once run everywhere platform. At least it's somewhat reassuring that Facebook still has lots of problems after spending many more hours on the mobile web than I have.

What really intrigues me is that average users feel the same way; it's not just us. Read the iPhone app reviews (current average: 2.0 stars). Ouch!

Facebook should hire back Joe Hewitt. His native app was fast and powerful, at the very least. Is employing one talented full-time iOS developer really too much to ask from a company as big as Facebook?

Is employing one talented full-time iOS developer really too much to ask from a company as big as Facebook?

You might as well add the Python SDK to that. The "we don't have the resources" claim rings a little hollow, in that the company probably very likely has the resources, but thinks such things are strategically unimportant.

You may not have the experience of supporting a large web service, but I do. Believe me, supporting native apps for multiple platforms is not only a multimillion dollar money pit, but an integration nightmare. You end up building a web interface anyways then hacking together a ui in native code for every platform. The long term support structure can very quickly (exponentially) get out of hand.

I don't personally, but the people I work beside do, and it doesn't seem from talking and working with them that it's as bad as you suggest, no where close. Having launched successful apps on multiple platforms for a website, I've seen it done successfully.

Website =/= web service

Large saas, social media, and rich media delivery services have many times more complex factors than a simple content site. Why do you think Netflix, Facebook, many major banks and loan servicing institutions and most financial portals have chosen the web app strategy. It's not just because they are idiots and don't get it, it's that theyve recognized the unsupportable nature of multiple mobile platforms with such limited penetration.

Was referring to a "web site" akin to Facebook. A social network. Not merely a "content site." So, that point is moot.

> It's not just because they are idiots and don't get it

Didn't suggest otherwise. But your reasoning is flawed, I'd imagine. Your suggesting that they don't go native because smaller platforms have limited penetration? If so, that seems silly. Why not support the platforms with large penetration natively, and support the platforms with smaller penetration with a web app?

I'm not suggesting going native for every platform, but going native for none because you can't do them all is even more silly.

I was referring to the actual penetration of mobile users vs desktop browser users -- which is often on the order of 5% or less. This makes it a very expensive investment for such a minority of users.

Besides that still leaves you with Android and/or iOS plus web -- two to three times the development costs. This becomes very hard to justify for such a small percentage of total product users.

"Read the iPhone app reviews..."

I went ahead and looked, and none of the complaints appeared obviously due to anything related to the current discussion.

The vast majority of them complain about "crashes" and problems logging in. The few complaints about it being "slow" appeared to be due to network issues, specifically related to getting new content from facebook. A handful report that content was attributed to the wrong user. Most of the remainder were just unsubstantial complaints. In the cases are something is actually mentioned, they are mostly about the lack of random features.

I've gone through many pages of comments on the app store reviews and I see no complaints that can be obviously attributed to the technology decisions discussed in the article.

Ratings reset every release, and this new release is only 10 days old, so I wouldn't read too much into that.

Also, I read the first few pages of reviews, and if those are your users, good luck to you app developer!

Not only that but it doesn't really sound that much easier. By the time you've pasted all this stuff together, custom JS scrolling lib etc and all, how much work are you really saving yourself?

But once they have set that up (which they have), they can build a feature once and deploy it on every mobile platform supported, iterate and fix things quickly without distribution delays (like 30-50% is on iOS?). It's not for everyone, and I don't like the Facebook iPhone app and I don't take this approach generally, but it works for Facebook because it works for most end-users.

Yes. And I think the cause of the problem is that the environment is running in a WebView + lots of JS floating inside the view.

Actually, while I'm still the first to say that web technologies are not ideal for apps UIs, the latest iteration (the one with the timeline) is working better than previous ones for me. Images or comments not loading or loading the wrong content are gone now.

Reply on news.ycombinator.com