The main aim of MVC design pattern is to separate the business logic and data (the Model) from the display logic (the View).

Ideally, the Model should have no idea of what displays its data (and how that data is displayed) as there can potentially be numerous different views. The View in its turn should have no idea of where the data it displays come from, as data can potentially come from just anywhere.

It is for the piece of code named Controller to ensure that a correct piece of data was sent for processing to the Model and that the result of that processing was forwarded to a proper view.

Struts and similar frameworks came with their own views, typically implemented as JSP pages, and their controllers, implemented as Action classes. As for the model, it is implemented elsewhere - maybe as an Enterprise JavaBeans application or perhaps something more lightweight.

Struts have also provided a number of convenient solutions for the most common tasks of Web development, and as a result, this framework became enormously popular. Currently, Struts is a de facto standard of a Java Web framework. However if you follow the trends of the Java world, you might know that although Struts is the present of the mainstream Java Web development, it is not widely considered as its future.

The main problem with Struts is that it is still a somewhat low level solution. It still leaves the developer writing a lot of code, and often that code solves some basic repeating tasks. The future belongs to component-based frameworks because with them one could write much less code and encapsulate significant pieces of logic into easily reusable components. At the extreme, a component-based framework could allow developers to simply assemble a web application from the existing components, only changing a few parameters of those components as required.

The other downside of Struts is that it uses JSP for its views. Yes, one could use a different display technology, such as Apache Velocity, but JSP is the default and the most widely used option, with all its inherent weaknesses.

In fact, one can still use scriptlets in Struts views, and many developers do use them because this looks to them like a simpler solution. The later versions of JSP even have a special setting that allows programmers to ban the use of scriptlets in the application - an administrative measure in software technology!

Also, although seasoned Struts developers will probably disagree with me, Struts introduces a rather unnatural view of a Web application. Normally - say, for users - a Web application looks like a set of pages. They read the content of a page or play with it, then go to another page and so on. From the Struts point of view however, a Web application is a set of actions that users initiate. Pages are only the results of those actions.

This doesn't seem like a huge issue, but from my point of view, this action-centered thinking makes it difficult for many Struts developers to understand a newer framework - more about this later.

So what do the new component-based frameworks bring with them? Most significantly,  a sharp increase in development productivity. My current rough estimate is that one week of Tapestry development is approximately equal to one month of Struts development, in terms of which part of the whole project gets completed in this time. And the more projects are built by the team, the less time the next project will take, just because of reuse of already created custom components.

Also, simply because less code is being written, the applications developed with new frameworks have less errors and are easier to maintain.

I would say that the three most widely known contemporary component-based Java Web frameworks are JavaServer Faces (with its different variants), WebWork and Tapestry. Comparing them all clearly goes out of the scope of this article (I have written a whole Masters dissertation on this; have a look if you are curious: http://sundraw.ws/assets/TapestryDissertation.pdf), so let me simply explain why my choice is Tapestry.