Comparing webapp frameworks : Why?
After posting Comparing webapp frameworks : Introduction yesterday, I got lots of feedback - some good, some bad. So, why am I doing this?
First off, here are some of the negative comments.
- Imho this is a complete waste of time and it will be another biased comparison without any real use whatshowever. Please spend your time on something useful and don't add another confusing hyped comparison to the mix.
- A propos, the easy 80% is rarely the problem and often very repetitive. Most of it is even getting totally automated with CRUD frameworks. The interesting bit is the difficult 20%, this is where the actual difficulties lie and where most time is spent.
- No one cares about how each framework handles simple things.
- If I wanted to compare frameworls your way I'd visit every one of the frameworks web sites...
- Many frameworks sell there idea demonstrating how easy it is to do simple stupid examples.
Fantastic! At least people are talking and I got some response. Great to see that the community is alive. :-)
When choosing a platform to build a web application, J2EE is still the first choice for many. As we're all well aware, new webapp frameworks are released fairly often and I believe that there's still a lot of room for innovation, particularly when you look "Beyond Java", with stuff like Ruby on Rails. So, from this perspective, one of the reasons that I'm doing this is to provide an "at a glance" view of many frameworks as opposed to going in deep on a few. After all, I want to be in a position to answer questions like, "do you think we should use Struts or something newer like Stripes?". I suspect that most people would comment that both are webapp frameworks, but recommend Struts because it's proven. I could be wrong, but I do think that even an "at a glance" view offers something of value.
Nobody cares about the simple stuff
Taking on the comment about the 80% being easy and repetitive - yes, that's exactly what I was getting at. It is easy, or at least it should be. That's something else that I want to look into. If a particular framework makes the easy stuff hard, I'm not going to recommend it to my clients. Where's the productivity gain in slowing 80% down but making 20% really fast? True, some of the easy stuff can be automated with CRUD style webapp frameworks, but this isn't necessarily the world we live in. Just taking an example, one of my current clients is building a web presence over the top of a service oriented architecture, which is deployed on an enterprise service bus. How do those CRUD frameworks help me here?
Consistency and reduced learning curve
Why should I have to compare frameworks by visiting each and every website? They all differ in terms of content, layout, documentation, examples, etc. By implementing even a simple application, I can reduce the learning curve for those people that just want to quickly skim the frameworks and pick up the main points. This is made even easier if the code for the same application is available for multiple frameworks.
The other thing to pick up on here is that some of the framework sites do have incredibly simple examples. They're even simpler than the application I've come up with and that's a problem. Once you stray outside of the simple example you have to start digging around the docs. If I can at least go slightly deeper than the very simple examples, again, I think this adds value.
The evolution of web MVC
Another reason for doing this is to see how the web MVC pattern has evolved over the past few years. I don't want to jump ahead too much, but there are some very interesting and unique ways that this seemingly simple pattern has been implemented. I want to compare and contrast this too. Coupled with the view technologies, I want to see how these various choices affect what is ultimately the core architecture of your web application.
Just to clarify, my sample application is read-only from the perspective of the user. The content is dynamic, but the user can't update it. As I said, I am hoping to make this an iterative process and revisit it to add further levels of detail. I've got to start somewhere though. ;-)