Thinking OPEN

Web Framework Project Comparison Matrix

By Kimberly McClintock • Oct 4th, 2008 • Category: Comparisons

A Web Framework speeds development by providing libraries to satisfy the common development needs of Web applications, and by promoting code reuse among engineers and over projects. For example, many frameworks provide libraries for establishing database access and managing user sessions. We’ve developed this comparison matrix to help you learn about the differences between – and relative benefits of – the most popular open source Web frameworks: Shale, Struts, Wicket, WebWork, Rails, JBossSeam, MyFaces and Spring. Although Rails is not a Java project, we included it given its popularity.

To help you make a decision about which Web Framework to use, we went to the experts — members of the OpenLogic Expert Community who are committers and expert users of the projects — and asked them to answer a bunch of questions about each project.

The Five Questions

The five questions we asked the experts appear below. To view more detail on the projects* compared across each question, click the question.

  1. What’s the ’sweet spot’ of your project? For what type of projects should users strongly consider it?
  2. What type of scenarios does your project not fit into as well? Would you recommend another project in this scenario? If so, which one?
  3. Of the projects included here, which have you tried? Of those, which ones did you like or dislike, and why?
  4. What is the future of this project? What’s coming that will ease development?
  5. Are there myths about this project that you’d like to challenge?

For comprehensive information on each project, search the OLEX Open Source Library. For a list of the open source developers we interviewed, click here.

*While no version of the projects is specified, you can assume that the information relates to the latest version in our library at the time of the last update.

Summarized Responses

What’s your project’s ’sweet spot’?

This is a summary of the responses. For full detail, click here.

Project Summarized Response
MyFaces
  • Separation of MVC layers reduces developer effort.
  • Framework addresses every complex aspect of Web development.
  • Developers can create new components or use existing ones.
  • Many sources for additional components.
JBoss SEAM
  • Complex Web applications that need to integrate with other open source projects.
  • Applications that have a long running business context.
  • Complex applications
  • Supports RESTful pages
  • Supports AJAX functionality
  • Uses new EJB 3.0 programming artifacts
Spring MVC
  • Projects that use – or intend to use – Spring
  • Projects that need to expose business logic as HTTP addressable URLs
  • Projects that must provides multiple view rendering techniques
Stripes
  • Projects in which developers must get productive fast
  • Sensible defaults reduce the need for configuration
  • Contains all basic components necessary for enterprise Web development tasks; avoids feature bloat
  • Stable code base
Struts 1*
  • Struts 1 has essentially been replaced by Struts 2 and is not recommended for new projects unless the development team already has expertise
Struts 2* (WebWork)
  • Projects with developers familiar with Struts 1
  • Projects using Struts 1 who need productivity increase
Wicket
  • Projects that must create the typical stateful Web application that must track session state and perform services for the user.
  • Ideal for developers who prefer a very clean separation of concerns and object-oriented programming
  • New projects that need to get up and going fast
  • Projects with teams that have UI members and programmers, working independently
  • Single developer  projects
  • Projects requiring mailing list support
Shale*
  • Projects requiring exceptional JUnit /JMock based testing framework
  • Projects requiring an XML-based alternative to JSP
Rails
  • Web applications depending on REST and/or AJAX
  • Standalone Web sites

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What sorts of projects does this package not work as well for?

This is a summary of the responses. For full detail, click here.

Project Summarized Response
MyFaces
  • No native AJAX support
  • No support for REStful pages
  • Standard component set too limited for complex enterprise applications
JBoss SEAM
  • Stiff learning curve makes it a challenge for projects with junior developers
  • Developers will need knowledge of JSF and some EJB 3.0 framework.
  • Simple CRUD applications.
Spring MVC
  • Projects with a complex business model
Stripes
  • Projects that need to run in a context where Java5 is not available
  • Established projects
Struts 1* Struts 1 has essentially been replaced by Struts 2  and is not recommended for new projects.

