Facebook has now largely moved away from HTML5 in favor of native Objective-C code with their new iOS apps. And the results speak for themselves. Facebook had been one of the companies that most vocal in their support of HTML5 as the future of everything. The apps suffered as a result. And now they're changing their tune. Is HTML5 still just not ready for prime time? At least on mobile? Will it ever be? Is Apple to blame, as Dare suggests in his tweet?

I think we're seeing the same thing happen to mobile that happened to the desktop. Native apps moved to Web apps, and now we're seeing a hybrid. (Remember those "virtual desktops" from a few years back?) The native code becomes the envelope, the content, in the form of HTML5, comes from the cloud. It doesn't seem like HTML5 is necessarily the problem, instead, it's the limitations on the bandwidth to deliver all that content.

As I responded to Dare on Twitter (twitter.com), I believe both Flash and HTML5 only have themselves to blame for awful performance relative to native code. Apple simply optimizes for performance so while it may appear that they're "killing" these other platforms out of bad blood, they're just doing what will lead to the best experience. Apple has done just about as much as any company to move HTML5 forward with their WebKit involvement. It's simply not where it needs to be yet. At least on mobile.

Facebook told me HTML5 is still very important to them. When they were getting to scale they needed to be testing lots of tweaks, and HTML5 let them do that quick and quiet. Now I think it knows what it wants, can predict how people will react to changes, and needs to focus on speed. I think the big problem with HTML5 is that Google and Apple control the dominant mobile browsers. They have little incentive to improve them with more HTML5 capabilities that could steer app devs to the mobile web where they can charge users directly and away from native app stores where Apple and Google get to tax payments techcrunch.com

Which is an argument for why Facebook both needs to build their own browser and their own phone, Josh. Don't want to dive into that too much in this thread, but at the end of the day, Facebook has no control over either of these things. And that's going to be a problem in the long run.

It's worth noting that (although Apple is a large part of the reason HTML5 is so awesome) the iOS limitations on non-Safari JS performance (Nitro) have a lot to do with poor HTML5 performance in UIWebViews in native apps.

That's a fair point Jordan. Though the counter there is that it's mainly a security issue though, right? (I actually have no clue.) Remember that when the iPhone first launched, Apple tried to get devs to do web-based apps and the result was mainly crap aside from, incidentally, the Facebook version built by Joe Hewitt, which was great.

There's no denying that Apple has an incentive to push the App Store ahead of web apps for a few reasons, but I still find it hard to believe based on what I've seen that those apps could match the best native apps. Some shitty ones, sure. But the best native still seems so far ahead of the best HTML5.

MG, I agree 1,000%. As I wrote in a column in May, a Facebook employee, referring to Zuckerberg, told me: “Mark is worried that if he doesn’t create a mobile phone in the near future that Facebook will simply become an app on other mobile platforms." The big question for me, is can Facebook figure out its mobile strategy before its too late.

Engineering and product managers have consistently looked to Facebook as thought leaders in development. As a result, they insisted that building a mobile hybrid app was the best strategy even if it resulted in inconsistent, clunky experiences (Android webkit issues).

Hopefully, this strategy will now change, and teams will focus on building the best possible clients instead of using the build-once-deploy-everywhere strategy.

I have to agree with Nick in his first post. It is the circle of technology and we are experiencing the same events that happened with desktop and web. Currently the technology is limited for HTML5 on mobile web and due to this constraint native apps are currently the way to go.

I think once the technology supports it HTML5 and the mobile web will take over the native app space.

Like a lot of issues, I think it's not really about web v native all that much, but think that this is a pretty big & relevant signal that'll move more devs towards native. And I think that'll result in better app quality in the near term for sure.

We're in this ridiculously fast paced time of innovation on mobile. And while I'd love to invest in more webby apps (we lose a lot when we move away from the mashupable, indexable web), native apps can just deliver a much better, much more polished, much more tech current experience right now.

The web tech guys are trying to solve a different problem than "how do i build the most modern, cutting edge user experience" -- but that's the most relevant problem for the near term.

I agree that the current and better solution is to go native, just as Facebook has proven. But native is not the long term solution.

I will quote Marc Andreessen "The application model of the future is the web application model. The apps will live on the web. Mobile apps on platforms like iOS and Android are a temporary step along the way toward the full mobile web. Now, that temporary step may last for a very long time. Because the networks are still limited. But if you grant me the very big assumption that at some point we will have ubiquitous, high-speed wireless connectivity, then in time everything will end up back in the web model. Because the technology wants it to work that way."

Cody, I used to really believe the web model was inevitable, but I've come to be less sure.

Historically (going back a LONG way), tech tends to go from closed (in garages and labs) to open (as the stack becomes layered and commoditized) and back to closed (around distribution networks as the tech matures).

What's unusual about this wave is that with mobile, we've jumped directly to closed-around-distribution-networks (Apple, Google). It seems pretty clear to me that unless (1) HW slows down, (2) web tech is closer to parity, and (3) distribution is figured out, HTML will have a tough road.

I think it's possible, and it's what I'm hopeful for, but doesn't seem anything like inevitable to me that the web will win mobile.

Very fair point that I agree with. I too hope that the web can jump the tough hurdles it faces to become a leader in mobile.

BTW this is a great conversation!

Every so often a new platform comes around and all the pundits say oh this is the future, everything else is dead. Desktop software, web clients, now mobile clients etc etc. What Facebook's change really signifies is that user experience is tantamount to everything else.

There are hoards of complaints on how slow it was with the older version. I don't think my dad really cares if it was built with HTML5, Native iOS or flying monkeys, it just has to work seamlessly and users are expecting the same quality and speed on mobile as desktop.

