A reader sent in a question: "What's the difference between Struts and JSF? Which one is better?" That's a ... question. What do TSS readers say? What about other frameworks? How would you sum up the primary strengths and weaknesses in a comparison? (As food for thought, consider Fred Daoud's web frameworks conference, in the same vein as David Rupp's "conference" for languages...)

5...4...3...2...1

I posted yesterday something related to this in my blog: JSF Today: Standards versus OSS http://blog.brunoborges.com.br/2007/10/jsf-today-standards-versus-oss.html It's funny to see people "flashing back" to this subject... :) Regards

Imho GWT is the best at the moment. It is designed for Ajax. It is designed by people who proved that they are best in Ajax. It has reach set of UI controls (and there are a lot of free additional controls on market) It can let you write client side code in Java and debug it without dealing with JavaScript. You can write unit tests for UI. It is very simple (I've never imagine ajax framework can be that simple). It is very Object Oriented. You make develop it terms of classes that support inheritance not in terms of Components. It is Open Source project. Drawbacks of GWT - no commercial support.

gwt++

I vote for Spring MVC. Moved away from struts 2 years ago, and have been happily using spring mvc ever since.

Apache Tomahawk, Trinidad +1 GWT +1 Struts -1

Imho GWT is the best at the moment.

It is designed for Ajax.
It is designed by people who proved that they are best in Ajax.
It has reach set of UI controls (and there are a lot of free additional controls on market)
It can let you write client side code in Java and debug it without dealing with JavaScript.
You can write unit tests for UI.
It is very simple (I've never imagine ajax framework can be that simple).
It is very Object Oriented. You make develop it terms of classes that support inheritance not in terms of Components.
It is Open Source project.

You forgot the most important point that keeps this stuff still alive - it is promoted by Google.

Drawbacks of GWT - no commercial support.

Last time, Google has a strange tendency to kill any commercial initiatives. Good example is "My Maps" that killed tons of new mashup-oriented startups.

Thinwire : http://www.thinwire.com/ Thinwire vs GWT overview http://www.thinwire.com/?n=Participate.ThinWireVsGWT Comparison of AJAX Frameworks: Prototype, GWT, DWR and Thinwire http://ajax.javabeat.net/articles/2007/05/comparison-of-ajax-frameworks-prototype-gwt-dwr-thinware/

+1 GWT is an awesome tool.

First, I'd like to say that these are only my opinions (can be right or wrong).

Imho GWT is the best at the moment.

...
It has reach set of UI controls (and there are a lot of free additional controls on market)

I don't think so. I think RichFaces & Trinidad have more components (I don't provide the link to rf & trinidad live demos because I don't want to persuade you that rf & trinidad have more components than gwt).

It can let you write client side code in Java and debug it without dealing with JavaScript.

That's what I like in gwt.

You can write unit tests for UI.

If I use a jsf component set, that set guarantees me that all the generated javascript code works correctly. Then, why do I need to test if those components work correctly or not?

It is very simple (I've never imagine ajax framework can be that simple).

Maybe, it took me less time to learn gwt than jsf.

It is Open Source project.

Is there any commercial jsf implementation? There are a few commercial jsf component sets, but all the free jsf component sets are enough, I assume.
A few questions for gwt users:
1. any way to not compile the whole project if there is only one change in one java file in the client directory?
2. it took me 37s on my PIV 3Ghz with hyper threading technology machine to send 200 rows of 5 columns each from the server to the gwt client and display them in a flex table. any way to make it faster? (don't ask me to reduce the 200 to 20. 200 is a beautiful number that the client wants). it will take me less than 5s if I use jsp.

Imho GWT is the best at the moment.

...
It has reach set of UI controls (and there are a lot of free additional controls on market)

I don't think so. I think RichFaces & Trinidad have more components (I don't provide the link to rf & trinidad live demos because I don't want to persuade you that rf & trinidad have more components than gwt).

GWT components from different vendors can be used together. Try to use IceFaces with RichFaces.

You can write unit tests for UI.

If I use a jsf component set, that set guarantees me that all the generated javascript code works correctly. Then, why do I need to test if those components work correctly or not?

What if you misused compoent, or created your own and want to test? What if you want to test client side logic? There are many cases where you need client side debugging.

re:1. any way to not compile the whole project if there is only one change in one java file in the client directory?

No, but you can make the compilation process much faster. While developing build only for one browser and add more memory to gwt compiler.

it took me 37s on my PIV 3Ghz with hyper threading technology machine to send 200 rows of 5 columns each from the server to the gwt client and display them in a flex table. any way to make it faster? (don't ask me to reduce the 200 to 20. 200 is a beautiful number that the client wants). it will take me less than 5s if I use jsp.

It takes time not to send but to display. That's because of client side rendering. Try to use text in cells, not objects. If your application still not fast enough you'll have to draw rows on server and send html on client. (ugly but works). --Mark

another one here for GWT. At this point i really can't stand doing webapp work in anything else. previously used: jsp/servlets, tapestry 3, jsf, rails/jror, springmvc adrian

Thanks Mark for some advices. I hope you don't bother giving some more detailed advices.

While developing build only for one browser and add more memory to gwt compiler

Add more memory to the gwt compiler means -Xmx1024m, isn't it? And how can I tell gwt compiler to create the javascript for IE only? (if you don't have time to answer, a link to some page telling that is much appreciated).

Thanks Mark for some advices. I hope you don't bother giving some more detailed advices.

While developing build only for one browser and add more memory to gwt compiler

Add more memory to the gwt compiler means -Xmx1024m, isn't it? And how can I tell gwt compiler to create the javascript for IE only? (if you don't have time to answer, a link to some page telling that is much appreciated).

During development I recomend to compile to Firefox or IE for one language. By default GWT compiles to all browsers for all languages. Add this to your .gwt.xml file <!-- in case you use ugly m$ browser for development <set-property name="user.agent" values="ie6"/> --> Good luck ;-) PS One more coin to GWT GWT forum is extreemly user friendly (comparing to Hibernate forum).

GWT only allows Java 1.4 code for the client side. Also it is limited in the API's that it supports, which is understandable, but you need to be very careful.

Drawbacks of GWT - no commercial support.

Hi Mark. Have you checked out the support in Seam for calling ajax-enabled serverside components from GWT? It's pretty smooth..

It is strange to compare GWT with Struts and JSF. GWT is client-centric architecture, while the others are server-centric. Client-centric is better for light-weight applications/websites. Otherwise, GWT is tend to bring back the age of fat clients if you design it carelessly. That said, too many codes will be written at the client and then open up security/maintenance headache. It is the common problems in fat client/server architecture. No mention JavaScript is notorious for its bad performance. Try to create a moderate big table with GWT and compare it with JSF/Struts. If you want to use load-on-demand with GWT, you are throwing stones on your nails. On the other hand, you can use JSF's data model directly. For security, try to access, say, Paypal with GWT. Or, dare you? There are a lot of server-centric frameworks. My personal preference is ZK. It is the most intuitive yet powerful framework I ever tried.

It is strange to compare GWT with Struts and JSF. GWT is client-centric architecture, while the others are server-centric.

Correction - GWT is not client centric. It is client-server.

That said, too many codes will be written at the client and then open up security/maintenance headache. It is the common problems in fat client/server architecture.

UI logic, not security logic should be implemented in client part. Nobody forces you to do security checks on client

No mention JavaScript is notorious for its bad performance.

Rendering on client saves CPU time of your server. More over, no server neither client have to rerender page each on click.

Try to create a moderate big table with GWT and compare it with JSF/Struts. If you want to use load-on-demand with GWT, you are throwing stones on your nails. On the other hand, you can use JSF's data model directly.

Have you ever tried to use big table in IceFaces or Infragestics? Or any other AJAX JSF solution?

For security, try to access, say, Paypal with GWT. Or, dare you?

What problems did you have with paypal? ;-)

Rendering on client saves CPU time of your server. More over, no server neither client have to rerender page each on click.

In an AJAX world, what's a "click"? To really gain what you're talking about, you need to migrate away from a page-oriented flow whereas most apps still use AJAX as a supplementary facet of web application development. In addition, the mechanics of GWT basically require subsequent requests on load to populate dynamic-server based content (your clicks are driven by code instead of by the user). In a JSF/traditional call, you can simply render everything up front in the first request-- lending itself as being actually more efficient than GWT for a majority of web apps.

Rendering on client saves CPU time of your server.
More over, no server neither client have to rerender page each on click.

In an AJAX world, what's a "click"?

Same as in NOT AJAX world ;-)

