HTML5 Zone is brought to you in partnership with:

Jesse Warden is a Flex Architect & Partner at Web App Solution, a growing company specializing in Flex/Java/BlazeDS/LiveCycle/AIR development. Jesse is a DZone MVB and is not an employee of DZone and has posted 32 posts at DZone. You can read more from them at their website. View Full User Profile

Facebook’s HTML5 Mistake

09.13.2012
| 11915 views |
  • submit to reddit

Laides & Gentlemen, some key points to keep in mind when reading about Mark Zuckerberg’s latest statement about Facebook’s mobile strategy:

“The biggest mistake we made as a company was betting too much on HTML5 instead of native… We burnt two years.”

http://www.theverge.com/2012/9/11/3317230/mark-zuckerberg-betting-on-html5-for-mobile-was-a-mistake-hints-at

I’ve seen some holes in a few of the blogs & commentary that I believe need plugging.

1. Companies have no choice, they have to have an HTML5 Strategy

If customers access your website on a device, it needs to work. If that is simply 1 page that provides a link to your iOS app store or Android Play store app, fine. SOMEONE has to build that web page and ensure it works on that particular set of devices.

Alternatively, it could just be your existing website that you’ve ensured renders reasonably well on iPhone, iPad, and Android. That, or whatever your analytics are telling you. Remember, interpreting quantitative data is key; just because 1% access your website on iPad could mean because it doesn’t work, hence they stopped trying.

Metrics have shown that consumers do not like “Download our App” as whole screen, first pagers. Metrics have also shown that if you show that screen without an easy way to use the site, they leave.

Conversely, for larger web applications, it’s not as simple as using “responsive design” (yes, I said it, take a shot) and calling it a day. In large companies with larger web properties, you’re talking multi-month initiatives to get a 3rd party agencies to respond to an RFP/RFQ, pick one to pitch an analysis of the companies mobile needs, design it, and Directors to figure out if you convert your existing code base or start anew, not taking into account the different API needs that may arise on the server-side. Sometimes stop-gap plans are put in place to give the user SOMETHING so they can at least be productive and/or it ensures the brand isn’t significantly hurt whilst larger initiatives get underway.

Also, some apps can only be downloaded on wireless.

For these reasons: web only access, app incompatibility with device, user experience, and lack of wireless.

Notice NONE of the above has anything to do with cost, developers, or user experience. It’s a fact that users surf the web on web browsers on their devices and expect things to work without having to download an app. If they use it everyday, it’s proven they’re more likely to download an app.

Until iPhone, iPad, and Android remove their web browsers, companies HAVE to have a mobile web strategy, period.

Web applications are a completely different story.

2. Web Application Cost Structure

The marketing goes, “Use HTML5 because it is ubiquitous, and the majority of your code base can be reused between various devices using responsive design.”

That is simple statement that varies in truth depending on what you’re building. A simple website with text content? Sure. Anything more complex, and the question’s answer gets more complex. As you know in software development, complexity == time and money and risk.

For some companies, the increased opportunity mobile usage by consumers covers the cost of new or additional development. For them, native’s a shoe in, as is an HTML5 strategy along side the same teams, even if different companies. For others, they make bets on the technology stack for a variety of reasons. Maybe they only know Android developers. Maybe it’s hard hiring Objective C people in their area with their small hiring budget. For whatever reason, they have to make a cost analysis of the software stack. As Patton would say, this is a “calculated risk”.

Part of that risk assessment is eyeing the current landscape, seeing what was built with the existing stack already, comparing the end product with your current teams capabilities, and sallying forth with much gusto. For others, they don’t have time, they’ve been at this for so long that they know stack often times doesn’t matter. So they sally forth.

The problem with both of the above is that if you’ve done any startup work, you know you sometimes have to pivot. These cannot be predicted, they’re in direct response to both user/customer feedback, stakeholder input, and leadership judgement calls. Can your stack support enough leeway? THAT is hard to predict.

Even if you’ve done a great analysis of your market, your existing product portfolio, your customers’ needs, your technology stacks’ capabilities, your team’s capabilities, hiring prospects, you could still gloriously fail when you hit scalability problems you can’t quickly recover from, or client-side rendering/performance issues that make you re-think you’re entire architecture, even when you’re team has had a lot of sleep and is in a good state of mind to make such a reflective decision.

