Since Facebook announced their decision to ditch their HTML-centric app experience for a native one, I’ve been doing a lot of thinking about what that means for the HTML5 versus native debate. Unfortunately we’re at a point in the circle of tech where it’s easier to build a great native experience than it is to build a great HTML experience. I’d argue it’s not impossible to build a great HTML experience on mobile devices, just more difficult (I think Untappd is a great example, photo bugs not withstanding). The problem is that runs directly counter to why most people choose to go the HTML route and that causes a host of issues.
Today, when someone decides to build a mobile app from HTML, it’s primarily a developer-focused decision and not a user-focused decision. What I mean by that is that often times HTML makes it easier/faster/cheaper for someone to deploy a mobile app. Maybe they have a bunch of web developers and want to quickly crank out an app. Maybe they want to target multiple devices and they see HTML as a way to reuse code. Those aren’t bad reasons to chose HTML5 necessarily, but they do drastically change the goals of a project from “make this as awesome as possible” to “make this as good as we can with our constraints”.
So it’s no wonder that a lot of the HTML mobile app experiences are subpar. They started with the very premise of wanting to do it cheaper/faster/easier. That’s not a path to software greatness. Facebook again provides an example here. They had a ton of HTML content they wanted to reuse and an HTML-centric app was a fast, easy way to repurpose that content for mobile apps. Plus they could deploy it to lots of different kinds of devices with minimal code changes. They didn’t start from a place of wanting to make a great mobile experience, and the results spoke for themselves. When pressure finally got to a breaking point and they had to create a great mobile experience, they went with the clearest path to that route – native. This tweet by Josh Clark implies as much. It wasn’t that the HTML app was fundamentally unfixable, it was that (I assume) they looked at what it would take to make it as good as the native app and decided it wasn’t worth the effort.
I don’t blame people for making that judgement call. The PR boost that people used to get from throwing HTML5 into their marketing has started to subside and at the end of the day your users aren’t going to forgive a crappy mobile experience because you got 5 in a row on buzzword bingo.
HTML developers are in a rough spot right now because once you take out the faster/easier/cheaper argument, it’s tough to provide reasons why HTML is better than native apps. I see three main reasons. One, the web is a fantastic medium for designers and allows very unique experiences. Two, the ecosystem around web technologies has never been stronger and the number of cool frameworks, tools, and libraries that are available to web developers could have a significant impact on the kind of app you can build. Three, it never pays to bet against the web.
The first two I’ll cover in later posts and the third is the most subjective anyway so I want to talk briefly about that. For most apps, the future isn’t going to matter, so this isn’t a “future proof your code” argument. It speaks deeper than that. Do you want to be the kind of company who makes the future, or do you want to be the kind of company who follows along? HTML is the future. Just like native fell out of favor on the desktop, native is going to fall out of favor on mobile devices. The APIs are getting better for device access. Core graphical capabilities are being added that will make for nicer components, better experiences, and faster UIs. And the web is bigger than one company. The web is the great equalizer in tech. That leads to its own sets of drama about how we add features, but at the end of the day, no one will own or control the web. I see the web as a glacier. It tends to move very slowly, which can be a drawback. But when it moves, it brings everything with it and it carves a deep, permanent path that completely changes the landscape. That’s a tough thing to try and stop or stand in front of.
When you see an HTML mobile app that’s not as fast or snappy as it should be, think about what problem they were trying to solve. If the answer isn’t “build the best app possible” then don’t take that as a good example of what HTML is capable of. And if you’re building an HTML app put the same amount of effort, thought, and design into it as you would a native app. With the breadth of design possibilities, the HTML/JS/CSS ecosystem, and some forward-looking vision, you can build something that helps turn the conversation back to why the web is such an awesome medium for applications.Tweet