To really gain what you're talking about, you need to migrate away from a page-oriented flow whereas most apps still use AJAX as a supplementary facet of web application development.

That's because most web apps are written on LAMP.

In addition, the mechanics of GWT basically require subsequent requests on load to populate dynamic-server based content (your clicks are driven by code instead of by the user). In a JSF/traditional call, you can simply render everything up front in the first request-- lending itself as being actually more efficient than GWT for a majority of web apps.

Do you REALLY think that to rerender whole page just to validate user input is more efficient? I'm not talking about how it ugly looks to user.

Do you REALLY think that to rerender whole page just to validate user input is more efficient?
I'm not talking about how it ugly looks to user.

No, I don't. Even LAMP solutions can do client-side validation. The only optimization a GWT-like deployment offers is when you want to provide multiple views over the same data-- not requiring another request to the server. Often these use cases are still supplemented by secondary AJAX functionality without locking your application into a different development paradigm. That simple, secondary AJAX functionality can be fulfilled by near every web-framework out there and isn't purely a benefit owned by GWT.

To really gain what you're talking about, you need to migrate away from a page-oriented flow whereas most apps still use AJAX as a supplementary facet of web application development.

Yes, let's get away from page-oriented flow! Whether you use Ajax as a supplementary facet or not. * I know I took this out of context Jacob. :-)

Rendering on client saves CPU time of your server.
More over, no server neither client have to rerender page each on click.

The trouble is customers can outright reject your work if javascript bogs down their web client, I had it happen to me, fool! It is often much faster (for page download and render time) and more efficient to write proper optimised server code (and data storage) which the client can make requests to, the browser should not be treated as a heavy Javascript client. Visitors do give a shit about page download and render time, too long and they are gone, even for intranets!

DWR + Dojo! I'm done with Struts, JSF, and other heavyweight MVC frameworks.

DWR + [pick one]

