Mobile Apps: HTML5 vs Native

Last week, Facebook transitioned its iOS app to be fully native. This has triggered another round of debate over the merits of native apps vs. HTML5. I am motivated to contribute my thoughts on this issue.

Public discourse on this topic tends toward the extremes. I participated in a recent discussion which started with someone worrying that his company will have to support Microsoft Surface in addition to Android and iPad, and ended with someone saying, "Or you could use HTML5 and get all three platforms for free."

Marc Andreessen, an influential bishop of the web, has said: "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."

It seems like most people look at this situation and see black or white. I tend to see shades of gray.

The question

The main question in play here is: How thick should clients be?

Let me define my terms:

I define the Client as the thing which is used by exactly one user, which interacts directly with that user, and which is probably physically close to that person.

I define the Server as the thing which is shared by multiple users, which interacts directly with the Client, and which could be physically located anywhere.

I define the Pipe as the connection between the Client and the Server.

I define the notion of a Thick client as a relative term. Thicker clients have more app-specific code and are less dependent on the Server. Thinner clients leave more of the app-specific work to be done on the Server.

There are two main variables in decisions about the thickness of clients:

The quality of the Pipe: This includes bandwidth, latency, availability, reliability, and cost

The Client side costs: This includes cost of hardware, software development, deployment, upgrades, and maintenance.

And, there are two laws which apply:

As the quality of the pipe goes up, the client can get thinner.

As the client side costs go down, the client can get thicker.

The Extremes

If the Pipe quality were perfect, the client could be "wafer thin".

A Pipe with perfect quality would have infinite bandwidth and no latency. It would be available everywhere. It would be 100% reliable. And it would cost nothing.

If the Pipe were perfect, the Client would be almost unnecessary, needing to provide nothing more than a physical presence for the Server.

On the other hand, if the Client side costs went to zero, the client can be as thick as we want.

A Client with zero costs would be constructed from physical components that cost nothing. It would contain software that cost nothing to build, which could be installed and upgraded and maintained with exactly zero cost or hassle or effort.

If the Client side costs were zero, there would be no need for the Server, except to facilitate communication between Clients.

And why does the thickness of Clients vary?

Because varying Client thickness creates opportunities to compete in the marketplace.

You can differentiate yourself from your competition by making your Client thicker (more expensive) and talking about performance and a better user experience and stuff like that.

Or, you can differentiate yourself by making your Client thinner (less expensive) and talking about lower Total Cost of Ownership and easier installation and stuff like that.

This issue is not new

Back in the 1960s and 1970s, when we only had mainframes and minicomputers, there was a distinction between smart terminals (thick clients) and dumb terminals (thin clients).

In the 1980s, we got workstations (really expensive thick clients, purchased by people who perceived them as cheap compared to the mainframes and minis) and microcomputers (far less expensive thick clients, purchased by people who previously didn't have a computer at all).

In the early 1990s, the high cost of workstations gave rise to X terminals, thin client devices which couldn't do much more than display the graphical user interface. My manager bought one of those fancy new 19.2k modems and actually tried doing Motif widget development from home.

In the mid 1990s, web browsers appeared. For a very brief time, this technology was regarded only as a way to collaborate on hypertext documents. This phase of the web lasted for most of an afternoon. Meanwhile, back in Champaign, Illinois, the Unsung Hero and His Eminence were busy building a web browser which had more "stuff" in it. What kind of stuff? The sort of stuff that made web browsers into a platform for delivery of apps. And the technologies of the web have been moving primarily in that direction ever since.

Java applets (developed a fatal disease called Swing)

ActiveX (declared dead seven years after it went missing)

Flash (murdered by Steve Jobs)

Silverlight (murdered by HTML5)

In the late 1990s, people (Oracle, I think?) tried to sell something called a Network Computer. It was a little PC with a video card, some RAM, an ethernet card, a web browser, and no hard disk. Thin.

Microsoft tried to murder the infant web. Then they tried to be its Mom. Then Bill Gates retired and I haven't been able to figure out Microsoft's strategy ever since.

While Microsoft was trying to cling to Windows as a thick client solution, Citrix was trying to make it thinner, building multi-user mainframe-style computing for Windows. The medical clinic here in Champaign deployed Citrix throughout its network, which explains the increased latency of my doctor, but his fees didn't go down.

HTML5 arrived. Actually, the spec is still a long way from being finalized, but nobody knows that. People needed a name, so they started saying "HTML5" before it was fully cooked. Common usage of the term "HTML5" is actually fairly accurate, at least compared to the way telecom companies use the term "4G".

And now, this war has moved to the battlefield of mobile. Smartphones and tablets.

Black and white

As I said above, people exhibit a black-and-white mentality about this issue.

In part, this is because people who make polarizing predictions tend to sound more visionary. In some situations, being inspiring is far more important than being correct. Venture capitalists in a bubble need to appear visionary so they can attract the deals with the most buzz, because those are the companies that can be sold quickly.

Another reason that people like to hear black-or-white predictions about the future is that it makes them feel better. Uncertainty is uncomfortable.

Broadly speaking, nobody likes articles like this one, essays which claim that the world is defined in shades of gray. This is why you stopped reading two scroll bars ago.

But on this issue, the black-and-white predictions are simply wrong.

I may not be inspiring, but I'm right

The quality of the pipe will continue to go up. In 1992, I was using a 14.4 modem. In 2012, the slowest network connection in my life is hundreds of times faster and far more reliable.

The client side costs will continue to go down. In 1992, I was using an HP Snake 730 workstation. In 2012, the hardware specs of my iPad are hundreds of times better in every category, and it cost 97% less.

Neither of these technologies is like batteries, which basically have not advanced since Kennedy was president. Both sides just keep getting better, steadily, year after year, with no end in sight. Individual battles are won and lost, but the battle rages on. Neither side has gained a permanent and decisive technological advantage over the other. And if you think that's going to happen in your lifetime, I think you're wrong.

Inspiring, perhaps. But still wrong.

Bets

Nonetheless, we must place our bets on one side or the other. There's a lot of money to be made in being on the winning side of these little battles.

Furthermore, my use of the "war" metaphor does not bring issues of national loyalty or citizenship into play. People who bet on thick clients in the last battle are free to bet on thin clients in this one.

Because of my earlier experience, folks tend to think I should always be a "web apps" guy. In the early days of the web browser, I was there. I wasn't nearly as successful as Mr. Andreessen. Marc was above the title. My name was after the fade to black, on the third page of the credits, and it took me three takes to get my line right. But web technologies are a big part of my career. I'm a believer, and I am an appreciative user of many of the web apps which have changed the world.

Nonetheless, for this round, I'm betting on native apps, for three reasons:

Recent declines in Client side costs. For example, the App Store makes a huge difference in issues of installation and upgrades.

Current problems with quality of the Pipe. Users of smartphones and tablets have high expectations regarding the quality of the user experience.

My own preference. I'd rather spend my time creating products that delight users. Wal-Mart may be successful, but the goal of making everything cheaper just doesn't look like much fun.

So that's why I pushed SourceGear into shipping a native iPad app for onVeracity.com.

When I first started exploring this path, somebody on the team asked me, "Why can't the iPad people just use the web app?"

Like I said then, web apps and native apps can and will coexist.

But native apps are just better. They always have been. That's why they cost more.