Simon Brown's Blog

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

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

Comments

• 
  The good frameworks all ship meaningful sample reference applications. In general, these samples serve as good starting points, and great learning aids. You might want to start there.

  
  As an example, Spring ships sample applications primarily for three reasons: 1. as a way to illustrate specific framework features in-action, 2. to illustrate how one would implement a realistic set use cases end to end with the framework, and 3. to provide a comparsion of different implementation strategies for different situations. For example, regarding #3: Spring ships a comparsion sample, JPetstore, which compares a Struts web-tier with a Spring MVC web-tier both sharing a common Spring-powered middle-tier.

  Keith

  Posted by: kdonald on November 03, 2005 at 02:50 PM

• I know exactly how I would structure web applications, I already did it 5 years ago and it works great. (Sadly, the approach wasn't adopted at work, but I probably didn't manage to communicate the ideas at that time). It is very simple, so it can't really be built into a framework. Here's the approach:

  design a data model for your view data
  design view pages in an html editor, adding attributes to dynamic fields connecting them with the xml view of the model and specifying possible repetions (foreach xml tag)
  create a generic xsl transform that creates an xsl transform from each html page, such that the created xsl transform will add the model data (viewed as xml) in the correct places defined by the extra attributes (this is a once-off job)
  define commands/service calls for each submit/request for dynamic data.
  build your controller so that it sends commands to the correct service and applies the correct generated view transform to the results

  Hmm, maybe this could be turned into a framework after all? :-)
  This is the same as the Triangle pattern from "Bitter Java", but simpler and less abusable because the views are plain html and it uses xslt for view generation instead of JSP
  The trick of added attributes has also been used by Wicket
  

  Posted by: tobega on November 04, 2005 at 02:24 AM

• Forgot to add: the xslt that generates an xslt approach was from an article on IBM developerWorks, from somewhere around the beginning of 2000.

  Posted by: tobega on November 04, 2005 at 02:37 AM

• Some other points:

  It's a piss-easy way of doing Ajax, too, just do XmlHttpRequest instead of a form submit, and generate snippets instead of full pages.
  It is language-agnostic, heck it's not even dependent on xhtml, any xml viewing format will do, WML, SVG, we also used it with pdf templates and the acrobat form-filling xml

  I think I'll hack up a manual and swipe the generating transform I wrote and publish it. All I need is a good name for this and a logo...

  Posted by: tobega on November 04, 2005 at 03:10 AM

• I was a bit more lucky, tobega, and as I was in charge at the time I was able to implement a similar framework and we've been using at at work since 1999. The basic difference is that for us the HTML is just a prototype that we use to build the XSLT, so we generate it from zero.
  This allows us to take full advantage of the re-usability you can accomplish with XSLT, even though it means it takes more careful work to do them.
  As I said we've been using it in production since 1999 and I decided to re-open source it at java.net and document it for some users at the beginning of this year, so if you are curious you can check it out at:
  https://webleaf.dev.java.net/ and
  https://swww.uib.es/webleaf/confluence/x/-w

  Posted by: greeneyed on November 05, 2005 at 07:12 AM

• Tobega, you are using the same technology to develop web applications for 5 years? WOW! And you are not using any available framework, not event Cocoon? Wow, wow!

  This approach was great in the era of CGI/Servlets. A lot has changed since that time.

  A short list of problems with XSL I have experienced in one project (3 years ago).
  1. URLRewrite: What you do to support cookie-less sessions? In JSP world, it’s ”, in Struts, its .

  2. Internationalisation usually means one XSL file per language. Imagine the maintenance of that monster.

  3. And the most important: What do you do to integrate a third-party component into your web application? Do you redevelop them all from scratch? I’m sure your manager/client would love to hear this. ;)

  So, event if it works great for you, please, do not persuade us to adopt your 6 yeas old (since 1999) approach.

  P.S. I am really sorry for not being positive in my reply.
  

  Posted by: shevit on November 06, 2005 at 10:27 AM