The following is included for purposes of comparison:

  • Projects that will be deployed to a 1.5 JVM
  • A lot of boilerplate code needs to be written for simple tasks
  • A Struts application will always have more classes than an equivalent application written in a different framework
Struts 2* (WebWork) Not recommended for any but new projects.
Wicket
  • Nearly completely static or completely stateless sites should avoid Wicket
  • Projects with existing code
Shale*
  • Shale is “on-top-of-JSF” so can’t be used outside a JSF-app
Rails
  • Projects that require lots of enterprise integration

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Of the projects we’re comparing, which have you tried?

These are summarized answers. For more detail, click here.

Project Summarized Response
MyFaces Seam: didn’t like

  • Steep learning curve for the developer, including JSF + EJB 3.0.
  • Its many libraries make it challenging to successfully deploy.
JBoss SEAM No information available.
Spring MVC Struts: liked

  • A simple, mature web framework. Struts 1 is a bit heavy and tedious, but the newest version (Struts 2) blends the robustness of Struts with the benefits of WebWork and many lessons learned from the Rails framework.

Webwork: liked

  • A simple, mature, and lightweight framework. Configuration can be arduous. Development has merged with Struts and benefits from the experience and community of that project.

Rails: liked

  • Rails favors convention over configuration and goes a long way to making web application development simpler. However, it is still immature and lacks the breadth of features of Java web application frameworks.
Stripes Spring: MVC: didn’t like

  • Overly complex, too much configuration outside the code.

Struts 1: didn’t like

  • Hamstrung by the backward compatibility requirements.

WebWork / Struts 2: didn’t like

  • WebWork learned a lot from Struts 1, but still suffers from configuration pain.
Struts 1* Spring MVC: didn’t like

  • Overly complex, too much configuration outside the code.

WebWork / Struts 2: didn’t like

  • WebWork learned a lot from Struts 1, but still suffers from configuration pain.

Stripes: liked

  • Excellent framework, clean and simple, it simply keeps out of the way.
Struts 2* (WebWork) Spring MVC: liked

  • Respectable effort that no one should be ashamed of using.

Stripes: liked

  • Very compelling. Either would be a good choice for a project getting a fresh start.

Wicket: liked

  • Very compelling. Either would be a good choice for a project getting a fresh start.

JSF: didn’t like

  • is the EJB of web frameworks. Cool in theory. Hell in practice.
Wicket Spring: liked

  • I use it to configure my entire middle-tier, and it allows me to operate many similar sites by overriding pieces of configuration that may be different for that particular site.  I’ve also used it for configuring custom back-office applications based on many components that I wrote, and wired together via Spring.

Tapestry: didn’t like

  • Worked with it for two years on an enterprise project at work.  It had absolutely no transparency as to what was going on underneath the covers.  It forced you to do things a certain way – the “HLS” way.  Everyone involved with the project seemed religiously addicted to it, and only to doing it the “HLS” way, like he was a deity.  It forced tons of configuration on you.  Every release is a complete rewrite, and backwards-compatibility is constantly thrown out the window to suit the author’s current whims.  The learning curve is extremely steep.  I hear that version 4 is better, but I gave it up with version 3.

Trails: didn’t like

  • Didn’t try very hard. Couldn’t ever really get it to work well, although with more effort, that would’ve likely changed.  Did not like Tapestry, so did not pursue further.
Shale* Spring MVC: liked

  • Cool, nice glue code, but there is a little overlap in Shale’s dialog and Spring Web-Flow (their JSF-version).
Rails No information available. TODO

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What is the future of this project?

This is a summary of the responses. For full detail, click here.

Project Response
MyFaces
  • Community is writing the new JSR 314
  • Artifacts from Shale will probably make it into JSF 2.0
JBoss SEAM
  • Developers are simplifying this project by separating the add-on parts
  • Project is related to the JSR Web Beans
Spring MVC
  • Easier configuration and better validation
