There is no "best" web framework
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Matt Stine replied on Wed, 2008/02/06 - 5:16pm
Steven Devijver replied on Wed, 2008/02/06 - 5:19pm
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
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 www.romaframework.org idea.
bye,
Lvc@
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
smith hou replied on Mon, 2009/09/07 - 11:33pm
why i feel hard always? but thank your help
christian louboutin