• 1. URLRewrite: What you do to support cookie-less sessions?
  Well, session id is a defined value you can send to the XSL and use templates to add them to your links, not really a big deal.

  2. Internationalisation usually means one XSL file per language. Imagine the maintenance of that monster.
  If that's how you developed your applications with XSL, no wonder you did not like it. That's like saying that internationalising an application with JSPs means a JSP file per language, and equally false. I do develope internationalised applications, due to living in an area with two official languages, and never ever wrote a duplicate XSL for that. It's a no-brainer
  3.-What do you do to integrate a third-party component into your web application
  I'm not sure I understand that completely. Do you mean how does one integrate a third-party JSP tag? Well, we don't do it. The same way that people that don't use JSPs and use Tapestry or other alternative template system. On the other hand we can integrate code from various sources, like PLSQL, just producing XML without having to re-write them in Java or adding another Java layer. My manager loves that ;). So you lose something, you win something.
  In any case, I would never try to persuade anybody to use it. This framework wars about who has it bigger are quite tiring already. It works fine for us and that's all that I need. Of course it's evolved during these 6 years, but in any case even though for you "old" might sound bad, for us it has meant stable, which has quite some value for us.
  And lastly it was me, greeneyed, who wrote the 1999 and that we have been using it since then, in case you confused tobega as the author of that message.
  P.S. I'm not sure how one can feel sorry for something written :). You write it, edit it... and then you post it or you don't.. You decide to write something positive about how you like other alternatives or how you do it or not. And please don't take it as an attack, I just wanted to clarify that it was me and answer your questions, but I understant it's a solution many people don't like and that in fact it does not work for many teams.
  

  Posted by: greeneyed on November 06, 2005 at 12:16 PM

• 
  1. URLRewrite is not equal to simply adding JSESSIONID. It is also used for other purposes, like application context substitution for portals, URL encryption filters, etc..

  2. No, I maintained an XSL per language application 3 years ago, developped by another company.

  3. I was not cear. I mean that there are plenty of third party components either free or commercial. Today there are 2 main specifications on the component market: JSP(Struts, Spring MCV, etc..) and JSF. We cannot find third party components to use with XSL approach.
  

  Posted by: shevit on November 06, 2005 at 01:18 PM

• 1. Aha. Well, we usually pass the context path and even the session id to build the URLs, but we never found the need to use more complex mechanisms. If they depended on Java components then yes, you would not be able to use them from your XSLs, except using ugly hacks.
  
  2. Sorry to hear that, mantaining these kind of things can be quite a pain. But I asure you that using XSL for internationalisation is quite simple, you just need to keep a different XML per language, like using a property file per language in Java. But each tool can be used the wrong way. I've seen JSP pages that would make Freddy Krugger run away in fear! ;-).
  
  3. That's a good reason and one we were exploring as a reason to migrate, but it always left me wondering... which kind of third party components are we talking about? Automatic creation of a forms from an Object? Pagination of query results? Which kind of components do you use?

  Posted by: greeneyed on November 06, 2005 at 02:07 PM

• > which kind of third party components are we talking about?
  Any kind of UI components, From charintg components to datagrid stuff.
  http://java-source.net/open-source/jsp-tag-libraries
  http://www.jsfcentral.com/products/components/

  ActiveWidgets as a good example of a Component: http://www.activewidgets.com/
  

  Posted by: shevit on November 07, 2005 at 01:37 AM

• Thanks for the info, now I see.
  Charting components are not embedded exactly in the HTML result so they can usually be accessed by crafting the appropriate URL. Having it crafted for you is nice but not a show-stopper.

  There are some nice components there, and yes they might give you some extra's, we are still not conviced to follow that route as they are not standard and each one follows a different pattern and some do not fit with the separation we want to accomplis, but I can see that it can work.
  On the oter hand, As far as I could tell, ActiveWidgets is not related to JSP, JSF or taglibs and can simply be used from the HTML you generate, so each generation layer works for it. In fact, the "loading data from XML" would fit nicely with what we do. Good to know.

  Thanks again for clarifying. As I said we get some different benefits from using XML/XSL and so far we consider it worthy. But it is good to know there are alternatives, in case you need to do something it does not fit in your current model.

  Posted by: greeneyed on November 07, 2005 at 05:14 AM

This work is licensed under a Creative Commons License.