Hacker News Reader

Comment by Pewpewarrows | Hacker News Reader

As others have been pointing out feverishly on Twitter: the problem wasn't them betting too much on HTML5. Their problem was developing piece of shit apps that happened to use HTML5. They tasked amateurs who didn't know what they were doing into building a hybrid native app container which in turn embedded HTML5 content. Plenty of other developers (Instagram and LinkedIn come to mind) have figured out how to do that right, and in a way where it is seamless to the end user and for all intents and purposes feels exactly the same as a native app.

I'm not saying that it's an easy problem. You have to find the right balance between which components should be native or not. It's clear from the other problems that Facebook's been able to solve that they know how to hire top-notch developers. They just failed to do so for their mobile efforts, which just reinforces the stereotype that they don't "get" mobile.

View on HN

Yes, yes, a million times yes. Facebook is very resource intensive (in terms of data+media loading over the wire) but there are certainly ways to work around this. Yahoo mail's mobile site (at least on my iPhone 4 with ios5) is a good example of this. The main problem with HTML5 media apps today is that they must be developed with a primary focus on optimization from the start. This is unfortunate, and will hopefully change, but it is possible. But seriously, saying "HTML5 failed you" when you don't even compile your scripts and initial resources to require a minimal amount of requests is just ludicrous.

To clarify: I'm not saying that facebook's HTML5 developers can't hold their own -- they produced a great looking mobile app with a truckload of functionality (and believe me, I understand code bloat). Maybe someday it will run flawlessly on mobile. But right now to produce a nice experience in HTML5 you must optimize from the start. Run your code on the device from day 1, not in Chrome with the vertical web inspector! Host your scripts on dev servers with artificial lag. Figure out what's slowing you down on day 1 and work around it! And one day you won't have to :)

But that more or less just leads to the question: If HTML5 requires extra work to get right, isn't that what Zuckerberg was saying?

It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work that you have to put in anyways with native mobile apps, and then the lack of that work ends up biting you in the end.

One of the big promises of mobile HTML5 was that you could just take your desktop web apps, scale them down, give them new CSS, and they'd "just work". It doesn't work that way. You need to test on actual mobile devices from the start, you need to account for the lower CPU performance of them, you need to figure in higher latency over 3G connections vs. wired LANs.

You have to do all of this on native apps anyway, but you know you have to do it from the start, otherwise you can't even get your app to display, and the frameworks are built with this in mind. There're still some areas where HTML5 wins - it's easier to update the app, for one, and it's more familiar to web developers. But the developer-convenience scales were not shifted as far to the HTML5 side as people hoped they were.

I'm still not sure which technology is, on the whole, better for mobile apps. But one of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y". We aren't going to get that in a TechCrunch soundbite; there're a lot of specifics that depend upon exactly what your market is.

> One of the signs that you actually understand a problem domain is that you can give advice more specific than just "Competing technology X is better than competing technology Y".

This should be the actual soundbite, and it bears repeating.

So why bothering at this point? If I have to optimize for a given platform, I'd rather use the programming environment that gives me the best tooling.

It depends on exactly how much you end up having to optimize for each platform, and how much reuse you get between platforms.

If your app is a simple broacherware+notifications app, then HTML5 is probably the way to go.

If you can afford expert developers for every platform and mobile is critical to your success then 100% native makes sense.

There just isn't a simple answer here. To quote nostrademons:

You're comparing apples and oranges. If you optimize for a mobile browser, you can target every modern mobile platform simultaneously, and most of your work overlaps with making your app work nicely for people on laptops and desktops.

If you go for a native app, you'll have to practically start over for every operating system.

Define "best". The best tools aren't necessarily the ones that give you maximum control or best performance. If that we're true we wouldn't have so many Ruby on Rails or Django web apps.

Good point. By 'best tooling' I'm mainly thinking about two things:

- How easily can I debug things if something breaks?

- In case I'm not happy with a certain behavior is it a dead end or can I simply swap out a parameter / function / module (in that order)?

These two aspects are IMO essential for choosing any development environment if I have the choice. This goes for web development too, which is why I'd prefer something like Django over something like Joomla for example. I don't even care so much about performance at that point.