Both frameworks are abysmal. It's like asking someone if they prefer Hitler to Stalin. A better question might be, "If you could use any web framework besides Struts or JSF at your current job, what would it be and why?" Another option would be, "If you are currently satisfied with Struts or JSF, please explain why so we can laugh at you."

Both frameworks are abysmal. It's like asking someone if they prefer Hitler to Stalin. A better question might be, "If you could use any web framework besides Struts or JSF at your current job, what would it be and why?" Another option would be, "If you are currently satisfied with Struts or JSF, please explain why so we can laugh at you."

May I ask: what do you use? I won't laugh I just want to know any better option.

I use Spring Webflow (SWF), since it has the notion of a conversation -- whereas Struts does not. My next choice would be Seam, although I haven't used that much yet. All I really know is that Seam also has the notion of a conversation. Struts is also 'forward' based whereas SWF implements PRG (Post Redirect Get) out of the box. Since SWF also provides flow, conversation, and flash scopes, the form backing object also stays a lot cleaner (than say, Spring MVC or Struts form backing objects), and so you feel less dirty passing a SWF command object down to the business logic layer. Command objects under SWF start to quite closely resemble the GOF command object pattern. For me, JSF sort of missed the point. Web development isn't so much about a single page, but the flow between pages which everything except SWF and Seam seem to handle abysmally. I'm also looking at http://extjs.com with interest. Looks damn impressive. (

. . . . . "If you are currently satisfied with Struts or JSF, please explain why so we can laugh at you."

LOL!

Both frameworks are abysmal. It's like asking someone if they prefer Hitler to Stalin. A better question might be, "If you could use any web framework besides Struts or JSF at your current job, what would it be and why?" Another option would be, "If you are currently satisfied with Struts or JSF, please explain why so we can laugh at you."

Good one!!

I enforce Struts usage not because it's easy to use; it's not. I enforce Struts usage not because it's easy to learn; it's not. I enforce Struts usage because at least it imposes some semblance of MVC, although I have yet to meet a developer who hasn't found some way to screw this up too. . .

Looks like a post from the deeply past. Who cares about what is a difference between two those ones now? There are many new frameworks that pretend to be known. Let them to fight between each other. - Sergey JSFTutorials.net JBoss RichFaces

Looks like a post from the deeply past. Who cares about what is a difference between two those ones now? There are many new frameworks that pretend to be known. Let them to fight between each other.

-
Sergey
JSFTutorials.net
JBoss RichFaces

Can we debate VHS vs Beta next?

Looks like a post from the deeply past. Who cares about what is a difference between two those ones now? There are many new frameworks that pretend to be known. Let them to fight between each other.

-
Sergey
JSFTutorials.net
JBoss RichFaces

Can we debate VHS vs Beta next?

Did you see a "new" keyword in my post?

Looks like a post from the deeply past. Who cares about what is a difference between two those ones now? There are many new frameworks that pretend to be known. Let them to fight between each other.

-
Sergey
JSFTutorials.net
JBoss RichFaces

Can we debate VHS vs Beta next?

Did you see a "new" keyword in my post?

Yes. I was just furthering your "who cares" argument.

Neither framework is perfect. I actually like JSF for it's view components, so laugh away. My team members all prefer it as well. While using it, I found at least a dozen "features" that could have been better designed or more thought out. However, being able to add ajax-enabled features and rich widgets with virtually no effort on my part, makes up for it's overall cumbersome design. Seam also has a lot of great potential which I haven't been able to explore fully just yet. I dislike Struts quite a bit. I haven't used it since the 1.x days, so cannot comment on the most recent releases. I'm also curious as to the superior framework, Marc. Please have your laugh and share with us your infinite wisdom on where so many of us have gone wrong.

we are using webwork since 1.x, and move to struts, because webwork guy move to struts. and we love it, because the technology is not amazing to fast like JSF, dont know what happen in the future of JSF, will this tech become heavy complex but i am learning JSF for review.

Steve, I will never claim to have "infinite wisdom". However, I can recognize a turd pretty easily and lets face it, that doesn't take a genius. Seriously, during your experiences with JSF, you haven't sat there and wondered why you have to deal with numerous XML files and the high learning curve of JSF just to spit out a simple web page? Why they have to wrap JSF with other frameworks like Facelets and Seam just to keep the smell down? The problem with the Java community is that it's gotten way too comfortable with unnecessary complexity. This is what the Rails snobs laugh at all the time and, at least in that regard, they are absolutely right. As for my framework of choice, I like Wicket. It's component based, there's no XML, HTML stays HTML so GUI developers can maintain it themselves, it has Ajax components out of the box, small learning curve (although the online docs could be better), auto session management, etc.

As for my framework of choice, I like Wicket. It's component based, there's no XML, HTML stays HTML so GUI developers can maintain it themselves, it has Ajax components out of the box, small learning curve (although the online docs could be better), auto session management, etc.

To complement the online docs, I've written some tutorials on Wicket at http://www.agileskills2.org/EWDW/chapters1-3.pdf.

