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).

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.

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.

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!

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.

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.

> 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. :)

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.