Guest post by Jason Miller, my co-founder at Carbyn and an absolute engineering whiz. You can follow Jason at @_developit.
When Jaafer asked me to start pouring my tech savvy into a post I started thinking about what would make a great read; something that sticks to the purpose of this blog which is to provide objective free-wheeling thoughts and knowledge, mixed with some humor and maybe even little controversy (after all not everyone will agree with everything I or Jaafer say (even though everyone should!)). So, I decided to write about something that’s becoming an increasingly hot topic in the web/mobile community and has come to be a part of my everyday work (and thoughts)….and something that is effecting web and mobile users every single day.
What’s the difference between a web app and a web site; what differentiates these two seemingly similar but in realty very different entities?
Is Twitter.com a web app? Yes. Is this website a web app? No. Is Gmail a web app? That one is debatable, but yes. What even defines an online resource as being an “app” instead of a “site”? I think the most definitive answer is that web apps transfer presentation separately from data, and do not employ a strict request-response technique for doing so.
Your users called, they want their time back.
Users care about speed, functionality (therein usefulness) and ease-of use. As developers, we can draw rather direct parallels to the technical aspects of web development from these general requirements. For speed, and since this is the web, we’re talking almost exclusively about speed of data transfer (requests take much longer to transfer than to execute on the server). Functionality is created by selecting the most effective set of features for an application (more is not always better). Ease-of-use is important in web apps because we are still collectively helping computer users to adopt a new way of thinking about applications – if a user’s first web-based application experience is horrible, they will most likely avoid using web-based software in the future.
So.. why classify “apps” and “sites” based on what the data looks like?
Users care about speed, and we know speed is most affected by data transfer time, so that’s where we can draw a clear line between the “old” and “new” approaches. A website transfers data and formatting via a single request, which is optimal when loading new pages is the primary means of retrieving new data. A web app transfers formatting and presentation information as part of an initial download process, much like downloading a desktop application. Once this information has been stored, data is then downloaded in a serialized format – optimized for speed in a situation where page loads don’t occur. Examining the data being transferred makes it easy to determine which paradigm something is optimized for. Simply look to sites like Facebook and Twitter, where you can see an evolution in the direction of “web app” for no reason other than to provide a better experience to users.
Doesn’t that mean everything should be an app?
You’re not getting the point – that would be premature optimization at its finest. If you are establishing a web presence for a business, where your needs are little more than an online business card or simple e-commerce site, don’t build an app. Your time would be better spent working with the client to optimize their site for Search Engines or creating PPC landing pages. However, it would certainly be beneficial to apply lessons learned from the world of web apps to your website – things like HTML5’s ApplicationCache and AJAX history can go a long way to improve user experience. A general rule-of-thumb is this: if your project is web-based, data-driven and is its own product, a web app would be a wise choice.
So, there you have it. Apps, both web and native, have an initial download followed by speedy data transfer. Sites throw everything into a pile and download formatting intermixed with data.