Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others. Matt is a DZone MVB and is not an employee of DZone and has posted 149 posts at DZone. You can read more from them at their website. View Full User Profile

There is no "best" web framework

  • submit to reddit

From Mike Clark's blog, I learned about a number of TED Talks. As a fan of Malcom Gladwell, I was drawn to What we can learn from spaghetti sauce. In this talk, he talks about the research that Howard Moskowitz did for spaghetti sauce and how it changed the food industry forever. Here's a couple of quotes I wrote down:

"When we pursue universal principles in food, we aren't just making an error, we are actually doing ourselves a massive disservice."
"The difference between coffee at 60 (% satisfied) and coffee at 78 is the difference between coffee that makes you wince and coffee that makes you deliriously happy."
In embracing the diversity of human beings, we will find a sure way to true happiness.

Can this thinking be applied to web frameworks as well? What if it's not about choosing the best framework for your type of application? What if it's all personality related?

What if there's types of developers that really like the Wicket Way, there's others that love Tapestry and others that think Rails/Grails is the bees' knees? Oh yeah, there is. It's entirely possible that one developer can be extremely productive in Tapestry and another one can be just as productive with Spring MVC - isn't it?

If you listen to Gladwell and believe Moskowitz's research - wouldn't you be doing a huge disservice to other developers by trying to get them to use a framework they don't like? If they don't like it, that's OK. Different people think in different ways and some frameworks may be easier to grasp for a certain personality type.

What do you think? It seems entirely possible to me.

Published at DZone with permission of Matt Raible, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Matt Stine replied on Wed, 2008/02/06 - 5:16pm

I'm all over this way of thinking Matt. Having worked with multiple web frameworks in the last few years (JSF, Struts 2/Webwork, Grails, Rails, Spring MVC), I've found that they all have their sweet spots, both from a domain perspective and a developer perspective. One thing that I've really enjoyed is that having exposed myself to the different ideas behind each of these frameworks has helped me to write better code within projects using OTHER frameworks. Almost everybody has something good to bring to the table, and many of those good ideas are "cross-cutting," so to speak.

Steven Devijver replied on Wed, 2008/02/06 - 5:19pm

I really liked the spaghetti sauce talk. There are so many excellent TED talks, it's days worth of entertainment.

Ben replied on Wed, 2008/02/06 - 6:07pm

Makes sense -- it would explain why so many web frameworks are less about the technology than the cult of personality around the lead developer (Tapestry, Rails, etc.) It would also explain the vast proliferation of frameworks that all function more or less the same way.

It amuses me that we may have reached the point in this well-worn area where it becomes about personality instead of technical merit.

Ignacio Coloma replied on Thu, 2008/02/07 - 5:36am

It makes some sense to me, since many frameworks are approximately equivalent.

People with experience in more than one or two frameworks are scarce. Since there is not enough time to assimilate the wealth of information, you select one with a big enough user community and stick to it. Learning another framework which does not have reported enormous productivity gains is not worth the effort. Imperfect knowledge, as applied to software economics.

There is a funny lesson about ecosystems I learned like ten years ago: if you leave a superior species inside an ecosystem (say, a lion in Australia), it may get a bigger share but the other species will not disappear. Call it imperfect knowledge, ecological niche, whatever.

For now, I think people who is happy enough will not try other options. They do not get payed for it. And the first try (and this is the important thing) is driven by personal taste.

Robert Diana replied on Thu, 2008/02/07 - 7:37am

I have been saying this kind of thing for years. For each project and person there is the potential for a different framework or even programming language that "should" be used. I have been having the Spring/Struts/Any other MVC debate lately, and still nobody wants to agree. It really all depends on what the developers feel is the best one to use. If Struts is more "comfortable" for the developers, then use it regardless of whether the experts say Spring is better.

Jose Maria Arranz replied on Thu, 2008/02/07 - 9:03am


I think is very very interesting to have several “coding/development styles” because the development style selected has a strong influence in your web application architecture.

There are many frameworks but not so many development styles. I like to classify web frameworks in these categories (frameworks cited are examples, this is not an exhaustive list, DWR = DWR + some JavaScript framework):

* Client/JavaScript centric (including JavaScript pushed from server): GWT, DWR.

* Server centric: JSF, Wicket, Echo2, wingS, Tapestry, ItsNat

* Custom tags based (HTML generated by the framework)/XML declarative programming (using expression languages etc): JSF, Struts (tons of similar frameworks), Tapestry.

* View built programmatically: GWT, Echo2, wingS...

* Pure HTML templates, components attached to the HTML using Java: Wicket, ItsNat.

* Page centric: JSF, Struts, Wicket...

* XML based navigation and bindings: JSF, Struts

* Component based: all except Struts.