Stripes
  • No major architectural changes
  • Community has expanded to ensure response to requests
Struts 1*
  • Bug fixes
Struts 2* (WebWork) No information available.
Wicket
  • Improvements to scalability
  • Better support for stateless applications
  • Full-featured Java 1.5 version planned
  • More tightly-integrated support for Spring
  • Role-based authorization
Shale*
  • Some artifacts from Shale will probably make it into JSF 2.0
Rails
  • Rails 2.0 is expected to be released by the end of 2007

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What is the future of this project?

This is a summary of the responses. For full detail, click here.

Projecth Response
MyFaces No information available.
JBoss SEAM
  • Some developers think that JBoss SEAM is a J2EE standard, but it is not.
Spring MVC
  • Spring MVC and Spring WebFlow are not competing projects.
Stripes
  • Stripes has been dismissed as a “one man band” but it has a very helpful and constructive user and development community
Struts 1*
  • Struts has no support for AJAX.
  • Developers also think that they will be required to use JSPs.
Struts 2* (WebWork) No information available.
Wicket
  • URLs are ugly.
  • That this framework is an infant version of Tapestry.
Shale*
  • That Shale is a JSF implementation
Rails
  • That Rails is all about code generation

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Complete Responses

What’s your project’s ’sweet spot’?

This is the full response. For a summary of the response, click here.

Project Response
MyFaces The JSF/MyFaces Web Framework reduces developer effort by cleanly separating MVC layers. The framework addresses every complex aspect of Web development, including page flows, model validations, model conversions and page actions. Developers have the freedom to create new components from scratch, or launch development from existing components. Because JSF/MyFaces represents the standard implementation, developers have another resource for components: the many open source solutions available. The list include ICEFaces, Ajax4JSF, Apache Trinidad and Sun Sandbox.
JBoss SEAM JBoss SEAM allows developers to code many types of complex, multi-window, transactional web applications more easily using EJB 3.0 as M(Model) layer and JSF as VC(View-Controller) layer part of the project.

It supports RESTful pages, provides AJAX functionality, and eases the development life cycle by using the Java annotations heavily. It provides new EJB 3.0 programming artifacts easily, so while developers need to learn this functionality, they do not have to be experts to begin.

This set of tools works well on projects aspiring to integration with other open source projects.

Finally, SEAM extends the classical session, request, and application scope with new defined context. This makes it a good choice for applications that have a long running business context containing more than one request.
Spring MVC Because the Spring MVC Web application framework is tightly integrated with the Spring application framework, it is best suited for projects that use – or intend to use – Spring as the basis. It provides a simple way of exposing business logic as HTTP addressable URLs and provides multiple view rendering techniques.
Stripes Stripes, a Java servlet presentation framework, is an ideal fit for many Web based applications, large or small. Stripes offers a clean design with simple concepts that allow developers to get productive fast. Annotation based configuration was designed into the tool, and sensible defaults reduce the need for configuration to be explicitly stated. Finally, a carefully controlled code base keeps the tools from the feature-bloat that makes competitors unwieldy while not compromising on the basic components developers will need to do the classic enterprise Web development tasks.
Struts 1* Although Struts 1 has essentially been replaced by Struts 2 (also in this list), and is not recommended for projects commencing today, it is still in use and extremely popular with enterprises so we’ve included it here.

Struts 1 provided an excellent fit for projects that involved form submission. When Struts was first released developers migrated to it from home grown servlet frameworks. Struts gave the industry a defacto standard for developing browser-based applications.
Two notable sites using Struts 1 are http://www.virgin-atlantic.com and https://www.21st.com/.
Struts 2 (WebWork) Struts 2, WebWork renamed, is an excellent web application framework of the “action controller” family. Due to similarity of paradigm, those tens-of-thousands of developers out there that are familiar with Struts 1 can learn Struts 2/WebWork in a matter of a day, realizing huge productivity increases. At the time my team made that transition about 3 years ago, we estimated about a 40% productivity increase in work on the web application. This is due to the (what was at the time WebWork was built) “next generation” features that WebWork introduced upon the “action controller framework” paradigm. Validation, auto-form handling, type conversion, interceptors, etc. all add up to having a real usable tool set, without having to entirely change the way you “think”.