I'm more curious to know why Facebook took this long to push out a native client. They have the all the resources they need and a ton of talent. What were the reasons for taking so long?

I agree Ketan. I simply think Facebook made the wrong bet with HTML5. Well, I should say, I believe they timed the bet wrong. Facebook is hardly the first to do this, but they are one of the biggest (again, Apple did this too when they originally launched the iPhone and wanted HTML apps). Facebook is still saying they believe in HTML, as does everyone, but the fact of the matter is that it's still not ready for primetime when it comes to delivering the best user experiences. We've been told every year that it's coming. I imagine it's still years away.

Facebook was all-in on HTML5 then had to do a full-stop and go the other way. It took them too long to realize the mistake. And we may look back as that being very costly.

1. Economics matter. At the moment, for a really 1st-class experience, you have to write 2 apps, for Android & iOS; with WinPhone coming up the track. In some cases, it’s just not gonna be justifiable to do it 3 times.
2. The fact that HTML5 wasn’t “Good enough” for Facebook doesn’t mean it isn’t just fine in lots of other situations.
3. HTML5 is getting better fast... but so are iOS and Android; each has a team of elite engineers holding their pedals to the metal. It’s not obvious that their relative attractiveness is going to change.
4. Both Android & iOS have a better programming model, and superior tooling, relative to browser-based development. If I were going to point at one area where HTML5 really needs to get better, that’d be it.

Good thoughts, Tim. Talking to Facebook back in the day, #1 was the main reason they seemed to be all-in on HTML. Even at their scale, they didn't feel like they had the right resources to make (and just as important, maintain) a native app for every single platform. Or they just didn't want to distribute the resources that way. As I noted above, in hindsight, I believe that was a mistake. And I believe they believe that was a mistake now, as they've gone the other way. I'm not sure they fully realized just how quickly iOS and Android would change everything, including the way people access Facebook.

Related: I think about Twitter. Twitter hired/acquired Loren Brichter of Tweetie to make their iOS apps. Because they were so dependent on this one person, they've struggled with maintaining them since he left. Well, they re-wrote the iPhone app (which, let's be honest, isn't as good as it was) and the iPad app had been left to decay. Brichter also wrote the OS X app, and the situation is the same.

This has to be a fear of many companies, I imagine. And I imagine this problem is much more pronounced with native code versus HTML. Thoughts?

So, two serious questions for developers here that have been around for transitions. (Paper forms to desktop apps. Legacy desktop apps to web forms. Business logic and web forms to rich web applications. Rich web applications to mobile apps. etc...)

Considering the shift from thick apps on desktops to HTML5, does this mean a shift from HTML5 to native mobile is simply the way to create a consistent experience in this moment at this time?

Machinations aside, is this 'back to app' approach also okay because of the (renewed?) emphasis on API as a short term bootstrap for social elements but a licensed API (or shuttering) as a defensive posture?

i.e. we'll help you grow and do chores but when you turn 18 we're kicking you out of the house

I think of the biggest reasons developers go for HTML5 embedded in apps is control. It's a huge pain to iterate quickly on iOS and you aren't guaranteed every user will have the same version. Then you have to support legacy versions and the whole thing becomes a nightmare.

The current native mobile landscape needs to improve where developers can make updates that go out to all clients, a/b testing, metrics and other standard web needs. Native mobile platforms still aren't mature on those items. The web has been around since 93 and modern app based mobile platforms really only since 2007. We are just getting started.

Don't even get me started on mobile QA.

My question is, what is everybody's opinion on the current state of the technology when it comes to developing a product or project for native vs web? Is it really solely based on budget and ability to wrangle in the correct developers or is it based on a project per project basis?

The cost of web app vs native is almost extreme. With native you need to support multiple OS platforms with very different skill sets needed for both, which usually involves developing a product or project multiple times. For web you need to decide on a single development platform and focus more on the client side presentation for multi-device support (which usually seems to be the much cheaper option).

I think the issue with Nitro (the faster of iOS's two JavaScript engines) only being available to Mobile Safari is a red herring. Yes, UIWebViews would be faster if Nitro were used everywhere. But native controls aren't just faster than non-Nitro-backed UIWebViews, they're also faster than Nitro-backed web apps running in Mobile Safari.

The big difference is between native controls and controls embedded in web views, period, whether those web views are inside native apps or running in Mobile Safari.

Same thing is true on Android and Windows Phone. Native apps feel faster. And I really believe that mobile web apps feel faster on iOS than they do on Android, even with Chrome on Jellybean.

@Cody, good question. Our view is this, HTML5 is for validation, and native is for execution. You experiment and solidify your product with HTML5 on mobile internally, and when you have nailed that basic experience, you making it sing with native.

That does mean you have multiple development paths but that's just the cost of doing business. You can offset costs by doing initial development on HTML5 but to truly take advantage of mobile, you have to live and breath native.

The reality is you must have a strong HTML5 component to do mobile right as the core of mobile is access anywhere, anytime.

@Gruber
Native will always be faster as its compiled code. Script will never execute as fast as binary given the same hardware.

Given that Facebook's move seems to have single-handedly shifted perception of the "right" way to do things from hybrid HTML5 to full native, which is very much what Apple wants as well, I wonder if this was part of the deal that brought Facebook integration into iOS 6?

The timing lines up, and it's strategically useful for Apple. If people have limited resources, and they're going to be native, you'll see more Instagrams (iOS-focused apps) and fewer cross-platform, which makes iOS stickier.