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.”
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.
…and yes, please do sally forth!
DOOO IIIITTTTT
You referred to yourself as one of the ‘cynical, bitter ex-Flashers’. Say it ain’t so. No Apache Flex? No Flash? Its just HTML5…rah, rah, rah? Its indeed a sad day if the Jester has abandoned the good ship Flex.
Why is it so ? On the contrary, I see it as wise to abandon a fast dying technology earlier than later. Don’t be afraid to learn new things :-)
“fast dying technology”.. may I inform you that the game that records the highest income in the last years is farmville.. which is a Flash game…
Speaking of YMaps, Paul Neave had an INCREDIBLE maps implementation in Flash around 5 months before that Y! doomed project launched. Still better than any other I’ve seen for responsiveness. I became aware of the YMaps work going on and started showing Neave’s work to those involved (I’d co-opted the codebase for an LCCS project at some point and optimized it even a little more), but they’d already written a ton of code and proceeded to suck wind. A real, preventable bummer.
Keep fighting the good fight here!
On a similar note, I believe people think that HTML5 will solve whatever issues (some) Flash implementations had in terms of performance – caused both by the player and devs alike (and as you mentioned management/leadership play a role too). A high profile case like this helps to shed some real light on HTML5’s infancy and lack of features when compared to native. And at the end of the day (not just in the mobile space) you have HTML5/CSS3/JS vs. all the native languages on mobile, Flash, Unity, etc – from a performance standpoint there are some things that simply can’t be done right now. From a language perspective (JS vs. AS3/C#/Java/Objective C) what is to be expected?