If a team is coming from Struts 1 and looking for a quick worth while change, WebWork/Struts 2 is for you. It vastly improves upon Struts 1, and has features that are quite competitive against the newer frameworks.
Wicket Wicket, out-of-the-box, provides everything teams need to create the typical stateful Web application that must track session state and perform services for the user.

This Web framework is ideal for developers who prefer a very clean separation of concerns and object-oriented programming and need to get going fast. Developers can be productive in Wicket quickly. Teams that have UI members and programmers working independently of each other find Wicket exceptionally friendly. Since the HTML is all regular HTML, with no weird additional syntax, the UI designers can write the HTML / CSS and leave the implementation completely to the programmers.

Although it sounds like the opposite of the previous point, Wicket is also great for one-man shops where one developer must program and write her own HTML. The developer can focus on object-oriented programming, and then add the basic HTML once she’s figured the implementation out. Projects that need or desire excellent mailing list support will find that the wicket-users mailing list first rate.

If you just want to do object oriented programming and not worry about jumping through hoops to work with “the framework”, Wicket is for you.  Once you understand a few basic concepts of how Wicket operates, you can start to figure out most of it on your own.
Shale* The Shale Web framework offers an exceptional JUnit /JMock based testing framework that provides developers the possibility of testing their JSF-application. Other goodies include the view-controller which follows the common JSF-pattern of one ‘backing bean’ behind the page. For teams that need an XML-based alternative to JSP, Shale provides CLAY.
Rails The sweet spot for Rails is any web application, especially ones that involve REST and/or AJAX. It should be strongly considered for stand-alone web sites.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What sorts of projects does this package not work as well for?

This is the full response. For a summary of the response, click here.

Project Response
MyFaces If developers need to create an application that requires static pages using HTML+ CSS + JavaScript, then JSF/MyFaces is not the best choice. It does not natively support AJAX functionality and developers will have to use one of the AJAX-enabled JSF components available in the community. JSF/MyFaces does not support REStful pages and the standard component set is probably not enough for implementing complex enterprise applications.

Users say, JSF “is the EJB of web frameworks. Cool in theory. Hell in practice.”
JBoss SEAM Although this project tries to address all the challenges of developing dynamic web projects, the stiff learning curve makes it a challenging set of tools for junior teams. Developers will need some knowledge of the JSF (it uses JSF as view) and some familiarity with the EJB 3.0 framework.

Its dependence on libraries makes JBoss SEAM challenging to deploy. Suitable for very complex and transactional dynamic web projects, it should not be used in simple CRUD applications.
Spring MVC A relatively new framework, Spring MVC is missing some of the features of more mature frameworks. If developers are building a project with an established, complex business model, it is somewhat arduous in Spring MVC to bind request parameters to a complex model. WebWork would be a better choice in this scenario because of its OGNL binding framework.
Stripes Because Stripes requires Java 5, it will not work in any context where Java 5 is not available. Developers think this would be a great choice for brand new projects, not as good for those with existing code.
Struts 1* Any projects that will be deployed to a 1.5 JVM should use Stripes instead.

One of the biggest complaints about Struts 1.x is the amount of boilerplate code that needs to be written for simple tasks. For instance, there is configuration required in struts-config.xml, possibly a form class to be written, and action class, possibly a Tiles configuration, and the a JSP. None of these things can be changed without introducing backward-compatibility problems with earlier Struts releases and so Struts 1.x is not able to overcome these weaknesses.

The lack of annotations can be mitigated with the use of tools such as XDoclet, and smart design can reduce the pain involved with adding new classes. However, the separation of form and action that many of the newer frameworks have avoided can only be handled, can’t be fixed. This means a Struts application will always have more classes than an equivalent application written in one of the other newer frameworks.

