Web applications vs. Web sites, Ruby on Rails and points in between

Ruby on Rails is rightfully gaining traction and respect right along with a rapidly growing developer community. This, due to its being the near-perfect match for developing its `home-turf’ software: database backed web site. However, as pleased as I am with RoR’s success, I’m beginning to note with apprehension as it is increasingly being used for writing the kind of software it is not meant for.

It is not unlike the early Java-rush years in which every tiny in-house web-application seemed to some misguided souls like a nail aching for the punch of the overweight EJB hammer.

Rails development scales very well, so if you are developing a web-site, you’re in for a pleasant surprise using it. Whether you develop alone or with many team members, whether you deploy for ten concurrent users or ten-thousand, Rails is definitely the right tool for the job. But if you are developing something more state heavy, such as a web-application, then you are in for a nasty headache when your code goes O(spaghetti^2).

Rails is a great tool for what it does, but when you’re writing software that translates to a different architecture than a thin-state web-site (as rich an experience as it may be!) using Rails will be like trying to fit a square peg into a round hole (when the cliche fits…)

Web site/app, what’s the difference?
The difference between the two boils down to the number and complexity of the states of the software… …Huh?

Let us demonstrate: A good example for a web-site is IMDb, it aggregates information about movies from various sources including other users. Another example for a web-site is OkCupid.com which allow online matchmaking and interactions between users. Contrast this with a web-application such as Google Spreadsheets which is pretty much a hosted version of Excel + collaboration. Another example for a web-application (although one that is smaller in scale) is an application which allows you to control your home automation remotely via a web browser.

What is a web site?
A classic web-site is a thin view layer unto an expansive schema which is modeled and stored in a database. The use-cases it implements are shallow on their own right but their aggregate creates an experience which is much larger than the sum of its flows.

The main draw of a web-site are the users– you are not interacting with the software alone, you are part of a grander ‘community’ (as much as this word brings a bitter taste to my mouth at times)– While using a web-site you become part of the network and as a user you give value back to the site by interacting. This is the ‘Web 2.0′ vision, a painful buzzword on its own.

Web 2.0-type sites are absolutely ideal candidates for Ruby on Rails and as such there are many success stories to be observed. I’ll skip the bother of listing them, go to RubyOnRails.org and scroll down, I’m sure you’ll recognize some of the leading neuvo-web sites.

Now, seeing these successes described in IT Weakly (ha-ha) your average Joe IT Manager figures, ‘Hey! This Rails thing does web sites good! We have an in-house application to plan our customers’ parties which we need to upgrade, so let us rewrite it as a web-application using Rails!’

Gulp! Ding! Big Whoop! No good!

Why?

Because web applications and web sites are not the same thing… Joe IT is going to use Rails for something it is not meant for and actually quite weak for.

Web-Applications, a primer
To understand what web-applications in a deeper sense, consider the expression itself– it is naught but the well worn word ‘application’ with ‘web’ tacked in front. So a web application is simply an application that runs on the web as its platform of choice.

A desktop application’s experience is one of the user vs. The Software. Perhaps a limited remote resource is utilized, such as a query to the Party Supplies Database for the benefit of the purchase order printing screen but other then that– it is the user alone who calls the shots.

You can create deep, stateful use-cases that involve selecting a venue for the party and setting up the table locations and seating arrangements. It doesn’t matter if the experience of using this piece of software is immersive or merely tangential but the main point is that does not involve anyone else but the user himself along with the rich client experience (ah… Buzzwords). There’s a heavy statefulness to applications that doesn’t exist in web-sites.

The Thin Line
AJAX, another aspect of the Web 2.0 paradigm, is bridging the gap between the richness of a desktop application and that of one set on the web. It is also bringing more modal interaction to web-sites. But as thin as the line is, it is still there. And where it is most noticeable is the amount of statefulness of the software.

In a web site the state is maintained in these locations: The URL, the session and the database. You can consider them the short-term, mid-term and long-term memory of the software. For brevity, I’ll refer to any information which is kept client-side and travels back from the user as the URL, although it may be sent to the server in other parts of the HTTP request (such as forms).

To scale a web-site well, as little state as possible should be maintained in the session (for clustering purposes) and yet the cost of a DB call is also prohibitive so it is best for UI state to be contained in the URL as much as can possibly be managed, while taking care to never trust the user-sent data and to avoid assuming that he will ever traverse the flow chain as expected.

This leaves very, very little place for statefulness in web sites and it is the main reasons why web sites have shorter, shallower flows than do applications.

Don’t get me wrong– web-sites may have a rich UI. We are all immersed in the latest trend of enriching web-sites’ UI by creating a more responsive UI using AJAX.

The list that updates without a page refresh, a popup dialog for selecting your state or the modal window which display the clicked-upon photograph, these are just a few of the examples we see daily– but all this adds nothing to the statefulness of the site — it doesn’t turn it into an application and it shouldn’t!

Rails is ideal for developing web-sites because it deals very well with interpreting the current state from both sources (URL –> ActionPack, database -> ActiveRecord) and churning out a view for it. The second you add more statefulness, it gets painful.

Words of Wisdom
I speak from experience— I learned this painful truth about Rails the hard way by trying (and actually succeeding, through painfully so) to create a rich-flow application with Rails. This application should have been a desktop application by all rights, but seeing as I had recently acquired a hammer, I just had to use it to beat the screw in…

This application’s model was simple enough, but the user flow involved the use of resources on the PC itself (the DVD drive, in this case) making it utterly befitting a desktop application, and less so for a web-app… Blinded as I was by the ease of writing web-sites with Rails, I ignored my own red-lights flashing and went ahead anyway. It turned out well enough, but taught me hard lessons about what Rails makes easy and what it makes hard.

Statefulness…Blissfulness?
There are frameworks out there which fit a state-rich AJAX web-application much more than Rails. There are many examples and I would not want to mention one for fear of the flames, but feel free to suggest yours in the comments below.

Technorati tags: , , ,