* Focused to desktop-like web applications / initial page based on JavaScript (the browser receives the markup embedded in JavaScript (JS builds the page): IT Mill, GWT, DWR, Echo2, wingS, Eclipse RAP, Tapestry(?)

* Not so focused to desktop-like app. (web site centric and search engines friendly) / initial page based on HTML (the browser receives serialized HTML): JSF, Struts, Wicket, ItsNat, Tapestry(?)

* AJAX based components: JSF enriched, Wicket enriched, GWT, Echo2, wingS, DWR, ItsNat.

* COMET/long polling built-in: IceFaces, ItsNat

* Remote views of other users/pages: ItsNat

* Server-sent events: ItsNat

* Functional web testing built-in using the browser: ItsNat

Note: Tapestry is not clear because is integrated with Dojo, Dojo is for me in the "Initial page based on JavaScript" category.

For instance, if you don’t like custom tags and view built programmatically, that is to say, you want pure HTML templates, you only have two options: Wicket and ItsNat, and if you are strongly focused on AJAX, you only have one option… ItsNat.

Disclaimer: I’m the author of ItsNat


Frank Silbermann replied on Thu, 2008/02/07 - 11:46am in response to: Jose Maria Arranz

It's probably true, and suggests that we need to do a better job identifying the kind of programmer who benefits most from each framework.

For example, Wicket most benefits the type of programmer who like using object orientation (encapsulation, inheritance, and polymorphism) to achieve code re-use and minimize redundancy.  People who don't understand encapsulation, inheritance and polymorphis -- people who don't strive to achieve code re-use and minimize redundancy (and there are quite a few such programmers) -- will probably be better served with something else.

Of course, you could argue that one who understands object orientation (encapsulation, inheritance, and polymorphism) and uses them to minimize redundancy and achieve code reuse is, given todays programming languages, the best kind of programmer (and the kind we all should be or strive to become).  But that's a different issue.


JeffS replied on Thu, 2008/02/07 - 3:58pm

It's all fine and good to say that different web frameworks fit different personality types, and are thus better suited to different types of developers.

 But the reality is that the management or project lead of any given shop will typically choose a particular framework, for a vairiety of reasons.  Then the developers who are currently at that shop, or ones who are hired after the choice, have to use that particular framework, regardless of how it fits their "personality".

 The diversity also can make it tough for developers with experience in frameworks A, B and C, to get jobs at shops that use framework X, Y, or Z.   Enlightened project leads are smart enough to know that a developer with Struts experience can probably get up to speed fairly quickly with a JSF, Tapestry, or Spring MVC (or whatever) project.  But, too often hiring is done or heavily influenced by ignorant recruiters, non technical management, or laundry list following personnel staff.

 Another drawback to all of that diversity and choice in frameworks is the time it takes to learn and evaluate them.   In the time it takes a team of Java developers to evaluate and argue over which framework to use, the equivalent ASP.Net, RoR, PHP, etc. team/developers are already (largely) done.  They can just "get on with it", and complete something that "works well enough".

Luca Garulli replied on Fri, 2008/02/08 - 3:54am

This is the reason because we need a META framework to abstract the most of tools and frameworks in order to save the application code against the "Yet Another Framework" and to avoid to start learning from ground everytime!

Take a look to idea.



Rainer Eschen replied on Fri, 2008/02/15 - 2:12am

Everybody is doing the framework she likes to do? Nice idea. Good start for effective results based on 100% motivation. But, for this I need 100% integration for all combinations that result from this. My experience show me that everybody out there writes a Web framework, tries to create a huge community to get momentum, but integration with existing frameworks is the last step, that is done by framework users, not the developers. So, costs to get all this together in a project are too high. Although, I don't know if this is the worst way for maintenance ;-). 

Springsteam Blog - Next Generation Java Development

Jose Maria Arranz replied on Fri, 2008/02/15 - 3:34am in response to: Rainer Eschen

 I think a framework must be focused to some specialization area, for instance a web framework must be ONLY related to web, a web framework must be orthogonal to persistence, messaging etc. Of course there are frameworks coupling several services for instance Seam and Rails, they are fine for quick development but I think coupling is a bad thing in the long term and limits your freedom.

I like very much the phrase of the venerable B. Stroustrup

"Independent concepts should be independently represented and should be combined only when needed. Otherwise unrelated concepts are bundled together or unnecessary dependencies are created"

Why a web framework must be coupled with persistency? JDBC, JDO, JPA, iBatis, EJB, file system, custom APIs of pure ODBMSs, XML databases, exoteric databases.... too many options.

 If a web framework is well designed will be easy to combine with your preferred persistence framework (for instance), any decent web framework offers some kind of join points into its lifecycle (for instance event listeners).


Rainer Eschen replied on Wed, 2008/02/20 - 6:18pm

Seems to be a historical problem to me. The first implementations tried to solve problems in every layer of the architecture. I agree that we need layer-specific frameworks, but integration problems still let us suffer.

smith hou replied on Mon, 2009/09/07 - 11:33pm

why i feel hard always? but thank your help

christian louboutin


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.