Given all of this, Struts 1.x makes a poor choice for most projects commencing today, with one exception: if the team is already familiar with Struts 1.
Struts 2* (WebWork) Not recommended for any but new projects.
Wicket Nearly completely static or completely stateless sites should avoid Wicket.  Wicket does perform well even for this sort of site, but it provides a lot of things that developers will not need in this situation. Wicket is a great choice for brand new projects, not as good for those with existing code.
Shale* Requires JSF/MyFaces as it provides the runtime environment for Shale. Since Shale is “on-top-of-JSF”, the usage of Shale outside a JSF-application is pretty limited.
Rails Rails does not particularly excel at projects that require lots of enterprise integration, such as performing a transaction across multiple databases or message queues. In these situations, Java-based Web application frameworks are probably the best choice. This may change in the future, however, as JRuby can already run Rails applications and also use Java’s high-end integration facilities.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Of the projects we’re comparing, which have you tried?

This is the full response. For a summary of the response, click here.

Project Response
MyFaces Seam: didn’t like

  • Steep learning curve for the developer, including JSF + EJB 3.0.
  • Its many libraries make it challenging to successfully deploy.
JBoss SEAM No information available.
Spring MVC Struts: liked

  • A simple, mature web framework. Struts 1 is a bit heavy and tedious, but the newest version (Struts 2) blends the robustness of Struts with the benefits of WebWork and many lessons learned from the Rails framework.

Webwork: liked

  • A simple, mature, and lightweight framework. Configuration can be arduous. Development has merged with Struts and benefits from the experience and community of that project.

Rails: liked

  • Rails favors convention over configuration and goes a long way to making web application development simpler. However, it is still immature and lacks the breadth of features of Java web application frameworks.
Stripes Spring: MVC: didn’t like

  • Overly complex, too much configuration outside the code.

Struts 1: didn’t like

  • Hamstrung by the backward compatibility requirements.

WebWork / Struts 2: didn’t like

  • WebWork learned a lot from Struts 1, but still suffers from configuration pain.
Struts 1* Spring MVC: didn’t like

  • Overly complex, too much configuration outside the code.

WebWork / Struts 2: didn’t like

  • WebWork learned a lot from Struts 1, but still suffers from configuration pain.

Stripes: liked

  • Excellent framework, clean and simple, it simply keeps out of the way.
Struts 2* (WebWork) Spring MVC: liked

  • Respectable effort that no one should be ashamed of using.

Stripes: liked

  • Very compelling. Either would be a good choice for a project getting a fresh start.

Wicket: liked

  • Very compelling. Either would be a good choice for a project getting a fresh start.

JSF: didn’t like

  • is the EJB of web frameworks. Cool in theory. Hell in practice.
Wicket Spring: liked

  • I use it to configure my entire middle-tier, and it allows me to operate many similar sites by overriding pieces of configuration that may be different for that particular site.  I’ve also used it for configuring custom back-office applications based on many components that I wrote, and wired together via Spring.

Tapestry: didn’t like

  • Worked with it for two years on an enterprise project at work.  It had absolutely no transparency as to what was going on underneath the covers.  It forced you to do things a certain way – the “HLS” way.  Everyone involved with the project seemed religiously addicted to it, and only to doing it the “HLS” way, like he was a deity.  It forced tons of configuration on you.  Every release is a complete rewrite, and backwards-compatibility is constantly thrown out the window to suit the author’s current whims.  The learning curve is extremely steep.  I hear that version 4 is better, but I gave it up with version 3.

Trails: didn’t like

  • Didn’t try very hard. Couldn’t ever really get it to work well, although with more effort, that would’ve likely changed.  Did not like Tapestry, so did not pursue further.
Shale* Spring MVC: liked

  • Cool, nice glue code, but there is a little overlap in Shale’s dialog and Spring Web-Flow (their JSF-version).