Do you agree with me that at least in case of iOS, native beats html+js+webviews in those two points?

I wouldn't. Debugging js is quite easy, overall probably more straightforward than dealing with Xcode. And there are tons more choices in the js world, having both more developers and a more free-as-in-speech mindset.

The big downside is the one Facebook found, js in a webview is just... slow.

Correction. Debugging JS in not easy. I have been working on a native application which has some HTML5 components in webviews. There is no easy way in XCode to debug JS in this kind of mixed application. In fact, it is a royal pain in the ass. You can run the JS in Chrome debugger or a web development IDE, but that can only work if all your functionality is in HTML5/JS and not a mix of Native and HTML5.

Thanks. I was gonna ask parent how he does it because if it's easy for him he might know some magic I'm not aware of.

Wow, I am going to save this one:

"It's not really that HTML5 requires extra work, it's that it lets you get away with not putting in extra work and then the lack of that work ends up biting you in the end."

I have never experienced such hard-torque spin in my life. It's not that you would need to put in overtime if you worked here. It's just that we really let you get away with never putting in overtime, if you don't want to. And then that lack of overtime ends up biting you in the end.

The point he's making is this:

If you put in <x> effort into HTML5 you'll have a slow, shitty version. If you put in <x+y> you'll have a nice fast version.

If you put in <x> effort with a native app, you have nothing. If you put in <x+y> you have a working, fast app.

You get a working prototype faster with HTML5, but that's not a fair comparison with a native app which took more work to get working at all.

But it's not really true, at least if you want a truly fluid UI... although I think it's possible to make UI written in HTML5 feel native, I have yet to use a single complex webapp that truly accomplishes it, unless it's hidden in a UIWebView in some app I use. (Gmail might come close if it didn't apparently use onclick instead of ontouchstart, and custom scrolling instead of -webkit-overflow-scrolling: touch, for no discernible reason.)