Just keep in mind not everyone can afford 5 development teams when they used to have 2, or keep 5 afloat and deliver the same expected capabilities form consumers. Everything has a price. Sometimes the increased opportunity pays for that, sometimes it doesn’t. Even if it does, there’s no guarantee you can deliver even with a great cost & capability assessment.

3. Even Great Developers Can Suck

Back in 2006/2007, Yahoo, to compete with Google maps, re-did their maps in ActionScript 3. Right out of the gate, it had some massive performance lag on the server delivering map tiles compared to Google Maps. I also noticed they were not utilizing any of the Bitmap API’s that Flash Player provided for increasing performance of large and many bitmaps. I also knew one of the developers and knew he was great. The press didn’t see those things. AJAX developers didn’t see those things.

What they saw was Flash sucked, and Yahoo wasted their time and choose the wrong technology.

What we Flash Developers saw was Yahoo “doing it wrong”. Here was a golden opportunity for a flagship example to prove to all the haters they were wrong.

If you’ve been in software development awhile, you know a huge percentage of all of the failures are not the developer. They’re leadership and management. Basically people, not code. You get ANY of these dudes who’ve worked on high profile projects like that drunk, and ask them about the drama, it’s insane. It’s hard enough with the pressure, with the multi-team challenges, with the deadlines, let alone good old challenging software development… now you add drama on top?

We currently do not have transparency into how Facebook executed on their mobile app. What we do know is that many assume HTML5 is either:

A. still awesome and the Facebook developers suck and “did it wrong” despite proven hiring practices to the contrary

B. sucks, and I told you so, duh despite many HTML, not HTML5, apps that are wonderful and a staple of the online world today (Facebook, Gmail, Google+, Harvest, Freshbooks,etc).

If you’ve ever actually shipped software, you know it’s hard and it doesn’t always go exactly as you planned. Just because Facebook is Facebook doesn’t make them an alternate reality of software. No, for that, we have Google.

Conclusions

Users have web browsers on their phones and iPads and expect them to work.

Companies do not have scientific ways to ensure the technology stacks they choose are “correct”. Failures happen all the time. We’re just hearing about it more so because of all the hype for HTML5 + Facebook hiring who they hire + their falling IPO. The market is currently laser focused on this use case as some qualitative proof of some preconceived notion.

Unless you developed the Facebook app, you don’t know what really happened. You can do all the DOM vs. CSS rendering debating you want, but even if there were some leadership issues, a more likely scenario was #2; Facebook didn’t anticipate the amount of features users wanted and pushed the HTML5 envelope on mobile. Good for them. They have the capital to do cool things like that and re-invest into native mobile solutions. Not everyone does and we should be thankful they have continued to talk openly about their HTML journeys.

Regardless, native performs faster than HTML5, has more mature tooling, and better languages for larger applications. For consumer focused companies, you can actually monetize those without an existing platform.

That said, web browsers aren’t going anywhere, and people will continue to use them. HTML5 isn’t going away just because Facebook’s users wanted faster mobile apps.

I’d be lying if I didn’t admit it’s nice to see a large company have buyer’s remorse like all us cynical, bitter ex-Flashers said was going to happen. It’s lessened by maturity (yes, I’m getting there), and the fact that this was more user driven than HTML5′s fault.

Published at DZone with permission of Jesse Warden, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Balázs Bessenyei replied on Thu, 2012/09/13 - 2:13am

http://blog.mobtest.com/2012/05/heres-why-the-facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/

Martin Spasovski replied on Thu, 2012/09/13 - 5:04am

Um, the full quote what Mark Zuckerberg said is the following:

 

When I’m introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native… because it just wasn’t there. And it’s not that HTML5 is bad. I’m actually, on long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.

 

Emphasys by me.

 

Here's the reference: http://blog.tobie.me/post/31366970040/when-im-introspective-about-the-last-few-years-i

Greg Brown replied on Thu, 2012/09/13 - 9:05am

I think the easiest way to summarize it is "use the right tool for the job". Sometimes that's HTML, sometimes it's not. Both HTML and native apps have a place - as always, which one is the "right" tool depends on project requirements and constraints.

Liam Knox replied on Thu, 2012/09/13 - 3:44pm in response to: Greg Brown

Amen.

This phil predates the web and prob most of civilisation

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.