Routing around the hyperbole and actually trying to answer the question... The key differences between the two are the base paradigms that underly each platform. Specifically, JSF is a "component" framework whereas Struts is an "action" framework. What does that mean? In a component framework, artifacts that are rendered on the page are initially developed as individual components, much like in modern GUI "fat client" libraries. You have components, they have events, and your code is written to work with those events against the components. Most of the time, in mainstream development, your code is pretty much ignorant of the HTTP request cycle and processing. Struts (both 1 and 2) are action frameworks. In essence they give you the ability to map URLs to activities and code on the back end. Here, the layout and workflow tends to be more page oriented. As a developer you tend to interact with the HTTP request cycle directly, though Struts 2 helps isolate at least the binding of the request data to the action implementation classes. Action frameworks tend to be much "thinner" in how they stand between your code and the raw HTTP request compared to component frameworks. For those people just cutting their teeth on web development, the component frameworks (especially with good tooling) can be much more approachable, as the tools tend to hide the heavy weight nature of the component frameworks. But, on the downside, their size and their "square peg in to round hole" nature of turning HTTP requests in to the rough equivalent of mouse clicks mean there's more complexity to try to understand if and when the framework starts misbehaving or getting in the way. But, to be fair, frameworks like ASP.NET and JSF are popular because novices can get quick success with them with the modern tools. Old School HTTP wranglers may simply be more comfortable with action frameworks, simply because they've been through the crucible of understanding how HTTP requests are structured. Action frameworks tend to work better with "pretty" urls (though component frameworks are getting better at his). Action framework coders can have more control of the structure and presentation of URLs, since their systems are more intimately tied to them compared to a component framework. As a basic guideline, I find the action frameworks are better for "web sites", site like this one, sites that focus on delivering content to the user. Where it's mostly a "read only" experience for the end user who is likely to want to bookmark things, come back to arbitrarily deep pages, etc. But the component frameworks are better for "web apps". CRUD screens, back office applications, lots of forms and controls, etc. Here, the workflow is more controlled. You tend to not get to a "detail" screen with going through the "list" screen or "header" screen first, for example. It's nice to be able to just drag and drop a grid component on to a form, add a couple of buttons and point it as a DB table to get "instant" results. But these apps don't bookmark well, HATE the "refresh button", may behave poorly with the back button, etc. Overall, they can not be very good citizens when working with the web browser. So, if it were me, I'd write a blog in a action framework like Struts 2 (or even better, Stripes), but I'd write an accounting package in JSF.

Action-centric frameworks have components too - taglibs. They just never seemed to take off beyond struts taglibs and jstl. You would never think to extend the struts taglibs but that is what you can do (more easily) with JSF components by writing your own, extending, renderers, etc. The architectural smell about JSF is the tight coupling with everything: committees, servlet and jsp specs, with other component libraries, specific dependencies on implementations, the need to tack on other third party libraries to make it useful - facelets. Tack on tools to get that sweet smell of vendor lock to top it all off. I like SpringMVC just because it's so light, portable, and decoupled.

Action-centric frameworks have components too - taglibs. They just never seemed to take off beyond struts taglibs and jstl.

You haven't seen my code. I make extensive use of Tag Files in building our pages, and think that they are one of the unsung heroes of modern JSP. Our pages are very clean because of it. In the end, though, they don't offer the granularity of control or events that a full bore component framework offers. If they did, then I would have written my own component framework. And also, tag libs are JSP specific, whereas JSP is a only one of many rendering options (though Freemarker and Velocity have similar mechanisms). With the action frameworks, the rendering mechanism can more easily by separated from the actual back end framework.

The architectural smell about JSF is the tight coupling with everything: committees, servlet and jsp specs, with other component libraries, specific dependencies on implementations, the need to tack on other third party libraries to make it useful - facelets. Tack on tools to get that sweet smell of vendor lock to top it all off.

I like SpringMVC just because it's so light, portable, and decoupled.

FYI, JSF 2.0 takes the best of all those addons and builds them into JSF. JSP will no longer be the default view technology. The replacement will be built from a combination of Facelets + JSFTemplating + Clay. The Managed Beans functionality is being replaced by WebBeans -- a combination of Seam component model + Google Guice. WebBeans is kind of like Spring (same sort of idea) but does things differently. The UI component model is being completely redesigned for simplicity. Built in AJAX support is a top priority. The JSF 2.0 expert group has been studying other web frameworks such as Wicket and even Ruby on Rails for inspiration. So JSF is coupled to servlets, but SpingMVC and every other web framework isn't? You know JSF being tied to other JSR standard makes it portable. That is the whole point of every JSR standard. You are not locked into any one vendor. All Java EE5 app servers support the same JSR standards if they want to be certified. The Java EE5 certification is must more strict than the J2EE 1.4 certification. +1 for JSF. I like JSF just because it's so portable, decoupled, and JSF 2.0 will be light.

Yeah, those all sounds good. But sorry for being sarcastic here, is JSF 2.0 going to be released some time with the current decade? Any guess on by that time, what other better alternatives will be there?

Yeah, those all sounds good. But sorry for being sarcastic here, is JSF 2.0 going to be released some time with the current decade? Any guess on by that time, what other better alternatives will be there?

The JCP page for JSF 2.0 says that there will be a public review in 3 months, final spec in April (with a beta RI), then the release timed with Java EE 6 (Q3 2008). Those who use Sun's Application Server (GlassFish) like we do will be able to take advantage of Java EE 6 as soon as it's available. The rest will have to wait another 6+ months for their vendor to support it. I'm looking forward to JSF 2.0, WebBeans, EJB 3.1, JPA 2.0, Servlets 3.0, etc. Very exciting stuff.