It's not just that JavaScript is slow, although that doesn't help - having to worry about the performance implications of using libraries rather than directly using browser APIs, or being forced to use native scrolling because JavaScript scrolling just can't avoid lag, is a waste of time. It's also that where native UI frameworks are designed for performance from the start - every single UITableView is drawn lazily (implementing "immediate-mode" infinite scrolling on top of the deferred mode DOM is awful), you can fluidly move between low-level and high-level drawing APIs (Canvas is a very sharp boundary), animation feels built in rather than a recent hack (and I hope you're not targeting anything other than WebKit) - in HTML you have to fight against an absurd layout system to do anything and, in some sense, work around it to do anything fast; there are usually many ways to do it but most of them are slow.

And it doesn't help that where native frameworks have built-in controls to do a lot of things - and those controls look and feel native simply because they have the home field advantage of being what everything else has to mimic - HTML5 is left with a bunch of shitty webapp frameworks and the option of reimplementing everything yourself. The creators of those frameworks seem to assume things like if the animation looks vaguely like the original, there's no need to actually get the details right to avoid uncanny valley, or make it performant at all, so you probably want to make it yourself. I hope you know what you're doing.

As much as I love HTML5, you have to fight every step of the way to make something that works right. Getting a prototype out is easier with HTML5 than native, but for a moderately complex app, making it actually work right is vastly harder.

FWIW, I've had to do my desktop web development without the benefit of frameworks for the last 4 years, since the latency constraints on Google Search preclude using them. It's nowhere near as hard now as it was in 2007, when you had to worry about IE6/IE7/Firefox/Safari, and IMHO is the biggest hole in most web developer's skillsets. Mobile HTML5 is easier still as the vast majority of the market uses Webkit, though the Mobile Search team here tells me that you can't assume that since there're still a bunch of shitty Blackberries around. If you still need JQuery/Prototype/Closure to do anything useful in Javascript, I really would recommend learning the browser-native HTML5 APIs and CSS3, because they aren't that much harder and perform much better.

(I do like the better layout systems and widget libraries of native frameworks - I did desktop app development with Swing and MFC before HTML/JS, and it really was significantly easier to put together a complex UI that matches the native look & feel with those. HTML5 gives you the opportunity to be creative that you don't have when you overrely on a framework, though.)

Livestand by yahoo! on iPad, but y! killed it. i hope they bring it back. it was really awesome app.

To be clear, I'm not necessarily backing his argument. Just clarifying it.

>Yahoo mail's mobile site (at least on my iPhone 4 with ios5) is a good example of this.

An app which all of 50 people use --and many of them curse while doing it.

According to comScore, Yahoo Mail is the third largest mail provider with over 300 million users.

Kicker:

> in the U.S., Yahoo is No. 1, with 96.6 million active users

http://news.cnet.com/8301-13772_3-20114975-52/microsoft-aimi...

On the Kindle Fire (and my Android phone) at least, their mail app puts most others to shame. It's one thing they've done extremely well.

50? It's more than 50 million if I am not wrong. Get your facts right.

I think your reasoning is flawed here, what is in the good side of HTML5 to develop a mobile app for Facebook, even assuming good HTML5 developers VS good iOS/Android developers? HTML5 is not faster to develop in environments like iOS that provide good API and tools, and the stuff you can't do in HTML5, you have to find a glue between the native side and HTML5 that is non optimal.

So anyway, if you put X efforts, the native app will always win, because it can do all the stuff the HTML5 app can do, but also more, faster, without intermediate layers, in a more native way and with more native look & feel.

Without to mention that for Facebook to use 2x resources to develop the application would be not an issue.

The current Facebook app, if developed by competent guys, is a 3 months project by 2 people, per platform. A joke for FB. (Note: I'm talking only about the app itself, not the backend that is an invariant).

Facebook used HTML5 for a variety of political and technical reasons.

On iOS, using HTML5 decoupled deployment of functional changes from the App Store approval process. They could add a new feature on the servers and have it available on phones immediately. Certain parts of the new app still use HTML to allow new features without updating the whole app.

On Android, HTML5 let them support a large number of phones with fewer special cases to work around old versions of the OS and phone-specific bugs.

Except that, once you're done developing a hybrid app, you now have a giant chunk of reusable code. Facebook simultaneously supports several different platforms (normal website, mobile website, iOS app, Android app, Windows Phone app, Blackberry app, etc). Any amount of code reuse is a huge win when you're trying to maintain feature parity in many different directions.

Oh come on, you are making it sound as if it would be a massive investment for Facebook to develop native apps for multiple platforms.

If I can build a Facebook client that covers the most important features within 3 months (at 2 evenings per week after work) then I'd bet that a company like Facebook (with hundreds of developers that are much better than I am) could invest the needed resources (maybe 3-4 developers per platform) to create a truely amazing native experience.

I'd even argue that it is not an option for anyone in their position to even consider going HTML5 just to reuse some code. That would be just the wrong place to save a few bucks for them, considering that they need to make a transition to mobile pretty soon and failing to do so would be an open invitation for competitors to come and basically kill them.

Additionally I'd like to add that I am not convinced that is even possible (or if so many times harder) to create a content rich application like Facebook with webviews wrapped in native code that feels as fluid and responsive as a full native app. I have tried this in the beginning with my Facebook client (app link: https://play.google.com/store/apps/details?id=com.flipster) and failed miserably before stopping this webview nonsense, and so did the Facebook developers.

Agreed.

On the scale of Facebook's resources, building well-functioning apps just isn't a hard problem. Not saying it's not hard, just saying it's not hard on the scale of Facebook's resources.

Creating a functional and performant HTML5 app shouldn't have been hard at their scale either. So either it's actually impossible to do better than what they put out (which I find hard to believe -- is it really that much more complex than the HTML5-based LinkedIn app?) or there's some other reason.

I just can tell you what my experience is. I was unable to do it, but what you have to consider on Android is that a many customers are going to use crappy cheap phones with a weak processor, so every layer of abstraction added is going to hurt the performance a lot.

Additionally making the mobile app run smoothly on any device is just the bare minimum for what they should deliver. It's hard to not compare it against competition like the Android Google+ app, which absolutely crushes the Facebook app (I'm talking about the UI here, not about the social network itself), and that's where my sketicism comes from. Even if someone was able to deliver a WebView based app like Facebook, running smoothly on cheap devices, other competitors betting on native (like Google+) would still be in a different league.

How re-usable is it really? The bulk of the work is being done at the server in this case, and the app is mostly UI code. UI code is very platform dependant. I think that HTML5 is probably the future, particularly if things like Firefox OS take off, and it's probably fine for a MVP mobile app (possibly combined with something like PhoneGap). Currently though, native apps definitely provide a better experience, and you should probably do it if you have the resources... and this is from someone who really enjoys web dev and dislikes iOS dev.

+1 The whole reusability thing is a red herring, it's like the whole Java run anywhere thing, it might save you duplicating UI code but the apps will look crap and run like a dog.

I do not agree with your reasoning.

First of all, if going native, you'll have to put in twice the effort for targeting both Android and iOS, while an HTML5 app can be easily ported to WinPhone or even Symbian.

Will it be shittier than a native app if doing a straight port with no effort to make it seem native? Most definitely YES, but at least you've got an app to give to your customers that want to use your product. Because no matter how cool the new Facebook app is on iOS, I'm still and will continue to be an Android user.

Also, I do not agree that it's easier to develop that native app in the first place. I can easily do things in HTML5 in terms of UI that I wouldn't know were to begin with native widgets. All is fine and dandy when you're using the standard widgets, but if you want to have non-standard behavior, or to put your personal touch on the design, then all hell breaks loose, because those native widgets ARE NOT as fluid, as easy to change or as composable as a bunch of divs with CSS attached. People underestimating this point have never worked on designing interfaces in both HTML5 and native widgets.

And for the record, I hate the native app because it's slower than when using the website in my browser. But the work they did also improved the mobile website, which I find to be awesome.

     The current Facebook app, if developed by 
     competent guys, is a 3 months project by 2 people

Yeah and I'm sure that in their spare time those same 2 people could also build Twitter.

Or they simply don't prioritize mobile. As has been extensively documented, they make virtually no revenue off of mobile use and see no easy way to improve that situation in the future. They're stuck in a situation where a great mobile experience is a near-term harm to revenue.

That doesn't seem right. Facebook has an increasing user base focused on mobile, their main priority for the moment has to be monetizing mobile. It's not a simple solution but it's a long standing problem that they've recognized. Mark Zuckerberg notes the huge potential in revenue from mobile here: http://techcrunch.com/2012/09/11/zuckerberg-says-on-mobile-w...

I don't think those arguments contradict. I'm saying that in the short term, more mobile users means less money for the simple reason that mobile users aren't checking Farmville or reading ads. Zuckerberg might note a "potential" for revenue in mobile but he's not getting any today. (Quick google turned up this link to that effect, there are lots of stories like this: http://www.forbes.com/sites/greatspeculations/2012/07/27/fac...)

So in the short term, a better mobile experience hurts, not helps, FB's bottom line. So they'll likely be looking at spending their development resources elsewhere.

> Zuckerberg might note a "potential" for revenue in mobile but he's not getting any today.

This isn't true any more. The new version of the Facebook iOS app includes sponsored "your friend liked [brand]" callouts periodically in the news feed.

Except they have those same posts on the desktop version in addition to farmville and normal ads. That's even ignoring the fact that mobile ads are worth way less than desktop ones since people aren't really as engaged on mobile, and aren't likely to type in their credit card while they are on a bus.

> Except they have those same posts on the desktop version in addition to farmville and normal ads.

Yes, but they didn't have anything like it on mobile until just recently. The iPhone app was zero revenue. It is now non-zero revenue.

That is silly. No one leaves their phone number to go find a laptop to read Facebook.

Joe Hewitt isn't an amateur.

No one said that. Everything post-Joe Hewitt and pre 5.0 was amateur.

They tasked amateurs who didn't know what they were doing into building a hybrid native app container which in turn embedded HTML5 content.

Am I wrong that this basic design is Hewitt's?

I can't speak for him, but I do believe that was his vision for the future. However, what he shipped (Facebook 3.0) was native. He was long off the product before the frankenstein HTML5/Native Facebook app shipped.

Gotcha. Thanks for correcting me.

You might have been right about his vision for the future of the Facebook app. I do recall a blog post by Joe in which he mentioned something like that he didn't like developing native apps for iOS anymore due to certain policies by Apple.

A relevant news item here: http://techcrunch.com/2009/11/11/joe-hewitt-developer-of-fac...

How can you make your HTML5 code as fast as native? Apple provides great tools to help developers optimize native apps because there are times when native needs to be tuned. Maybe HTML5 can be good enough for some apps, but if you're competing to win, I'd suggest that you offer the very best app for each platform.

Lots of fetch-stuff-from-the-network-and-show-it apps spend 99% of their time waiting on the network anyway; optimizing the last 1% isn't really worthwhile.

(Of course, this depends heavily on the app.)

> How can you make your HTML5 code as fast as native?

https://developers.google.com/native-client/

Native Client apps are no more HTML5 than Flash is HTML5.

The key thing is that FB when the HTML5 route because they wanted to side-step Apple's signing process. They wanted to roll out updates on the server that downloaded to them without redistributing the app.

HTML5 webviews helped them do this, and worked on both android and iOS.

NaCL would, like java applets vs java apps, or flash, have let them do this too.

Yeah they could had focused on a mobile-first mobile site, but to be fair, if they didnt make the iso app how were they going to get a copy of your address book?

Maybe amateurs got assigned to it because it's hard right now to find HTML5 pros. And the problem is then HTML5.

But why did Facebook get away with it for so long?

http://www.quora.com/Facebook-Engineering/Why-does-Facebook-...

Why does Facebook not need to produce particularly high-quality software?

By paying less attention to quality, Facebook has been able to focus on other things, like making the company a fun place to work at that can attract and retain talented engineers. Facebook would probably be less fun if it cared more about quality.

Facebook's product is a website, so it can fix things quickly. It has a process which permits rapid deployment of new code, and rapid rollback of buggy changes. This reduces the cost of recovering from bugs.

Facebook's product has a lot of momentum and lock-in. The barrier for users or businesses to move off Facebook is very high. This gives Facebook a wider margin of error to ship glitchy software. If Google was broken for a day, you'd probably go to Bing and might not come back. If your iPhone pissed you off all the time, you'd probably buy an Android when you're faced with the decision in a year or two. If you can't order something on Amazon, you can order it from somewhere else. If Facebook is broken, you keep coming back until it works again.

I'm not sure I 100% buy into the first statement. Why are fun place to work and quality products mutually exclusive?

I'd say that Facebook's acquisition of top talent has much more to do with them having huge pre-IPO monetary incentive and less to do with being a "fun place to work".

Because quality either means writing tons of test code, or having lots of process and manual regression checks.

Any impediment to shipping code makes things less fun for many developers.

If they care about making the place attractive to talented developers, then why did they stick with PHP?

Not all of Facebook is written in PHP; most backend systems are C, Java, Python, or something else.

>* Why are fun place to work and quality products mutually exclusive?*

Because "fun place to work" obviously means beer and bongs passing around, in-office swimming pool, bikini models, pool and air-hockey tables, and Futurama watching marathons.

Which doesn't result in the highest quality products, if any products at all.

Or would you rather work at a place where every little change you want to make needs to be "approved", and any new ideas you wanted to try needs to be checked off by a manager, who may or may not want it implemented depending on the political situation?

No, because "fun place to work" means your #1 focus on building new features and getting them out to users as quickly as possible. Building quality products means the tedium of writing test suites larger than the rest of the code base, fixing them when they fail, and a sometimes-lengthy review process before pushing things to prod.

Not saying the stuff associated with quality is bad -- quite the opposite -- but (at least to me) that part isn't particularly fun.

Is that really what's it's like, or is that just what it looked like in a movie about its early days?

Because people really, really like Facebook apparently...

Where does the Instagram app use web views and/or HTML 5?

Lnkedin's fancy HTML5 mobile website sits and fails at the spinner on the splash page when I view on Android. That is one of the main reasons I gave up on LinkedIn. Hat and its devolvement into a sourcer spam haven

Linkedin's android app is 85% native and only 15% HTML5 :(

the problem wasn't them betting too much on HTML5. Their problem was developing piece of shit apps that happened to use HTML5.

Yeah, MZ is not smart so it is not surprising that he would say not correct things...

Heh...

Reply on news.ycombinator.com