Rails No information available.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

What is the future of this project? What’s coming that will ease development?

This is the full response. For a summary of the response, click here.

Project Response
MyFaces The JSF 2.0 community is writing the new JSR 314. Interested parties can find it here: http://jcp.org/en/jsr/detail?id=314. This effort solves a number of the problems addressed in other questions.

Some artifacts from Shale will probably make it into JSF 2.0. For instance, there are the Shale-Tiger extensions that allow the usage of annotations to register a managed bean.
JBoss SEAM Developers are simplifying this project by separating the add-on parts. It is also related to the  new JSR Web Beans. For more information, see http://jcp.org/en/jsr/detail?id=299.
Spring MVC Spring MVC continues to benefit from the improvements made to the core Spring framework. Future improvements include easier configuration and better validation.
Stripes There has been an expansion of the developer base recently to ensure that Stripes continues to be in a position to respond to the community’s requests. However, the community plans no major architectural changes. Users can adopt Stripes confident in the knowledge that the codebase has stabilized.
Struts 1* Struts 1.x has a very limited future. Whilst officially new functionality is being added to the 1.x releases if backward compatibility can be maintained, in reality only very minor functionality improvements are being added. Having said this, bugfixes are still released. Thirdparty tools (eg XDoclet, IDE support) are mature and unlikely to offer any significant changes from the functionality offered today.
Struts 2* (WebWork) No information available.
Wicket The community plans to improve scalability, and provide better support for stateless applications. A full Java 1.5 version of Wicket is planned (current version works on 1.5, of course, but does not take advantage of 1.5 features so that 1.4 projects can still use it). Additionally, more tightly-integrated support for Spring and role-based authorization is in the works. Manning Early Access Program publishers released a Wicket-in-Action in July 2007.
Shale* Some artifacts from Shale will probably make it into JSF 2.0. For instance, there are the Shale-Tiger extensions that allow the usage of annotations to register a managed bean.
Rails Rails 2.0 is expected to be released by the end of 2007. It will make REST-based web application development even easier. It will also provide improvements in these areas: performance, security, formatting content for multiple clients (e.g., iPhone and Atom readers), testing, database schema migrations, XML handling, debugging, plug-in processing, and much more.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Are there myths about this project that you’d like to challenge?

This is the full response. For a summary of the response, click here.

Project Response
MyFaces No information available.
JBoss SEAM Some developers think that JBoss SEAM is a J2EE standard, but it is not. It is developed on top of two important J2EE standards, namely, JSF and EJB 3.0.
Spring MVC Spring MVC and Spring WebFlow are sometimes seen as competing projects. Spring WebFlow is actually complimentary in that it solves a particular problem with long web conversations.
Stripes Stripes (like many other good frameworks) was started by one person, Tim Fennell, and concerns have been raised about it being a “one man band”. Earlier this year Tim stated that he wanted to open the framework up to more developers, his reasoning was so that Stripes could continue to grow. Stripes now has a very helpful and constructive user and development community.
Struts 1* Developers think they need to use AJAX in their application and think that older frameworks like Struts have no support for AJAX. This is a myth, any framework can integrate with AJAX, see http://wiki.apache.org/struts/AjaxStruts for details on how AJAX interacts with a server side implementation based on Struts. It should be noted that existing applications written on Struts should not be ported to a newer framework purely in order to add AJAX using some AJAX support from another framework.