Yeah, those all sounds good. But sorry for being sarcastic here, is JSF 2.0 going to be released some time with the current decade? Any guess on by that time, what other better alternatives will be there?

The JCP page for JSF 2.0 says that there will be a public review in 3 months, final spec in April (with a beta RI), then the release timed with Java EE 6 (Q3 2008). Those who use Sun's Application Server (GlassFish) like we do will be able to take advantage of Java EE 6 as soon as it's available. The rest will have to wait another 6+ months for their vendor to support it.

I'm looking forward to JSF 2.0, WebBeans, EJB 3.1, JPA 2.0, Servlets 3.0, etc. Very exciting stuff.

That time line basically says you don't even need to think about it now. 6+ months is a very long time on a tech watch. Q3 2008? Forget about it, that means it's irrelevant now.

That time line basically says you don't even need to think about it now. 6+ months is a very long time on a tech watch. Q3 2008? Forget about it, that means it's irrelevant now.

I am happy with JSF 1.2 and use it in production today. I am looking forward to JSF 2.0, and completely disagree with those who say that JSF 1.2 is terrible.

Routing around the hyperbole and actually trying to answer the question...

The key differences between the two are the base paradigms that underly each platform.

Specifically, JSF is a "component" framework whereas Struts is an "action" framework.

What does that mean?

In a component framework, artifacts that are rendered on the page are initially developed as individual components, much like in modern GUI "fat client" libraries. You have components, they have events, and your code is written to work with those events against the components.

Most of the time, in mainstream development, your code is pretty much ignorant of the HTTP request cycle and processing.

Struts (both 1 and 2) are action frameworks. In essence they give you the ability to map URLs to activities and code on the back end. Here, the layout and workflow tends to be more page oriented. As a developer you tend to interact with the HTTP request cycle directly, though Struts 2 helps isolate at least the binding of the request data to the action implementation classes.

Action frameworks tend to be much "thinner" in how they stand between your code and the raw HTTP request compared to component frameworks.

For those people just cutting their teeth on web development, the component frameworks (especially with good tooling) can be much more approachable, as the tools tend to hide the heavy weight nature of the component frameworks. But, on the downside, their size and their "square peg in to round hole" nature of turning HTTP requests in to the rough equivalent of mouse clicks mean there's more complexity to try to understand if and when the framework starts misbehaving or getting in the way.

But, to be fair, frameworks like ASP.NET and JSF are popular because novices can get quick success with them with the modern tools.

Old School HTTP wranglers may simply be more comfortable with action frameworks, simply because they've been through the crucible of understanding how HTTP requests are structured. Action frameworks tend to work better with "pretty" urls (though component frameworks are getting better at his). Action framework coders can have more control of the structure and presentation of URLs, since their systems are more intimately tied to them compared to a component framework.

As a basic guideline, I find the action frameworks are better for "web sites", site like this one, sites that focus on delivering content to the user. Where it's mostly a "read only" experience for the end user who is likely to want to bookmark things, come back to arbitrarily deep pages, etc.

But the component frameworks are better for "web apps". CRUD screens, back office applications, lots of forms and controls, etc. Here, the workflow is more controlled. You tend to not get to a "detail" screen with going through the "list" screen or "header" screen first, for example.

It's nice to be able to just drag and drop a grid component on to a form, add a couple of buttons and point it as a DB table to get "instant" results. But these apps don't bookmark well, HATE the "refresh button", may behave poorly with the back button, etc. Overall, they can not be very good citizens when working with the web browser.

So, if it were me, I'd write a blog in a action framework like Struts 2 (or even better, Stripes), but I'd write an accounting package in JSF.

Wow Will! After a long time I got to read some sensible analysis on technology than usual incoherent claptrap.

I don't think that it only depend on the webapp type, component vs action, but also on the dev team, personally if I have a small team with guru's, I will use velocity, with velocity you can create your own ui component and your own navigation controller, and adapt it to each webapp I think that each web framework represent the vision of the one hwo developp it, velocity let me adapt my component/controller to each webapp I create

Great post Will! If you don't mind, I'd like to add it to the Struts 2 FAQ as it perfectly answers the question of when to choose an action-based or component-based framework; I'll even leave the Stripes bit in ;) The only point I'd add is that action-based frameworks, Struts 2 in particular, are a better match for Rest-oriented designs and client-side heavy designs that use Dojo and other libraries to consume server-side JSON/XML services. For example, I'm writing a Struts 2 plugin that simplifies writing Rest resources and automatically supports multiple data representation formats so a Dojo component could consume JSON while a third-party client could use XML. Since you need full control over the URL and response headers, action-based frameworks are a great fit.

Great post Will! If you don't mind, I'd like to add it to the Struts 2 FAQ as it perfectly answers the question of when to choose an action-based or component-based framework; I'll even leave the Stripes bit in ;)

Sure, free free to copy it wholesale in to the FAQ if you like.

The only point I'd add is that action-based frameworks, Struts 2 in particular, are a better match for Rest-oriented designs and client-side heavy designs that use Dojo and other libraries to consume server-side JSON/XML services.

