A New Era in Application Development, Part I

Roughly speaking, we have had four “eras” in the computing industry, each era defined by the dominate platform at the time. The eras were:

• Mainframe
• Minicomputer
• Client-Server
• Web

I believe that we are now entering a 5th era: the Device + Cloud era. Simply said, the Device + Cloud (D+C) era is defined by users having multiple devices and running thin applications that share data via the cloud on each of them. As your use of the devices goes up, you rely on the applications more and more.

I have five devices that I use and travel with: a Zune HD, a Kindle, an iPad, an Android 2.3 Nexus One Phone, and a Lenovo Laptop computer running Windows 7. Since my Zune and Kindle are dedicated devices for one purpose (even though that they try to be more), I use my Nexus One Android, iPad, and Lenovo as my primary computing devices. I use similar apps on all three devices, apps that use the cloud for execution and storage. Examples of apps that I use on all three devices that I can’t live without are TripIt, GMail and Evernote. These apps represent the future of software development: cloud storage, cloud “logic” engine exposed via an API, and multiple native clients.

Applications in the Device + Cloud Era

While email, social networking, and travel apps were the early adopters of this paradigm, I consider Evernote to be one of the “killer” apps of the Device + Cloud era. (There are several other killer apps, but I will focus on Evernote for this discussion.) By looking at how I interact with Evernote, the Device+Cloud paradigm will become more clear.

I interact with Evernote in one of four ways. For my job at Telerik, I spend a lot of time in front of my laptop. At any given time I have four applications open: Chrome, Skype, Evernote, and Tweetdeck (as well as a VPC with my development environment). I use Evernote as my main “writing” client, writing out memos, keeping lists of stuff to do, blog post drafts, and archived PDFs of important documents, etc. I share notebooks with my wife that lists of the wines we have tried, what songs we are going to play at our wedding party, and of course the grocery list. My interaction with Evernote is with its native Windows client. It gives me the ability to copy and paste, use rich formatting, drag and drop, right click menus, and all the things you would expect with a Windows application.

Later in the day when I am out and about, I use Evernote on my Android. This too is a native Android app and it takes advantage of the Android operating system, giving me tight integration with the OS and a live widget to sit on my home screen. It is touch integrated as well its UI is tailored to take advantage of the Android system. When I am at the store, I look at Evernote for the items I need to buy as well as look up the passcode to my apartment buzzer. As I cross off items on my to-do list in Evernote, I update the note on the fly. Also when I see something and want to remember it for later (like a friend telling me the name of a good book or movie), I make a new note.

I also interact with Evernote on my iPad. I use my iPad mostly for reading the newspaper, Flipboard, Hacker News, and email or watching TED videos while lying in bed. (I know Steve Jobs had a grander vision for the iPad, but that is my reality.) The iOS also has a native Evernote client. The client there is visually stunning and multi-touch enabled, but slightly behind the other clients, not allowing rich text and media editing. I usually jot down notes while reading in my Evernote iOS client.

Lastly, I also interact with the Evernote Web app. Usually when I am trying to log onto Telerik’s VPN from an Internet Café in some far away place like Nepal and I need to look up my VPN password stored in an Evernote note (please don’t tell the Telerik Admins this!)

Evernote is a productivity app, not a Facebook client, so it is no longer easy for the “mainstream” to ignore the new era. To be fair, they have not, I interact with native clients on my devices for my bank, credit card, airline, brokerage account, the Hong Kong public transportation system, local TV station, as well as “official” apps from my favorite sports teams, etc. The D+C paradigm may have been started by social media, embraced by start-ups next, but it is now going mainstream.

Application Development Complexity in a Device + Cloud World

Building an application is no longer so simple in the D+C world. Evernote is making use of several different technologies to build its client natively on each platform. This is not a huge problem since most of Evernote’s core is in the cloud. Evernote has backend storage, upload, synchronization services, and user authentication and authorization services in the cloud. They also have APIs to expose all of this so most of the logic of the application is pushed to the cloud. (As a bonus, they get to expose their API to 3rd party developers who get to build on top of the Evernote API, but that is a benefit of the D+C era that we can talk about in a different blog post.) Evernote then has to build a thin client for each platform that it targets, the clients are mostly UI components that call the services and APIs in the cloud.

While Evernote chose to build native clients for each platform in order to get the richest experience and best performance, they could have chosen to have a single client written in HTML5 using JavaScript to call the back end services and APIs. This is a popular route taken by many these days due to the cross platform nature of HTML (every device these days supports HTML5+JS) and developer familiarity with HTML and JavaScript.

Native v HTML5

Building applications in the D+C era will come down to two choices: Native v Web (HTML5+JS). Each has their own advantages and disadvantages. Native gives you the most fidelity, platform flexibility, tight integration with host OS (think of status bar notifications), and the best performance. However, you have to maintain separate code bases for each device you target as well as master multiple platforms (and languages). Web/HTML5+JS gives you one code base to use across multiple platforms. HTML5+JS will give you a faster time to market. HTML5+JS is also a “one size fits all” approach, where the app may not “fit” well with the native OS. (Just look at any Web app that was built with the iPhone in mind on an Android of WP7 phone, it just feels wrong.)

I am not going to take any sides in this debate since I feel that there are needs for both approaches. Companies will weigh the pros and cons of each approach and sometimes choose to go native and sometimes choose to go HTML5. They may also choose a hybrid approach like some other popular apps have done where they have both an HTML5 application and a native application (see the Kindle and BBC news on the iPad for example.)

Developers today will find themselves working on a project that requires a Web/HTML5+JS approach and on their next project having to brush up on objective-c and Java and take a native approach. Just like if you were a developer in the late 1990s, you had to have solid Windows client/server programming skills as well as solid Web skills.

I have seen many blog posts indicating that you should forget native and only build cross platform web apps. I have seen many blog posts saying the opposite. I think both are wrong, you will have to embrace both in the D+C era. In my next post I will take a look at the state of building applications with HTML5 plus JavaScript.