Tuesday, April 8, 2008

Battle of the Web Application Frameworks

I recently spoke at the Emerging Technologies conference in Philadelphia. It's a great and growing conference that boasts low registration costs and high-value. I'd say perhaps 75% of the sessions are very informative. Most of the attendees I spoke with were psyched about the content of the sessions. If you get the chance, I highly recommend attending next year's event.

On the topic of my own session, I am glad to say that I "spoke", rather than shouted, screamed or threw chairs. While I am, of course, being slightly tongue in cheek, my speaking was a part of a panel that billed itself as a "main event" of sorts. People definitely came looking for blood. No blood was spilt, but the tenor was clearly up tempo, and the language sprinkled with color ( i.e. F-bombs ). I won't name names, but, apparently, the conference is going to publish a video or audio on their website.

After particpating in this panel, and, more importantly, spending a couple of days chatting with my fellow panelists about their various frameworks ( Seam, RoR, Struts 2, Open Laszlo, JQuery, Flex, etc. ), I realized a couple of obvious things about this whole "battle of the frameworks" concept. First of all, as far as the web application frameworks go ( we'll leave the rich client frameworks for another day ), while there are clearly differences between the frameworks, I'm convinced that, in a nutshell, they are pretty much all good choices.

I'm not saying that your choice doesn't matter, it does. But not in the way that people seem to expect. It would be nice to just say that one of them is the best and be done with it, but, unfortunately, it's not that simple. Let's take the Convention over Configuration issue as an example. Ruby on Rails has certainly made CoC popular. When I talk to developers on the street, rapid development time is what they always rave about. They want to talk about how fast they can build a web application. And that's about all they want talk about. I won't even go into the old school complaints about any sort of code generation ( a.k.a. scaffolding ), but I will skip on to the easier point that, in reality, all new frameworks, taking the lead of projects like RoR and Maven, will all boast high levels of CoC.

Struts 2, for instance, now sports a zero configuration mechanism which is basically the Struts 2 version of CoC. Combining that with the Struts 2 Spring and Hibernate integration provides you with high levels of CoC and a full stack. In other words, you can build an application, providing it follows the straight and narrow, in a very small amount of hours. Whoo hoo! This is in some ways very exciting and lots of people want to know about it. I'm planning to do a tutorial on Struts 2's zero configuration stuff in the near future. Keep your eyes out for that.

I don't want to go into more details about CoC, and only raise it to make the point that any recently minted framework, that has an active community of smart developers, will have absorbed the latest and greatest ideas of the domain. After the success of RoR, you're not going to find any new frameworks that don't support high levels of CoC. I'm afraid that this means that choosing a framework is just plain hard work. You'll probably have to investigate your options to the point of doing a bit of actual development on them.

But lot's of people liked the Battle of the Frameworks and said it was very helpful. I'll relate what I think was the most interesting sound byte. For me, I was just interested to here how the insiders themselves express the differences. Most of the heat was about RoR, not surprisingly, and they claim to have the best framework for *smart* developers. They believe that this is the halmark of their framework. Kind of like the "Ruby allows smart people to better express their smartness" argument. This is probably true ( though, not being all that smart or Ruby-fied, I can neither confirm nor deny it), but it certainly has a bit of the meta-physical cast to it.

Ultimately, I was just flat interested in the Ruby community's choice of this aspect, rather than the high speed dev time, as the best feature of their framework. They don't really boast about the rapid development time. There was even some suggestion that they don't like the way this particular aspect of the framework draws in the *wrong* crowd. This is very interesting actually. I'll have another post, as soon as I can do the research, on the "Rails Ghetto". A very interesting concept.

Those against RoR make accusations about performance. Search the web for Twitter and performance issues, you'll see what they are talking about. To me, this seems a rather foregone conclusion. The newer framework will always be vulnerable to performance issues. RoR has rolled their own persistence layer and web server, afterall. How could they not have an issue or two? Nonetheless, I would suspect that as long as the RoR community stays as active as it is, and filled with bright folks, these issues will go away.

Struts 2 gets accuses of being old. Well, what did you expect them to say? This is, however, patently untrue. As I've indicated, Struts 2 is a brand new framework that was recently born so it incorporates all the new stuff -- CoC, annotations and the like. Struts 2, speaking for itself, makes claims to being a better engineered piece of software. I personally think this is accurate ( I'm not a Struts committer and I wrote a book on Struts 2; this gives me both objectivity and insight, I would hope ). When pimping Struts 2, I always say that I think it's hallmark is the elgance and flexibility of its architecture. If something like the next Ajax comes along, which it will, and makes new demands of frameworks, I'm confident that Struts 2 will be able to respond with speed and grace. This is what you get from software engineering. Admittedly, this is not as sexy as CoC, but there's that too, if you like ;)

3 comments:

mstittle said...

the problem I have with struts 2 is the documentation which i find to be rather sparse and lacking examples. I had the same opinion of webwork which I know struts 2 is based on. I had an application that originally written in webwork. I've since converted it to struts 2. I'm interested in some concrete examples of how to do security/roles in struts 2. I just ordered the struts 2 in action book. Hopefully that will resolve my concerns :)

chadmichael said...

We show how to do application controlled security, but that's not really a recommended practice. We just use it because it serves as a good example.

What kind of security are you interested in? Sounds like you are looking for container based security?

mstittle said...

I was considering using Acegi. Not sure if that requires using spring as well or not. Would like to disable access to selective pages based on role and maybe disable certain actions on a page by role (like delete).