Yes, of course. This is lightly implied by the mention of how an action framework has more control over the URLs. I was simply trying to answer the question at hand rather than go down in to the depths of the further ramifications of the frameworks beyond your base requirements for web applications.

It's nice to be able to just drag and drop a grid component on to a form, add a couple of buttons and point it as a DB table to get "instant" results. But these apps don't bookmark well, HATE the "refresh button", may behave poorly with the back button, etc. Overall, they can not be very good citizens when working with the web browser.

So, if it were me, I'd write a blog in a action framework like Struts 2 (or even better, Stripes), but I'd write an accounting package in JSF.

Excellent post Will. Thank you for increasing the signal-to-noise ratio of this thread. JSF is complex, but so is Swing. In both cases, the complexity of these GUI development frameworks or toolkits also an indication of their power. I think some developers new to JSF may be frustrated by the learning curve, but I can safely say at this stage (having climbed it myself) that the rewards are huge. JSF truly separates UI design from programming, meaning Web designers and Java developers can do the things they do best within the same framework. I love being able to drag-and-drop a command button onto my page in Dreamweaver, wire it up to an EJB3 stateful session bean with some EL, load the view in my browser, click the button, and debug my code in Eclipse. Leveraging the full power of the Java EE stack from your UI is awesome. The criticism that you need other frameworks to make JSF usable completely misses the point. JSF was designed for extensibility, and frameworks like Facelets and Seam take full advantage of that to add new features to the framework, such as advanced view composition, binding UI components to EJBs, and much more. Those efforts are also helping to define new standards for enterprise Java-based Web development and are leading the way to enhancements to the JSF framework. JSF is still young, and is evolving. Third-party frameworks like Facelets and Seam are a clear indication of this, and the wide range of UI component libraries promote innovation and reusability. As for the back button issue, I thought we solved that problem with the Post-Redirect-Get pattern. As for bookmarking, I'm leaning towards REST principles and pull-style MVC to make my URLs easier to work with. Have you looked at the Seam RESTful blog application example? Ian Hlavats JSFToolbox for Dreamweaver UI Design with JSF, Dreamweaver, and the JSFToolbox

As for the back button issue, I thought we solved that problem with the Post-Redirect-Get pattern.

The Post-Redirect-Get pattern only really works in the Web 1.0 world. With Web 2.0 (i.e.: AJAX), that all falls apart. As for frameworks, the only one I have truly been impressed with is Stripes. I was able to get up to speed with it in 20 minutes. Interestingly, Stripes uses what's already available as of Java 1.5 and servlet 2.4 (annotations, generics, JSTL, etc...) and takes it to the fullest potential (or close to it). You don't have to completely learn everything all over again with it. In a sense, there really was not ever a need for JSF. We already had custom tags to create components with. JSP was not the problem, scriptlets were and JSTL fixed that. Besides, JSF *is* also action-based under the hood like everything else. It just *also* happens to have a complicated component framework and touts itself as "component-based".

Using plain JSF does not give you any value addition. Availability of ready made components in JSF based rich frameworks (ICEFaces, RichFaces and a few others) is where it pays off. You can't easily mix and match components from different JSF based frameworks yet, but hopefully it will move towards that.

JSF was designed by the same folks who developed Struts, applying the lessons they learned from doing Struts. David Geary, at least, pretty much disavows Struts. You'll find JSF to be more flexible in many areas, as revealed in this (serious) comparison: http://websphere.sys-con.com/read/46516.htm P.S. If you are new to this forum, you may be surprised to find that the majority of answers to serious questions are smart-alecky, beside the point, and often vulgar.

There's way too much focus on those two frameworks recently. Everyone tries to push them and everyone seems to hate them. At the same time whole web world goes in the same direction. Even PHP finally starts to get it. Despite all that, my personal preference is Stripes framework. How much more easy can it get?

Hi, I used Struts 1.x, and a lot of WebWork 2 (Struts 2)... I also evaluated GWT, Wicket, Tapestry, Stripes... but forget all of them, the Click framework is definitely the most simple and easy to use and learn. It has a lot of components out of the box, good documentation, it is page oriented (but can be used as a action framework too)... it looks like wicket but it is more simple. See the examples and source code for yourself: http://www.avoka.com:8080/click-examples/home.htm

Is there any possibility to use Ajax? Looks to be slow. greetings, Albert

Hi, unfortunately not, this is on of the drawbacks of click. You must create your own components and override the toString() method to generate some ajax stuff...

Hi,

I used Struts 1.x, and a lot of WebWork 2 (Struts 2)... I also evaluated GWT, Wicket, Tapestry, Stripes...

but forget all of them, the Click framework is definitely the most simple and easy to use and learn. It has a lot of components out of the box, good documentation, it is page oriented (but can be used as a action framework too)... it looks like wicket but it is more simple. See the examples and source code for yourself:

http://www.avoka.com:8080/click-examples/home.htm

Yes Click is very easy and intuitive, the only downside being Strong Ajax support.

Hi,

I used Struts 1.x, and a lot of WebWork 2 (Struts 2)... I also evaluated GWT, Wicket, Tapestry, Stripes...

