With the advent of Web 2.0 and webapps like Gmail (circa 2003), everyone started talking out how all desktop apps would be eventually converted to webapps. Prior to Gmail, people didn’t believe that such a paradigm shift was possible. Websites were not considered as heavy-duty as desktop apps for a lot of use cases.

Gmail gave us new hope. Around the same time tabbed browsing became popular. The combination of tabbed browsing and rich webapps was supposed to deliver a death blow to traditional desktop apps — aka “thick clients”.

This combination promised that we will finally get rid of the nagging problems associated with desktop apps. Some of the serious problems that webapps addressed were:

  • Each tab of a browser was completely sandboxed. To try a new app you didn’t have to install anything. It promised us freedom from DLL Hell. Business apps were no longer dependent on arcane ODBC drivers!
  • Keeping multiple tabs open and switching back and forth was very convenient making us super productive.
  • App delivery and upgrades were simplified. The executable code that made up the app was distributed and managed from central servers.
  • New apps didn’t impact the performance of the OS. No virus problems (with the notable exception of webpages embedding ActiveX controls!). No Registry conflicts. No spyware.

But there was one big problem. Those webapps were simply not as capable as desktop apps. JavaScript (JS), the language primarily used for the UI was not designed to be an industrial strength language for developing rich UI. Complex projects resulted in thousands of lines of spaghetti JS. Frameworks like Google Web Toolkit were introduced to bring some sanity into the entire process.

All of a sudden, the future didn’t look so bright after all.

A few years later, we saw another wave of optimism with HTML5. HTML5 held the promise to solve world hunger. Everyone was dreaming of an Utopian world where you could write rich apps once and those apps would run on different platforms with little or no modification.

HTML5 was a standard. No single company controlled HTML5 and developers would no longer be held hostage by Microsoft APIs. No vendor lock-ins. For the first time in the entire history of computing, it seemed possible to learn one front-end technology and deliver apps on all platforms. The promise once Java made, but failed to deliver — especially for the UI layer.

Ironically, the problem with HTML5 is that it was a “standard”. It was evolving rather slowly. It was a democracy-led development, not a dictator-led development. Historically, some of the most successful technology companies were dictator led. Notable examples are Apple, Microsoft and Oracle.

Meanwhile, all of us continued to love our browsers and its tabs for a lot of computing activities.

Then the iPhone launched. With the launch of iPhone, we were unknowingly transitioned to a new era. In my opinion, the best way to define this era is — “The OS is the new browser — apps are the tabs

The new era retained the richness and power of desktop apps and the delivery and sandboxing advantages of webapps. Additionally, you can use industrial strength languages C, Java and C# to develop apps.

iOS, Android and Windows 8 are designed ground-up to act more and more like browsers. There are some striking similarities.

  • Launching an app became as trivial as launching a new tab
  • Switching between apps became similar to switching between tabs
  • Installation and upgrades are seamlessly delivered through central servers. Those central servers are called App stores.
  • Complete sandboxing of apps. One app cannot access the data of another app. No DLL hell. Virus and spyware were contained.

However, nothing is perfect. This model introduced a new set of challenges.

In the classic browser and webapp model, seamless transition from one webapp to another was done naturally, using hyperlinks and URL parameters. In the app world, such seamless linking between apps is not popular yet. However, things are changing. Many apps now support URL schemes. For example, from the Twitter mobile web, you can launch the Twitter app with the right context. Over time, this integration will evolve and you can pass data from one app to another in more sophisticated ways.

Developing apps for multiple platforms is expensive when compared with HTML5 apps, that have a common codebase.

If development cost is the only reason you are settling down with HTML5, you are not working hard enough to create a killer browser tab for your app. You are going to miss out. Users don’t care about the cost implications of the developer. They care about the quality of their experience. Products that are winning provide the best experience.

[Image Courtesy of Windows Blog]