Web applications vs. Web sites, Ruby on Rails and points in between
July 16th, 2006
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: Ruby on Rails, Development, Software, Web 2.0
June 6th, 2007 at 10:03 am
Well said and thanks for sharing!
I’ve heard a couple of people now who used RoR for non-trivial web applications and concluded it wasn’t the right tool for that.
June 6th, 2007 at 10:16 am
Thanks for commenting!
By the way, I’ve been seeing and hearing good things about Seaside [http://www.seaside.st/], Avi Bryant’s web-application framework. It is build for state-heavy rich web-applications. Check out the DabbleDB demo [http://dabbledb.com/explore/7minutedemo/].
June 6th, 2007 at 11:20 am
Yeah, Seaside is nice, though you’d have to buy into Smalltalk first. For Java, the thing that comes closest to seaside is Rife [http://rifers.org/], which also works with continuations.
As for statefullness, it’s one of the core ideas behind Wicket [http://incubator.apache.org/wicket/] as well. I always found it amazing that people can rave about object orientation, but then settle for a ’stateless’ web development, which in effect pushes you into a procedural programming model.
To be complete, Google Web Toolkit also provides a stateful programming model. It’s Ajax all the way though, which may or may not work for you.
June 6th, 2007 at 11:48 am
Do you know of a good event-based framework for Ruby?
June 6th, 2007 at 12:17 pm
Nope. It could use one I guess.
I’m using Ruby for sysadmin stuff, and it’s very nice for that, but it’s not on my list to use for anything other than that. I’ve simply heard too many stories of Rails projects gone wrong when complexity kicked in (larger teams, more complex user interfaces, etc), largely because of the lack of static typing, code duplication (due to lack of fine grained reuse) and the spaghetti code you’ll end up with page scripting unless you’re very, very disciplined.
June 6th, 2007 at 1:33 pm
I disagree with all of your points regarding RoR and complexity. I’ll elaborate:
*. Lack of static typing does not matter if you are doing test-driven development correctly.
*. Code duplication? Ruby allows you very fine grained re-use, could you give an example of what you mean?
*. Spaghetti code can occur even in the most standard EJB application, the same type of discipline is required, no matter the language.
June 6th, 2007 at 5:28 pm
:) Note that in my reply I mentioned the complaints of other people who did real projects with Rails. Maybe they didn’t get it, but the experience for them was enough to ditch Rails for larger projects. Anyway, I can imagine their griefs, and I’ll comment below.
> Lack of static typing does not matter if you are doing test-driven development correctly.
I can follow that you catch and pinpoint errors quickly if you write lots of fine grained unit tests. In the same fashion, I can turn off my spellchecker hoping that my editor will catch all the mistakes. ;) Seriously, there’s lots of debate on whether static typing is a good thing, and I’m still convinced it is, though I understand not everyone agrees.
> Code duplication? Ruby allows you very fine grained re-use
Yeah, Ruby does a great job at that. Rails however doesn’t afaik. Not in the sense that you can develop a component like a class with all it’s resources bundled, which you can drop in to any application, any context, without a single line of configuration. Something that *is* possible with most desktop frameworks, and frameworks like GWT or Wicket.
> Spaghetti code can occur even in the most standard EJB application
EJBs, like most of what people consider to be the typical J(2)EE stack, are horrible. If I’d have to develop using that, I wouldn’t be doing Java now. Fortunately, there’s a lot of choice.
Anyway, there are definitively things you can do to limit potential damage people can inflict on themselves. In general: defensive programming. A good strategy for keeping the user interface code manageable is to keep the raw presentation and the logic that works on it (to fill in the dynamic parts) stricly seperated. It’s certainly not a new idea – e.g. tag libraries for JSPs (which unfortunately was too little, too late) – were introduced for this purpose, but it seems not everyone is convinced about the advantages (but read for instance http://www.amazon.com/Building-Scalable-Web-Sites-applications/dp/0596102356 – the author, the lead dev of Flickr, makes an excellent point of seperating these different layers of the UI).
All my 2c of course. I’m definitively not a Ruby nor a Rails hater; I think it’s great that people don’t take the whole J(2)EE stack for granted anymore, and Rails probably played a big role in that. However, I still think there’s a lot of good stuff in Java (like Wicket), and I need a lot of convincing before I’d be ready to give that all up. :)
June 7th, 2007 at 11:54 am
My original question was regarding a framework for Ruby, not for Rails, but never mind.
I’ll still like an explanation on how Rails doesn’t allow you code re-use? Rails plug-ins are a great way to do code-reuse between applications both of whole components and pieces of functionality.
June 7th, 2007 at 2:22 pm
> My original question was regarding a framework for Ruby, not for Rails, but never mind.
Yeah. Sorry for having us ending up there.
> I’ll still like an explanation on how Rails doesn’t allow you code re-use? Rails plug-ins are a great way to do code-reuse between applications both of whole components and pieces of functionality.
Well, first let me say that I’m not a Rails expert; I’m judging Rails from what I’ve read and how I expect the framework to work. So please correct me if you think I’m talking rubbish.
Concerning reusable components… Take for example a panel with a search form and a pageable results list. Keeps track of it’s own state (like the currently selected results page, the search argument and the sorting) and uses it’s own resources like localized texts, images and style sheets etc. As a user, I want to be able to drop that in any page, and the only thing I want to need to know about this is the exposed API (for configuration). Whatever page/ context I drop this in, no matter how many instances, the thing should just work.
This stuff is natural in desktop application frameworks, but unfortunately, very rarely supported in web app frameworks. And *if* it is supported – though usually without ’state’ -, you typically still need all sorts of configuration (like configuring the paths of the resources the component depends upon).
To come back to the original question: nope, I don’t know such a framework for Ruby, but I think it would be a gain for those who like to use Ruby for developing web apps. That is because I am convinced that the advantages of a real object oriented programming model are as true in the web tier as they are in the other layers of our applications.
June 7th, 2007 at 2:58 pm
> To come back to the original question: nope, I don’t know such a framework for Ruby, but I think it would be a gain for those who like to use Ruby for developing web apps. That is because I am convinced that the advantages of a real object oriented programming model are as true in the web tier as they are in the other layers of our applications.
I agree with that whole heartedly. The debate rages on however if heavy-state web-apps can scale to web-site traffic.
> Concerning reusable components… Take for example a panel with a search form and a pageable results list. Keeps track of it’s own state (like the currently selected results page, the search argument and the sorting) and uses it’s own resources like localized texts, images and style sheets etc. As a user, I want to be able to drop that in any page, and the only thing I want to need to know about this is the exposed API (for configuration). Whatever page/ context I drop this in, no matter how many instances, the thing should just work.
This is not easily possible in Rails even when not re-usable. In essence this is why I’m looking for a framework which does ;-)
This is a healthy discussion in any case, thanks!
June 7th, 2007 at 3:37 pm
> The debate rages on however if heavy-state web-apps can scale to web-site traffic.
Yep. And much of that is simply premature optimization imho. If you look at Wicket, a typical session will cost between 20kb and 80kb in my experience. Make that 100kb. That means you can serve 10,000 concurrent sessions on one 1GB of memory, which can easily be fitted in one box. I doubt your processor etc are gonna hold that.
Now, I’m not saying server state is always ok. There are sites out there for which that would create a bottleneck – you’d need session affinity, which limits your choices in load balancing, and moving state around the cluster can get expensive. And if you’re operating on the scale of Google, such inefficiencies will hurt. However, how many people actually are building sites for millions of potential *concurrent* sessions? Or even hundreds of thousands? I think we can safely say the majority of the web applications being build today – certainly all those that run on intranets – do not have such extreme scaling requirements.
Bottom line is that every serious software engineer should make the calculations (what kind of traffic do you expect, what kind of fail over strategy do you need, etc). Pick the right tools for the job, and don’t blindly follow the ‘wisdom’ of others (look at what that brought us with those EJBs). Weigh how much extra you’ll pay for the hardware opposed to paying extra for development (especially where the larger part of the cost is: maintenance!). And finally, just to be selfish, I’m spending the larger part of my awake hours writing software. I want a programming model that doesn’t suck!
> This is a healthy discussion in any case, thanks!
The pleasure has been all mine.
June 7th, 2007 at 3:41 pm
Sorry, one final thing about Wicket is that Wicket, though being a stateful framework, supports stateless pages (and forms and links etc) as an optimization.
June 7th, 2007 at 4:53 pm
Its good to hear that Wicket allows such a balance. As indicated in the post above, I believe that a rich user experience does must mean something state heavy in the server.
For example, if the user refreshes a page, it is important to maintain the state of items selected in the list box while the scrollbar’s position is not as important.
June 8th, 2007 at 1:57 am
> I believe that a rich user experience does must mean something state heavy in the server
If you use Google Web Toolkit, you don’t need any state on the server. But that runs more like an applet, and has other trade offs (which I won’t get into here).