but forget all of them, the Click framework is definitely the most simple and easy to use and learn. It has a lot of components out of the box, good documentation, it is page oriented (but can be used as a action framework too)... it looks like wicket but it is more simple. See the examples and source code for yourself:

http://www.avoka.com:8080/click-examples/home.htm

Yes Click is very easy and intuitive, the only downside being Strong Ajax support.

One of the best things about Click imho is that the code base is tiny, making it very easy to trace back errors and making you less dependent on a magical box. But The other side of simplicity is that it won't help you as much with complex scenarios. And that's one of Wicket's best parts: it scales really well for development.

Apple's WebObjects is still the best web framework I've come across, but it's commercial ($699) and not open source. It's disappointing that the OSS community hasn't produced anything as elegant or powerful. The two best open source web frameworks I've come across are Tapestry and Wicket (both Apache projects). Like WebObjects, they're both component-based, and unlike JSF, reasonably well-architected and easy to get started with. If you're open to trying something more esoteric, you could also learn Scala and try Lift, but it's pretty new, and so still not something most developers are ready to use in production applications (yet).

Apple's WebObjects is still the best web framework I've come across, but it's commercial ($699) and not open source.

I think you will find that WebObjects is now free (and has been for some time). The recommended development environment is now one of the popular Java IDEs (e.g. Eclipse) with a couple of open-source tools to assist (with setting up the OR map and configuring Web pages). Cheers, Ashley.

I vote for Grails. It's action-based, but very easy to create tags that can have their own 'controller' and 'view'. All of the view templates can be written as plain XML/ HTML etc. There is _no_ XML configuration and URL mapping is done through a simple configuration mechanism. It is easy to get up an running without hiding too much of the environment from the user.

A show of hands of people that have used a light framework with an awesome javascript library like jQuery. A show of hands of people that after using the light framework with jQuery would go back to JSF.

Try them. Sometimes broccoli is nice too.