Developers also think that they will be required to use JSPs. Struts, like all popular frameworks, uses JSP as the default templating engine. It is possible to use Struts tags with both Freemarker ( http://cwiki.apache.org/WW/freemarker-tags.html) and Velocity ( http://cwiki.apache.org/WW/velocity-tags.html).
Struts 2 (WebWork) No information available.
Wicket All of the URLs are ugly.  This is easily configured.  Developers can literally do whatever they want with the URLs to fit the project’s needs.

That this framework is an infant version of Tapestry.  Wicket supports so many things out-of-the-box, and is a very mature framework in that “it just works” and has few bugs.  It has excellent AJAX support, again, out-of-the-box.
Shale* Developers think that Shale is a JSF implementation, but it’s not. It is a lightweight framework on-top of JSF.
Rails Some people think that Rails is all about code generation. Although code generation in Rails, called “scaffolding”, is convenient, that’s really just a tiny fraction of a very robust package. Code generation gets you started quickly and lets new Rails users learn how the basics work, but in most cases the generated code will be replaced by hand-written code one method at a time. This makes sure your application is always ready to run and test while you’re implementing it.

*More information on the relationship between Struts, Shale and WebWork.

Return to the questions list.

Struts, Shale and WebWork

In the early 2000’s, WebWork broke off from Apache Struts 1. In 2006, WebWork 2.2 was pulled back in to the Apache Struts project and became Struts 2. Shortly thereafter, development on WebWork ceased. All releases after after 2.2 consist of patches. Active development is taking place on the Struts 2 code base.

Shale also began life as an Apache Struts subproject. Based on the JSF standard (which did not exist when Struts 1 development commenced in 2000), the Shale project broke off on its own in late 2006.

A word about the relationship between Struts, WebWork and Shale in the OLEX Library. Although the entries in this table are organized into Struts 1 and Struts 2/Webwork, downloadable code in the OLEX library is organized differently. Under the Struts project, you will find Struts versions 1.0.2 through 2.0.9, and under the Webwork project you will find versions 2.1.7 through 2.2.4. OpenLogic policy is to offer all of a project’s versions – regardless of the significance of the changes – together. Project developers, when asked to answer our ‘Sweet Spot’ questions, found it more natural to talk about in terms of Struts 1 and WebWork/Struts 2 given that the code bases are so closely related.

For access to Struts 1 and Struts 2 code lines in the OLEX library, search for Struts. WebWork code is kept under the WebWork project.

Acknowledgments

OpenLogic would like to thank the following members of the OpenLogic Expert Community for their contributions to this effort and invite the community to email us (docs-at-openlogic-dot-com) if they’d like to augment, correct, update, refute or dispute any of the information included herein.

Project Contributer
JSF/MyFaces Gurkan Erdogdu
JBoss SEAM Gurkan Erdogdu
Spring MVC Andres March
Stripes Dmitri Colebatch
Struts 1 Dmitri Colebatch
Struts 2 (Webwork) James House
Wicket Jeremy Thompson
Shale Mathias Wessendorf
Rails Internal Expertise

Related OLEX Packages: jboss-seam, myfaces, rails, shale, spring, struts, webwork, wicket
Kimberly McClintock

Kimberly McClintock
Kimberly is absolutely fabulous, in every way. Before striking out on her own to pursue a career in writing, she led the technical writing team at OpenLogic that's responsible for all technical content on the OLEX site, as well as the the selection, editing, coordination, and management of content here at Wazi. She's developed content for lots of different audiences - teachers and students and salespeople, to name a few - over the course of her career, but nothing's been as much fun as writing about Open Source. She's a heckuva cook, has an enormously varied vocabulary, and you might justifiably be fearful of her dog, a big girl named Lola.
All posts by Kimberly McClintock

2 Responses »

  1. JSF sucks « Incremental Operations on October 20th, 2009 at 10:02 pm:

    [...] Web Framework Project Comparison Matrix – quote: Users say, JSF “is the EJB of web frameworks. Cool in theory. Hell in [...]

  2. CRUD with Wicket + Guice + Db4o / NeoDatis « Find Time for the Karussell on January 20th, 2010 at 6:55 pm:

    [...] requires pure Eclipse development, I guess. So what else? There are a lot of Java web frameworks (with Ajax) as I discovered earlier. My choice now was simple: Wicket, which is Swing for the web. But what if [...]

Leave a Reply