Do Web Applications Suck?

Posted by on May 6, 2010 at 4:22 pm.

A recent rant about the state of the web has made its way around the tech chattersphere, and is part of the growing commentary on application development for native applications (something you install, on a PC, Mac, iPhone, Android) versus web applications (written to work in any of the major web browsers).  The general gist is how fantastic it is to see the re-emergence of cool native applications, and how much more robust, functional, and well-designed they are compared to web applications, because they are liberated from the lowest common denominator approach of web standards and can take full advantage of the specific device they are running on.

So are web applications now the equivalent of MS-DOS applications, circa 1990: dinosaurs in the face of applications with windowed, mouse-controlled user interfaces?  Or is this just excitement over what’s shiny and new right now?

Context, part I:  One computer to many devices

It wasn’t too long ago that everyone was celebrating the death of traditional (aka “native”) applications and the liberating rise of web applications.  In the past, you had to have your floppy disks, your thumb drive, or your e-mail file transfer system to shuttle data between all of the local native applications you ran.  You had to hope your friend had the same software installed to show them your work.  And you got annoyed.  You didn’t have the right version…of the file, the software, whatever. Or there just wasn’t any way to do the job electronically at all, because the software the system used was too expensive or too complicated.

So when the web application revolution began, it was liberating.  You could get to your e-mail from any computer, spend endless hours searching for the best airline fare without a grumbling travel agent, file your reimbursement before you even got back to the office,  and unleash your creative skills designing your next holiday card.  All from the web.  And you couldn’t wait until you untethered yourself from every last installed application you had on all the various computers you owned and used.

Context, pt II:  From fixed on the ground to mobile in the cloud

So why the sudden counterrevolution to take us back to what we were so happy to get away from?  If all of those “old” applications were such a frustration, why are the new ones so appealing?  For the answer, we look to two of the big changes in the last few years in how we use computers and applications:  cloud-based services (typically remote data storage and computer processing at large scales) and mobile devices (aka “smartphones”).  And an additional “secret sauce” we’ll get to in a minute.

From the viewpoint of the user, you could say that most web applications succeeded because they took advantage of the cloud (even if it doesn’t meet the technical definition):  whatever you were doing happened on the web and the data you created was stored there as well, for you to access from anywhere.  The big change from old applications to web applications was this connectivity.  The new native applications have stolen the thunder from the web applications, because they use the cloud too.

The other big difference is that where we see most of the native application success is in the world of mobile devices:  the iPhone, Android phones, and now, in particular, on the iPad.  These are very different from most computers, because they are personal, in the sense that you actually take them with you.  Everywhere.  So the old application problem of not having it on the computer you are using goes away…because you are always using just that one device.

And the secret sauce of the new native applications?  It’s design.  “Traditional” desktop applications were horrendous looking things, both because nobody seemed to care, and also because there wasn’t enough computing power to make things look nice.  The evolution of the web brought in a cadre of people with design backgrounds while Apple raised interface design to a temple for worship, and now the new applications have adopted similar attention to design, and look nothing like the old systems we once abhorred.

Pick the right tool for the job

The only thing that all of this tells us, though, is that you can now make native applications that are really good, and succeed because of both what the web created (cloud services and nice design) and because of a whole new paradigm in mobile personal computing, not to mention the intrinsic virtues of a native application.

But is it the death knell of the web application?

I seriously doubt it, because there is a whole dimension of the question still unanswered:  what, exactly, is it that web applications “suck” at doing?  But it is perhaps easier to see this by looking at when native applications are better.

Native applications are fantastic when you (as a user) have a task which:

  • You undertake frequently and repeatedly (like checking e-mail);
  • Relies upon a set of services or contextual information specifically native to the device you happen to be using (think GPS location);
  • Has very complicated workflow or interaction behavior which benefits from a highly sophisticated design interface; or
  • Is performed primarily on a single, “personal” device like a smartphone, which you always have with you .

While there are certainly a large number of applications which fall into these categories, many don’t.  And for these types of applications, a web application is probably better, or at the very least, “good enough.”  And there isn’t anything wrong with that.

Serving up universal access

And let’s not forget one area where web applications vastly outperform native applications:  universal access.  This is a feature that can get easily overlooked by the new apostles of the native application.  It is certainly fantastic to be able to benefit from the vastly improved interfaces that some of these devices enable, but let’s not forget that these devices are considered a luxury for many, whether as individuals or as institutions.  One could argue that this could change (and it probably will), but the trailing edge of adoption is very slow.

One of the great benefits of the web is the level of access to services and information which has been granted to the public at large.  A public whose needs have been successfully served because of the lowest common denominator approach of standards-compliant web technology.  Fostering a new race to develop competing platforms significantly undermines our ability to serve a wide and general public, to serve those who happen to be on the trailing edge.

And ignoring their needs is what would really make the web suck.


  • David Ledgerwood says:

    Interesting. I'd like to hear your thoughts on the hybrid model as that is an option that needs to be considered. It seems as if companies, especially small ones, are only willing to invest in one strategy or the other, most likely due to resource constraints or the business problem at hand.

  • ryanfrazier says:

    In my mind a “hybrid” model can look like a few different things (so let me know if this isn't what you were thinking):
    – “Embedding” web content within a native application (though this tends to be more of a hack than a strategy)
    -Creating both a full-featured native application and a “light” web-based application (probably the most common)
    – Using a “platform-independent” application model, like Adobe Air or Java
    – Creating applications which are “functionally identical” but have both native and web-based versions (can't think of too many good examples in this category)

    What I said with the general case still applies here: you need to pick the best solution depending upon what you are trying to achieve with the application and how you want to position it within the marketplace. And for companies doing development, it is a really important consideration, because, as you said, the more you try to do, the more resources you have to spend, and the more risk you run of either fragmenting the product (different functionality on different platforms) or impeding development (keeping products in parity, but being limited by one of your platform choices). Note that this choice also plays out if you choose to build native apps, because there are platform choices there: iPhone/iPod Touch, iPad, Android, PC, Mac, Linux…and so on.

    For consumer apps it probably makes the most since to focus more narrowly, at least in the beginning. For Enterprise applications, I think it is much more common to have a hybrid model: full function native application for “power users” and web-based applications for casual users. This reflects some of the distinctions I laid out in the post, with the difference being that you have two very different user groups, both of whose needs must be satisfied. While most of the modern ERP systems embraced a full web-based model for both groups, a large amount of technical complexity was introduced to create all of the necessary functionality for power users in a web-based application. I've not really thought about whether that is a good and sustainable strategy or not, but that's an interesting question. I haven't followed that market recently to see what the developments and trends have been.

    The other part I didn't even get into was HTML5, which adds a lot of application functionality and is creating the dust-up between Adobe and Apple. I think it is an important development, but because of my universal access concerns, I hope browsers can keep up to standards instead of trying to fragment into “best of breed” solutions competing with native application platforms.

Trackbacks / Pingbacks

Leave a Reply