...the winner is emacs. and_open_braces_go_here() => { { <== not here 2, or 4 spaces for indentation are better than 5 (or 8, god forbid), but ANY number is better than tabs. And of course, camelCasingIsForPansyPascalJunkiesAndDotNetGoobs. What'd I miss?

I've used both JSF and Struts 2 quite a bit. JSF: Plenty of special IDEs and control libraries to choose from. Although, I found it very hard to get these tools to do what I wanted them to do and ended up coding most functionality from scratch. I really had a bad experience with JSF. If you don't mind working in the Microsoft universe, ASP.NET is a much better framework for this type of novice-friendly component-rich development. Struts 2: Very simple, elegant, and flexible. If you are comfortable with raw HTML/JS/CSS, and tend to dislike "heavy" tools and frameworks that get in the way, this is for you. This works really well with client-side GUI libraries (Scriptaculous, Yui, etc). Very much designed around test-driven development. I love it and feel very productive with it so far. GWT: I have limited experimental use with this, but I wanted to point out that this is for a really different type of app. GWT is more of an RIA framework along the lines of Flash, Flex, Silverlight, JavaFX, while Struts and JSF are for more traditional web development and compete with PHP, Rails, and ASP.NET.

I've been evaluating the latest frameworks to use on an upcoming project. I've looked at Spring MVC, Seam, Stripes, Struts 2, Wicket, and finally Tapestry 5. I'm currently in the process of building a prototype with Tapestry 5 and I gotta say I'm impressed. It's basically a better Wicket...more reliance on annotations and great IoC support. No base classes to extend, all PoJo and clean separation of UI.

Tapestry 5. It's basically a better Wicket...

Are you sure it's better than wicket? We have switched from JSF to Wicket. We didn't evaluate Tapestry... I have heard it's quite complex.

I too thought that the previous versions of Tapestry were overly complex, but Tapestry 5 has been rewritten from the ground up and is not even trying to be compatible with the previous versions. It's clean, simple, elegant and powerful...clearly a step in the right direction. http://tapestry.apache.org/tapestry5/

Tapestry 5. It's basically a better Wicket...

Are you sure it's better than wicket? We have switched from JSF to Wicket. We didn't evaluate Tapestry... I have heard it's quite complex.

Nah it's not (but as a Wicket developer, I'm biased). Tapestry 5's Ajax support still isn't great and Wicket is way more dynamic. The only thing imho you might like better about Tapestry 5 is that you can get away with writing less code.

I've been evaluating the latest frameworks to use on an upcoming project. I've looked at Spring MVC, Seam, Stripes, Struts 2, Wicket, and finally Tapestry 5.

I'm currently in the process of building a prototype with Tapestry 5 and I gotta say I'm impressed. It's basically a better Wicket...more reliance on annotations and great IoC support. No base classes to extend, all PoJo and clean separation of UI.

I don't mind anyone liking Tapestry 5 better than Wicket. But I don't agree with the arguments you give here. Why is 'more relience on annotations' a good thing? I disagree. And I'm sure Tapestry 5 has great IoC support, but Wicket has that as well. In fact, IoC is supported in a general fashion, so you can plug in Spring or Guice (both already available) or whatever lib you like. Clean separation of UI is something both frameworks support and in fact Wicket is a bit more zealous in that separation (which you may or may not like). Using base classes (but not required abstract base classes like Tapestry had before!) instead of interfaces actually makes sense sometimes. With base classes, you have finer control over what you expose how and you can better guarantee contracts. Even those base classes are 'pojos'. Furthermore, Wicket only requires components to extend base classes (and for good reasons). Most other things are based on interfaces, including behaviors, which are Wicket's way to support object composition.

Instead you should consider a framework where UI:s are developed in Java. Currently available options are: GWT, IT Mill Toolkit 4, Echo2 and Thinwire. Upcoming IT Mill Toolkit 5 will combine the best of server-side and client-side Java UI development: http://forum.itmill.com/posts/list/318.page

Instead you should consider a framework where UI:s are developed in Java. Currently available options are: GWT, IT Mill Toolkit 4, Echo2 and Thinwire.

With Wicket, the only thing you don't do in Java is layout management (for which you use plain HTML and CSS). Layout management in Java can be both convenient (if you're UI requirements are modest) or a PITA (when you're deviating from the mean).

For layouts, both declarative (in HTML) as well as programmed layouts should be supported and mixable. This allows you to use the best tools for all situations.

what I find a little funny is people saying Struts is all action based. Fact is, you can do component based development with Struts... well, if you use the nested tag library. But only a few people were open minded enough to listen to me back in the day (oh well, the world's loss) ...but with the nested tags, you really can separate out complete components, and hook them all up on the server. Include them in a component fashion in the UI, and it's all married back for you through the tag library itself. Very usable. Some people have used it for this very ability to manage very large object structures (including true recursion)... but "popular" was not a term you could pin on the nested tags (and I sleep at night knowing that just because it wasn't popular, didn't mean it wasn't a wickedly productive way to do things :) Also, the nested tags boiled down the tags to a much simpler form. Just ask the people that did "get" the nested tags mojo if they like developing with Struts in a component fashion, they are out there.

I, for one, before have started using WebWork had longterm experience with plethora Java frameworks including classic Struts 1, few implementations of JSF including ADF, Spring MVC, Stripes etc. Starting to work with WebWork 2 was like enlightenment. All, simply all problems I had with those farmeworks were solved here, in lightweight, elegant way. Simply one of the best piece of software I've ever seen. I'm amazed how simple, elegant and powerful WW is. Never ever look back. Speaking about JSF and other "controls" oriented frameworks like ASP.NET. I cannot understand who actually is using it for real life projects, except most simple ones? Unless You are using standard functionality (which is in most cases, especially in JSF, is just rudimentary) be prepared for hard work. Want something different from "standard behavior"? Want to integrate two frameworks? Welcome to hell ;).

A good framework is one that is cheap to use over the short, medium, and long term. As private companies are now evolving in a global and extremly competitive world, developers will save their jobs by adopting cost efficient frameworks around these 3 horizons. Short term: The upfront learning cost of a good framework must be as cheap as possible. This means should require the smallest footprint in terms of time to be efficient to start delivering web applications on top of it. Medium term: A good framework will have to be extensible. New pages can be designed at low cost. New widgets can be integrated cheaply (time and money wise). Long term: This is the most difficult to achieve: Applications designed with a good framework must be maintainable. MVC is one way of achieving this but it so easily wrongly implemented. The language plays a significant role here. The ability to find developers on the technology as well. In the proprietary world, my personal intuition is that ASP.NET is emerging as a winner. In the free world, the picture is more complex. Taking the long term horizon, it seems a Java-based framework is a good candidate. Ruby on Rails developers are not widely available globally yet for example. So it seems that we are looking at a Java based framework. Taking the short term horizon, it seems that J2EE based frameworks are too costly. A core java developer needs weeks to understands the way HTTP, servlets, tag libs, EJBs and the like. I place JSF in this category. Structs is in the same line: It takes time(=money) to learn it. Spring is a step in the right direction, but its MVC implementation is only alleviating the pain. Let me share some thoughts from an other angle: A company can take a young software engineer right out of school and start building rich gui applications (with frameworks like swing or swt). Why cannot we figure out a way to develop a web application using the same simplicity ?. Answers to this question are starting to emerge in the java free world: - Tapestry, Wicket, GWT, RAP an others. In my opinion, none of them do answer the medium term horizon: They lack real extensibility. Who will win ? Tought to say. I start to have a significant experience with GWT. Out of the box, it lacks professional looking controls. GWT-Ext is a beginning of answer, but this is still way too cutting-edge for a conservative company. I don't think there is a clean winner yet, but the winner will be the one adopting a GWT like approach with a choice of javascript/ajax controls wide enough to build very professional and dynamic applications as we can do with Swing or SWT. My 2 cents, Sebastien Marc.

Best server-centric RIA solutions I found so far. If you know how to develop event-driven application, you'll find it very easy to use. Great support, too.

I think my tutorials on Struts and JSF for beginners answers this question. Kindly visit: http://in.geocities.com/rsramsam/struts1.htm and http://in.geocities.com/rsramsam/jsf1.htm RSR

If you are keeping alert of any technical news this article on JAM may interest you. It is a tool kit for testing Java/J2EE applications. I think there are many applications in the software market. I am keen on checking out dedicated server hosting plans for my upcoming website. I believe there is a fierce competition going on among web hosting companies to offer the best service. I am sure there are many web hosts in UK and USA that can offer a reliable service.

Paul - http://www.connetu.com