What Would You Ask the Web Framework Experts?
At the end of this month, I'll be moderating a Java Web Framework Smackdown at TheServerSide Java Symposium in Las Vegas.
The following frameworks will be represented on this panel (+ possibly a few more if there's additional framework experts at the show):
* Struts 2
* Spring MVC
* Grails
* JRuby on Rails
* Seam/JSF
* Wicket
I suspect we may get folks representing GWT and Flex as well.
If you had an opportunity to be in the audience of this panel, what question(s) would you ask?
If you'd rather answer this question on Javalobby, I've posted this question there as well:
http://java.dzone.com/news/what-would-you-ask-web-framewo
Answers (10)
Why can't we, the java community, come together and adopt the best application framework and settle the web development subject? I think that a team lead or architect could choose a framework, hire a team, and there still could be disagreements among team members. This is a problem. Probably Grails is the closest to Rails, but if we could solve a few complex object relationship choices, AppFuse could be a real contender using Struts. The framework should be more than just an MVC model. It should quickly do the job and generate code for us. There should be no questions about servlet controllers, page flow, validation methods, ajax use, custom components, etc. We should just write web applications and solve bigger problems. But, this means standardization. Or, it may mean who's most productive and profitable. For me personally, I like selling my opinions. I like AppFuse and I like Struts. I like Rails but it's not Java. That's the only reason why I'm not fond of Grails. AppFuse and Struts get's my vote.
I wish there were one application (not just web) framework and everyone agreed it was the best. It should be simple to use and quick to learn.
Back to my question, what can we do to get Java folks to kick it up a notch and adopt an application framework and settle on a single controller, model, and view solution? E.g. I could get a Hibernate and Spring tatoo with no regrets. I wrote a post on jroller and our Arizona buddy sent me a link to look at a new framework called Crank. I've found my solution I think and it would AppFuse and Struts.
Clarification added March 6, 2008:
would (+be correction) AppFuse.
Use the process of egglimination.
#1 Give each panel member a single egg.
#2 Ask the question: "Who sucks the most?"
#3 Most egg covered is voted off the panel (cumulative).
#4 Goto #1 unless only one panel member remains.
#5 Last remaining panel member wins a shower.
Don't forget Stripes and Tapestry! And YouTube it for the rest of us who won't be there.
Cheers,
Clinton
Clarification added March 6, 2008:
This isn't a clarification, but a response to Tina's great suggestions. So, since Linked In seemingly doesn't have any other way for me to respond here (or I'm blind)...
I think Tina makes a good point about building a decision tree is excellent. Although I don't think it could be a tree, but more likely a matrix, possibly modeled after a Kepner Tregoe decision matrix (http://tinyurl.com/ysp9tr).
For me, the first distinction I make between frameworks is the separation fo Component based frameworks and Action based frameworks.
Component frameworks generally try to break things up into reusable components or widgets, and will often try to hide HTTP behind a more traditional rich client like GUI API.
Action based frameworks (a.k.a. Page or Template frameworks) will generally have a single method per request that either renders content directly, or delegates to a page level view. Action based frameworks achieve some level of reuse with includes and templates.
The lines may be blurry for some of them, as many (most?) are capable of both. I think the idiomatic usage of each is generally swayed one way or the other. For example, here's how I divide them up:
Action (Page/Template)
* Struts 2
* Spring MVC
* Grails
* JRuby on Rails
* Stripes
Component
* GWT
* Flex
* Most/all RIA Ajax toolkits
* Seam/JSF
* Wicket
* Tapestry
I'm heavily biased towards the action based frameworks and tend to avoid the component based frameworks for all but business form type applications that are only meant for internal consumption within an organization. My reasons would probably take twice as much space as I've already taken...
So I'll end on that and leave others to fill in the rest of the tree/matrix/cube.
Cheers,
Clinton
Tina C
Smart and Gets Things Done with Teams in Software Systems Development.
Best Answers in: Career Management (1), Ethics (1), Software Development (1), Web Development (1)
Although Clinton's answer is certainly amusing, and I can definitely see it as playing well in a symposium setting, what I really want to figure out is a decision tree for narrowing the choices:
- what are the use cases in which these really shine or really don't fit: e.g., if I want a quick-to-market solution, X is wonderfully flexible, but has the disadvantage of not allowing me to do these kinds of things readily (plug into a CMS, scale via load-balancing, do wizard-style apps, run on mobile devices, or whatever)
- what're the paths to proficiency? Do I have to deconstruct the source code or sample apps to bring someone up to speed, or is there a thriving community, sets of docs, best pattern advice, ...?
- who has the best business pitch, in terms of selling my company on the path? Things like the depth of the talent pool or ease in training someone come into play, as do tool support and factors of development speed or cost of ongoing maintenance.
I assume all of these frameworks are workable. The challenge has always been being enough of an expert across the whole set to pick the right one for a given project (and hopefully breadth of projects), such that we build it the right way given that right tool. I know it's too much to resolve during a panel discussion, but even moving towards the first version of a decision tree for framework selection would be a wonderful step.
- What are you doing to help with developer productivity?
- 2008 is a huge year for the mobile web. How do you help developers build great mobile web applications?
- If you couldn't use your framework, what would you use and why?
- How do you enable rich Ajax applications?
- Can a developer make a change to source, and hit RELOAD in the browser to see the change? If not, why not?
- How easy do you make it to unit test the UI controller code outside a container?
- How easy is it to create a module and plug it into a bigger application, complete with configuration, code, and view?
- What have you done to support reloading to allow for an edit-refresh development cycle? How usable is reloading right now, and what are the limitations of what can be reloaded on the fly?
To turn David W's question on its head..
Q1) When are we going to get a J2EE specification that addresses front end concerns? ie. a framework for encapsulating validation logic, the presentation data elements, the actions associated with a UI event etc.. JSF is an attempt to address this, but why can't we have clear direction as to where to place our front end logic? Regardless of the framework and underlying paradigm, all front ends are performing the same types of logic processing.. If we have a specification to adhere to, we can then start creating more powerful tools to enable more flexible orchestration ...
2) When are we going to ditch the web browser and HTML and come up with a better protocol... html, css, javascript.. it sucks.
Clarification added March 7, 2008:
HTML, css, and javascript have done the job, but it is time to evolve. Hyper Text is too primitive. The new protocol needs to recognise video streams, UI widgets, etc.. etc.. The new client side renderer needs to allow user to customise the display, create their own displays etc.. etc...
Since there are already a bunch of good answers to your question I'd like to answer it in a different manner. I'd also like to preface this with the fact that I don't find developing in .NET. That being said, .NET development teams have an advantage over Java or even Rails developers. Their toolset if fairly predefined and they don't spend months determining the best solution, they simply go with what they have. This can actually produce lower cost end products (albeit they might not have the best solutions).
The Java community has been constantly refining what is good practice and how each different module in an n-tiered application should behave. This is a double-edged sword, we have some great benefits from this reinvention, but we also suffer from a lack of congruity. It is still very difficult to hire people that have specific knowledge of the architecture you use, and training can be expensive. One thing that is currently happening that I like is the Spring Source team is attempting to take a leadership role in the open source market to standardize. However, they cannot feasibly standardize everything, nor am I suggesting that they should.
I believe that eventually (probably soon) a lot of those less popular frameworks are going to die off. Most Java users enjoy trying out new software and seeing how things work, however, I feel like they're getting tired of having to relearn simple concepts over and over.
A great example of a technology that could have succeeded because it was technically superior is XSLT. XSLT has a plethora of features and benefits that many view technologies do not, and frankly, converting your domain objects in XML is pretty easy these days. However, it was too complex for people to learn, and therefore didn't take off.
What I'd really like to see is for the different platforms to learn from each other and develop standard practices such that the learning curve is smaller. Additionally, I think that the Java community needs to learn to accept something that isn't bleeding edge technology in order to keep costs down. Developing good software doesn't mean rewriting everything from scratch all the time.
To answer your original question, I'd like to ask everyone why there is so much infighting. If we work together on a few of the options instead of splitting into small teams on many different products can't we develop much better solutions? Does everyone really believe that their idea is superior? I don't think that they do, but if this is the case, why not become committers on other projects to add your ideas there?
Clarification added March 7, 2008:
I meant to write that I don't find developing in .NET enjoyable. This is, of course, my preference. Also, I don't mean to infer that Java developers don't have many advantages over .NET developers because there are certainly many examples to the contrary.
I would ask them what they think about the whole Flex revolution, and whether they think of themselves as competitors to this technology? If not competitors, which category of web applications do they feel they're fitting in?
Although Java 1.5 has been out for more than two years, I'm still finding corporate environments that haven't moved past Java 1.4. Do your frameworks still support Java 1.4 out of the box? If not, what features of Java 1.5 do Java developers need to sell to their supervisors?
Since when did frameworks become about trying to outdo one another rather than providing a foundation to help developers deliver dependable software on time and on budget? Options are not a bad thing to have, but I don't see options. What I see is a cat and dog fight for attention and fame, measured by the number of downloads achieved. An yes, Ruby on Rails, you are the most guilty of them all.
Let me justify my question before I offer up my response.
When an announcement is made about a new feature in a framework, my first reaction is to think "framework XXX can already do that" or "I think I can duplicate that functionality in framework XXX". I know that I share this sentiment with a vast majority of developers. In fact, I have heard these words used at conferences by speakers and attendees alike. To find someone guilty of taking this position, you only have to look in the mirror.
So I ask, is it possible to invest time in one framework and advocate another one? Can we stay impartial and hold the needs of the developer in front of our own vested interests?
In response, I will point out that frameworks are products. It's human nature to advocate something you have put time and money into, hoping to get other people to use it. With the exception of a select few, we all carry this bias. But, that doesn't mean we cannot our nature. Here's how you start. Select a framework that is not on your sounding board and say something good about it. The goal is not to merely adopt another framework into your arsenal of advocacy, but to learn from it. This experience might even give you reason to pause the next time you go to twist someone's arm into using your favorite framework. It's alright to have options, as long as they are really options and not just there for the fame.
Clarification added March 11, 2008:
Correction (last paragraph): But, that doesn't mean we cannot *control* our nature.
Clarification added March 11, 2008:
Since my primary framework choice is Seam, my plan is to say something nice about both Wicket and Grails, for different reasons. Sorry, I don't have anything nice to say about Struts.
