Spring MVC, JavaFX , Google Web Toolkit and Struts2 - State of the (dis)Union.

by Paul Browne


My fellow Java Developers. Two years ago I wrote an article on 'Web 2.0 and Enterprise Java - move over Struts' looking at what was likely to replace Struts 1 (then and now a de facto web standard). How did our predictions fare?

Remember that article (and this one) isn't looking for technical best, but which is going to be a best investment of your time to learn (in a mercenary commercial sense). And if you're deciding which to use in a project , which framework is going to be easiest to support in 5 or 10 years time?


Broadly speaking, the frameworks we talk about break into two types: those that treat the web as a set of pages, and those that treat the web as a set of components (think Visual Basic, Delphi or Oracle Forms act-a-likes).

So , what has changed in the last 2 years:



  1. The rise of Spring. Not only has it gone mainstream, but the Spring MVC, Spring Webflow and Spring-JavaServerFaces are very powerful and widely used web frameworks. A sign of how things have changed is that for Sruts 1 the Spring guys wrote the integration for the (then) bigger Struts framework. For Struts 2 , the integration was provided by the Struts community. With the forthcoming Spring 3 release the framework is increasing momentum; More annotations and less XML in Spring MVC; Rest Web Services out of the box, support for Dynamic languages like Groovy and Spring Webflow becoming a more 'just use it where you need it' solution.
  2. Adobe Flex and OpenLaszlo - Flash graphical interfaces on the Web, built using Java. I don't think these will be *the* mainstream choice but I do think the will be more than a just a niche. And for design led companies, nothing else (not even Microsoft Silverlight) can come close in terms of a user 'wow' factor.
  3. JavaFX and Applets done right (Jim Weaver has a good article on this). More of a competitor to Adobe Flash as both are rich content in the browser using an easily obtainable plugin. JavaFX will appeal to developers because of it's Java like syntax. I hope I'm wrong, but for rich web content, would you put your money on Sun (an Engineering led company) or Adobe (an almost apple-like design led one)?
  4. Frustration with JSF (Java Server Faces). For the last 3 years I've thought that '*this* is the year of JSF. I'm still waiting not because of lack of demand (as web apps become more complicated and use more Ajax they become more like the JSF component based model). It's now uphill for JSF as I (and a lot of other Developers) have given up. I'm still waiting for the 'EJB 3' moment when JSF becomes more simple and more usable. Remember , we 're not talking about technically best, but which is going to be in widespread use.
  5. Google Web Toolkit (GWT). Looking at it one way , GWT is JSF done right - a component based web framework , but one that is fast and has a lot of community support. Even then it took me a long while to warm to GWT - I've bad memories of web-components that hide their internals (remember Microsoft Interdev 10 years ago?) . What got me over the hump was thinking of GWT as a compiler not to Assembly or bytecode , but to Javascript and HTML.



How has Struts 2 got on in the meantime? I'm not sure. Remember , Struts 2 is very different from Struts 1. Conceptually it's very similar to Spring MVC (Simple Java Beans based with configuration); Slightly easier to learn and maybe slightly less powerful than Spring (although both are more than capable for most Enterprise web applications.


The 'I'm not sure' bit comes from two (non technical) factors:



  1. Struts 2 hasn't achieved the massive Enterprise developer mind share that Struts 1 did. It's a better framework, but it's got more competition.
  2. If you're using Spring in the middle tier, why not have one less framework and use Spring MVC (instead of Struts 2) in the presentation layer as well?


Back to the previous predictions , how did we get on?


Scenario 1: Adding Ajax to existing Struts Applications. Use AjaxAnywhere - closest to the approach taken in the article Sprinkle Some Ajax Magic into your Struts Web Application. Despite writing this article , I see the frameworks evolving rapidly to the point where you would only take such an approach for adding Ajax to ‘Legacy’ applications.


How did we do? I'd maybe widen the choice of Ajax Libraries (to include DWR , Dojo, Prototype and others) but the basic idea of evolving rather than replacing your Struts 1 app still holds true.


Scenario 2: Need Ajax Now for a new Java Application. Use Appfuse as it gives Struts, Ajax (with DWR) and the possiblity of JSF integration now, all ‘out of the box’.


How did we do? I still recommend AppFuse, as it combines (name-your-web-framework) with Spring Hibernate(and other ORM) and Maven. However I'd now tend towards choosing Spring MVC (unless you've a reason to use Spring 2), given that you're probably already using Spring in the mid tier.


Scenario 3: Medium Term. Use an implementation of JSF (either MyFaces or whatever Appfuse promotes - probably Struts Shale). Struts Shale (JSF) has so far released only ‘overnight’ builds. Apache MyFaces (JSF) tool support and Ajax capabilities are likely to improve over time. Both Struts-Shale and MyFaces are likely to play well with AppFuse , making it a safe bet for investing your time checking it out.


How did we do? Struts2 and Spring both still give you migration route to JSF. But do you want it?


So out of the creative ajax-induced chaos of 2 years ago, I see 4 or 5 clear choices in Enterprise web frameworks: Struts 2 (as a follow on from Struts 1). Spring MVC, due to the huge mindshare Spring has on the mid-tier. Google Web Toolkit , both as a natural home of frustrated JSF developers , and because who's going to argue with the people who gave us maps and mail? Flex, because Flash apps done well just look so good. And JavaFX, because Applets-haven't-gone-away-you-know.


In my view, we would have been delighted to have any of these framworks 5 years ago. And each (for different reasons) is likely still to be popular in 5 years time. Your missions now is to pick the one that suits your project needs.



47 Comments

Yeti
2008-03-12 03:26:03
The one framework that I think will be the rising star for the coming years is one that is not mentioned in the article. It's name is Wicket!


IMHO it is a component framework that is by far a lot easier to understand than any of the above (especially JSF).


And since it has been adopted by Apache I think it will gain a lot of support in the Java community.

lunatix
2008-03-12 03:53:29
hum, try wicket, just once and you'll think that wicket is jsf done right. Simple, object oriented, simple, component framework, and simple :D
Paul Browne - Firstpartners blog
2008-03-12 03:55:45
@Yeti


Thanks for reminding me of Wicket - it's one that I've heard a lot about, from people whose opinion I respect. The reason it's not on the list is that while it's technically strong (and very easy to use) I'm not sure of the traction it has (yet) in the Enterprise.


I am willing to be proved wrong, especially when the job ads start saying 'must have x years Wicket experience) :-)


Paul


Andy Yates
2008-03-12 04:24:45
I'm surprised that you didn't mention anything about Wicket. In my opinion I feel Wicket represents the culmination of the JSF backlash rather than GWT and is closer to the original aims of JSF than GWT is. Just one man's opinion ;-)
Andy Yates
2008-03-12 04:25:46
Doh should have refreshed the page before posting my comment :)
seam guy
2008-03-12 04:35:55
another framework that's worked for us is jboss seam.
Sgt Garcia
2008-03-12 05:03:29
To be the best "request oriented" web framework is not Struts nor Spring MVC, but Stripes!


As @lunatix said it earlier, for "component oriented" web framework Wicket is JSF done right, for "request oriented" web framework Stripes is Struts 2 done right.

Paul Browne - Firstpartners blog
2008-03-12 05:03:42
@Seam Guy


Seam suffers (unfairly) from the the perception that it is a 'JBoss only' technology (for the record it *does* work well with other Web and App servers). If you're using JBoss Technologies like workflow (jBPM) and Rules (JBoss Drools0)then it is *very* compelling technology to glue them together with Hibernate and the Web.


Like Wicket, the downside (in my opinion) is traction in the Enterprise.


Paul

Renaud Bruyeron
2008-03-12 05:05:37

imho, struts 2, wicket, stripes, tapestry and all the competitors are destined to remain fringe players. The market is fragmented, the big players are betting on JSF, but JSF is currently not simple and productive enough. JSF2 is meant to fix this but it is not final.


Here's what I think will happen: JSF2 delivers 80% of what it needs to be, and the market slowly moves there. All the other frameworks remain marginal.


In the mean time, I recommend stripes: small, tight and productive, with tiny learning curve (for former struts1 developers): this means I am not taking a huge risk. Tapestry5 and wicket are technically fascinating, but the investment required to train dev teams make them too big a risk in 2008. As for struts2, why bother? It does not buy me anything over stripes, and it is harder to learn / less focused.

Peter
2008-03-12 06:25:33
Wicket is the best web framework. Believe me, Paul.
Scott
2008-03-12 06:50:55
I've just started working with stripes and I think it's great. I've written Struts and JSF applications, but I still prefer the request based frameworks. Going from struts to stripes was easy, and It's easy to be productive using stripes.
sidewinder
2008-03-12 07:03:48
Tapestry 5, Grails, Wicket and Stripes are the best ones, easy and simple, well designed, nice communities.


If I want component based Tapestry 5 or Wicket.
If I want action based Grails or Stripes.


For the middleware and back end Spring and Hibernate are the way to go.

logrus
2008-03-12 08:37:04
I tried Wicked, and I had the feeling that the ideas were good, but the implementation was bad. Just look in its FAQ at the horrible hacks it needs to play well with Spring for example, or ajax...
On the other hand, the Click framework seems to be "wicket done right" : lighter, easier, and more easily integrated with Spring.
As usual, YMMV :)


Anyway, my web framework of choice is still Spring MVC.

David WIESZTAL
2008-03-12 10:51:13
Hi Paul,


Good to read you again. Hope you are well !


It's a pity you have not spoken of framework that are 'JSF done right' (as you said) but without the known limitations of GWT. I mean echo2-like framework.


By the way, my feeling is that JSF (and any framework supporting it), despite all the good reasons not to use it, will lead the market. Because it is supported by major big vendors, has specifications, and because big companies like big vendors and are highly influenced by notoriety. And if you want to be bankable, you won't escape this trend.



Eelco Hillenius
2008-03-12 14:48:48
What 'horrible hacks' are you talking about logrus?


You configure Spring for Wicket by adding this line to your application class' init method: addComponentInstantiationListener(new SpringComponentInjector(this)); and then you just use @SpringBean annotations wherever you want a dependency to be injected.


And Ajax is pretty straightforward as well. There are catches and workarounds for them, but that's not for straightforward cases.

Eelco Hillenius
2008-03-12 14:55:17
JSF is - despite all the good intentions behind it and some good people trying to uplift it - a good example of a JSR stifling competition. It would have died long ago, or at least have a marginal following, without the big vendors backing it, and that would have cleared the way the alternatives to gain more momentum (which *could* have resulted in more funding, more people working on it, better IDE support, etc).
Eelco Hillenius
2008-03-12 15:01:46
And while I'm being defensive logrus, saying that Click is 'the better Wicket' is a bit funny. Component reuse and clean templates are core ideas in Wicket, whereas Click (supports template scripting and does not support self contained components like WIcket does) is more focussed on delivering a framework that is minimal and quick to work with. Both frameworks are fine, but they're quite different. JSF and Wicket are closer related, as both focus on reusable components (though Wicket stresses easy authoring whereas JSF focusses on easy using of those).
Carlos Scheidecker
2008-03-12 16:49:56
Dear Mr Browne,


All very good, thanks for this article. However you forgot to mention a framework I have been working with and is getting some momentum : Apache Wicket. An important framework I would say. It allows you to write a websystem without messing with XML config files and Javascript but provides AJAX functionality and it is just beautiful from a software developer perspective.


As for OpenLaszlo, I have been developing applications with it since 2004 and the new version 4 allows for a DHTML interface instead of SWF. Amazingly, it provides the same look and feel as Flash. I love OpenLaszlo. It is better than Flex in my opinion and easier to use as well.


kind regards,


Carlos Scheidecker.

Paul Browne - First Partners blog
2008-03-13 01:53:52
@Everybody


I'm jealous of the people that get to use Wicket / Stripes / Curve / Click or other such framework. One of more of these frameworks may / will make it mass market with widespread enterprise adoption - in the same way Struts1 gained underground developer momentum before coming to the attention of the business types.


However I can't learn *all* of these frameworks, so I'm going to have to choose. And what I'm going to spend time learning isn't the technical best (that discussion would go on for a *long* time) but which one is likely to pay me in terms of future work. Boring, but pays the rent! Hence the choice of Struts2 / Spring MVC / GWT / Flex and (keep an eye on) JavaFX.


Two specific comments about Lazslo and JSF. JSF (or rather the component based approach behind JSF) I want to succeed as it solves the web-app-complexity problem. However, there is a lot of negative sentiment towards JSF-as-a-brand-name, so I think it will be GWT, Spring or 'JSF2' that becomes a defacto component based web standard.


OpenLaszlo I like, not only because it gives me a choice of DHTML or Flash rendering. My choice of Flex in the summary was because of the additional (paid) tools that Adobe provides. If you're doing flash you want it because it looks *cool* and the Adobe tools help you with this.


All of this is mainly *opinion* and I've been wrong before :-)


Paul

Artur Karazniewicz
2008-03-13 06:48:05
Paul,


I'm really surprised with Your analysis... struts2 isn't just new kid in the block. You haven't mentioned WebWork which Struts2 is based upon. WebWork is excellent framework, used for Years now, rock solid, stable and feature reach. It's not that Spring2 is new thing, and doomed to be niche. Look at Atlassian products, most of them is based on WebWork. I myself worked on Enterprise projects based on WebWork and only thing I can say about WebWork (nowe Struts2) is that's the very best framework I've been using for Years.


Also I'm really supprised that anyone looking for something which is "Component" based. For me "Component" frameworks based on HTTP and HTML are doomed to fail, badly. Not HTML nor HTTP is supposed to support frameworks like JSF or ASP.NET very good. Sure developers of those frameworks work hard to hide all the gory details of HTTP nature. Also HTML is really *bad* thing to create "components" as we know from GUI frameworks. It's even really hard to place elements You expect (it's more or less possible recently, but As You can see ACID conformance, hardly usable).


The last thing is, most surprising, that with "component" frameworks, we encourage *Developers* to provide *User Interface*. Show me one, proffessional web design, designed by Backend Devloper... Sure it's appealing that Developer can click, drag and drop, component on the page, wire database etc. But and the end of the day, Enterprise expects something what is pixel accurate, corporate standards compliant and in line with overall corporate Web look and feel. I work for company for which Web Standards guidelines have almost 100 pages, and Yes it mentions pixels, layouts, fonts and styles. I cannot even imagine that anybody in serious company could expose client facing .NET application, without heavy UI redesign. And, in the case "readymade" "component" frameworks it happens to be serious pain... Covince You Web Designer to use Visual Studio as their HTML Editor, instead of Aptana or something...

jimothy
2008-03-13 07:17:43
Just as Struts 2 != Struts 1, Spring MVC != Spring. So, whether you use Spring + Spring MVC or Spring + Struts 2, you're still using two frameworks, so "why not have one less framework and use Spring MVC (instead of Struts 2)" is not a valid point.


Struts 2 integrates beautifully with Spring; better, in fact, that Spring MVC does, because it does so automatically, without all the configuration hassle of Spring MVC.


Spring proper is a wonderful framework, but you make two dangerous leaps of faith. The first is that Spring MVC is as useful as Spring proper simply because it shares the brand name. The second is that Struts 2 integration with Spring isn't as good because it does not share the brand name.

Paul Browne - FirstPartners blog
2008-03-13 08:43:29
@Artur : Re Struts2 and Webwork: this blogpost doesn't state the Struts2-Webwork relationship clearly, but one of the linked articles does. Sorry for any confusion. My interest in component-frameworks on the web is that I was a Visual Basic programmer in a previous life, and I'm still hoping / waiting for something as productive in the Java world.


@jimothy: You are correct (that Spring MVC and Spring are 2 frameworks, not one). But if names weren't so important, why is Webwork (3?) called Struts 2? :-)


jimothy
2008-03-13 09:28:09
You're right that names are important, and that's unfortunate. I consider the Struts name both an asset and a liability to Struts 2: On the plus side, Struts has a lot of name recognition and mindset, but Struts 1, as good as it was for it's time, has some rather poor design features (which Spring MVC gleefully copied). Thus, some developers and managers may be unfairly biases against Struts 2, especially those who never used or heard of WebWork (name recognition is, again, important).


Likewise, people learn how Spring can simplify their code, and they assume that Spring MVC must, therefore, do the same for web development. In my experience, the result is the exact opposite. Spring MVC takes all that was wrong with Struts 1, and adds heaps more XML and a gazillion confusingly named Controller implementations, including a SimpleFormController that is anything but simple.


I haven't yet used Stripes, but if you want an action based web framework that integrates fantastically with Spring, drop Spring MVC and take a look at Struts 2.

jimothy
2008-03-13 09:45:47
P.S. By "rather poor designs features" of Struts 1, I refer primarily to choice of making Actions singletons, which required a separate ActionForm bean. As I've read the history of Struts 1, WebWork, and Struts 2, much of it written by the members of this list, I see that they've acknowledge the drawbacks of that approach and have learned from it. By no means did I mean to disparage the Struts 1 team. The nature of software is that it gets better with time as we refine our designs.


That said, it's interesting that the Spring MVC team decided not to learn from, and instead repeat, this mistake.

saber
2008-03-13 10:00:07
I have to agree with jimothy on this one. Where Struts2 is elegent and simple to use, SpringMVC is mind numbingly convoluted (though I think 'gazillion confusingly named Controller implementations' is actually understating the fact'). What I like about Struts is that most of the code you write for most webapps is pretty straightforward. Struts2 is designed in such a way that implementing all the simple stuff is simple. If you have exceptional functionality that you need to implement, Struts2 has ways for you to do it. With SpringMVC even the simple stuff is complicated. jimothy mentioned the SimpleFormController - what a overly engineered mess that class is. There are too many similarly named methods to override.
Keith Donald
2008-03-13 11:16:10
People, have you not seen Spring MVC 2.5, out since November already? The annotated @Controller model is quite elegant and fully replaces the old hierarchy of SimpleFormController and company. Please consider the latest production version of Spring MVC before making such statements!
Diego Fernández
2008-03-13 18:28:02
I have another prediction for you: dynamic languages.


A lot of developers are frustrated with the current state of Java, and there is more and more developers interested in dynamic languages like Ruby, Groovy, Python, and even Smalltalk (from the technical point of view, Seaside is the best web framework that I saw).


You could use Ruby on Rails in JRuby, deploy apps. to a J2EE app server, and use EJB, so my prediction for the next 5 years: the most popular web framework is going to be based on a dynamic language.
Today they are ignored at enterprise level, but is just a matter of time (and tools).

sidewinder
2008-03-13 21:28:21
I'm more fan of Tapestry, Wicket or Spring MVC but take a look at JSF 1.2 with Icefaces is not bad and the coming JSF 2.0 spec looks very promising. I think in the end JSF will take the lead it is where the big ones are investing, But the cleaver people will realize that Wicket or Tapestry, Stripes or even Struts2 have more value and pragmatic approach. Or as Diego Fernández said take a look at Grails with Groovy or Turbogears with Python are also very good web frameworks and easy with scripting languages.


I'm fan of Ajax is cool but not of Flex, lazslo or JavaFX. It is a mess to require to the end user install plugin's, it creates a mess as the old idea of applets, I think the RIA with Flex and friends is a horrible way to RIA approach, it's bloated and bad designed.

Eelco Hillenius
2008-03-15 02:44:47
> For me "Component" frameworks based on HTTP and HTML are doomed to fail, badly.


No they are not, and they have been proving this for years now. Components fit UIs neatly, and web frameworks trying to provide a similar programming model as for desktop applications is comparable to Object Relational Mapping frameworks (remember how many people used to say how such frameworks, like Hibernate, were doomed to fail).


Read what component oriented frameworks try to solve in the free first chapter of Wicket In Action, which you can get here http://www.manning.com/dashorst/.

saber
2008-03-15 21:12:10
I can see some people being interested in the Groovy or GRuby approach to Java, but I can't see it in medium to large companies that use java. In my experience, it's hard enough to find good java developers, but to start looking for java developers who also program in Groovy or Ruby or whatever, you might be asking for trouble. I think the maintenance aspect will slow adoption of these technologies. Plus, I don't see any large benefit that these languages would bring. Faster development? Development is already slowed down in medium to large companies due to all the overhead; I don't think that Groovy is really going to help speed things along any faster.
roosevelt
2008-03-17 00:21:57
Forget about java and j2ee, take a look at ruby on rails, play with it. You will know where the future is.
Paul Browne - First Partners blog
2008-03-17 14:54:33
@Vincent


5 days before somebody mentions Ruby on Rails :-)


I have looked at Ruby on Rails and it does fill a niche. While there is some overlap with Enterprise Java they are trying to solve two different sized problems.


*If* you are interested in Ruby / Dynamic languages in the Enterprise I'd suggest that JRuby or even the more Java like syntax of Grails is more likely to breakthrough into the mainstream - mainly as they can reuse the existing infrastructure and not start from scratch.


Paul

nikita
2008-03-18 01:20:27
I have to agree with numerous comments already posted - I find it difficult to believe that Wicket wasn't on the above list. After working with JSF for some time, switching to Wicket was such a breath of fresh air. A really well thought-out and executed framework.
stephdavid
2008-03-23 12:14:05
As a front-end developer, RSF (Reasonable Server Faces) is very appealing, as it gives me a certain independence from the middle Java tier and no "tag soup" - a grab bag mixture of tag libs, components and other foreign elements in my semantic HTML. I also believe it offers the Java developer freedom from the front end. Have a look at http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=Main


Anyone care to comment on possible trade offs for the middle-tier role?

Thiago Souza
2008-03-25 20:08:49
Wicket sux, Struts sux, JSF sux, Spring MVC sux, Tapestry sux, Grails sux, they are all legacy and suck. Long live to GWT!!!!
Angel
2008-03-26 07:07:42
We are talking about developers, but users are more important.
Web applications have problems: request, session, parameters, attributes, replication, cluster, webcache, poor interfaces, http errors (500...).
I think that returned the concept client-server applications. The new in this case is SWT/JFace, Rich clients.
Future will Eclipse RCP. See Lotus software for example Symphony. They go to the right path.
That's all folks!
simon
2008-03-26 07:22:24
you missed out ZK which is blows away the other web2 frameworks that you mentioned.
Jonathan Locke
2008-03-30 13:49:05
RE Wicket "Enterprise Traction", I know of several fortune 500 companies (including banks, who get some particularly enviable security advantages from Wicket) using Wicket and dozens upon dozens of mid-sized companies and VC backed startups. In addition, I know of sites with >10M users that are switching to Wicket because of its maintainability characteristics.


As far as the job listings metric goes, I wouldn't put too much faith in that as a measurement of traction. I happen to know that NOT ONE of these companies ever posted a job listing for Wicket. And companies may never do that. The reason is simple: you don't need to know Wicket to be a successful Wicket programmer. If you are a good Java programmer or even just a good OO programmer (.NET, SmallTalk, Objective C, whatever), you will find Wicket a breeze. The whole point of Wicket is to move away from do much "programming by configuration" and "programming by convention" to something that is really just a bunch of dirt simple objects and design patterns. Don't hire Wicket programmers. Hire good OO programmers with real domain problem analysis skills.


Jonathan


Son
2008-04-01 10:02:20
I personally like Wicket a lot. I am very new to web-development, yet I can easily create complex components. My biggest challenge, and one that I think is common in large companies, is trying to integrate Wicket with the legacy web-frameworks/authentication systems built in-house. Without this step, there is no way to nicely transition to Wicket. However, once that hurdle is crossed, I believe Wicket to be an easy sale.
Peter Thomas
2008-04-04 04:35:27
>> My biggest challenge, and one that I think is common in large
>> companies, is trying to integrate Wicket with the legacy
>> web-frameworks/authentication systems built in-house


You would have the same problem with *any* framework - so it is not really a problem with Wicket right?


I would go so far as to say as it should be *easier* with Wicket because you can wire up things in pure Java. Just extend a couple of classes, or write some nifty code as your IAuthorizationStrategy implementation and you are done. I have successfully integrated Wicket with Acegi and even plugged in custom code for cookie-handling, no problem at all. Let me know if you need more details and I can share code. More details here:


http://ptrthomas.wordpress.com/2007/03/02/wicket-impressions-moving-from-spring-mvc-webflow/

Lawrie
2008-05-14 02:13:28
Nice article. So far, I have found Struts2 (WebWork), DWR, SiteMesh, Spring and iBatis to be the best combination (for me) - there's nice extra libs like DisplayTag (data tables), overlib (popups). All these make time-to-implementation very quick. Spring is used to handle iBatis and transactions calls.


Its hard to find a good set of rich components (that are easy to implement and 'work') - JSF doesn't do it for me (but I've heard JBoss SEAM makes JSF much easier). Flex and OpenLaszlo look good for rich components, but I went the YUI route (but development becomes for involved when the ui becomes more complex). Still, YUI is flexible and very capable.


I liked Spring MVC, but contrary to your article, I think Struts2 has more functionality to offer. Spring MVC is catching up with Struts2, not the other way around. Shame to call what is essentially revised WebWork; 'Struts2'. If you mention Struts2 to anyone, the response is 'Struts is dead'. Many people can't look passed the name, which hinders adoption. A VERY bad move by the Apache group!


For me, Struts2 has always been comfortable and familiar to work with - it allows me to think of the business logic implementation, rather than get tangled up in framework learning and querks. You can use as much or as little of the framework as you like. If the ui components were more like flex, yui or OpenLaszlo; Struts2 would lead the market, and that would be a beautiful thing.

Peter Thomas
2008-05-14 20:57:07
@Lawrie - what if you could condense the UI 'stack' you are currently using:
- HTML
- JavaScript
- JSP / JSP-EL
- Struts2
- DWR
- DisplayTag
- SiteMesh


into something much simpler: HTML + Wicket ;)

Lawrie
2008-05-16 03:36:17
@Peter - Could I, just the UI part? Wicket & Struts2 together? Or is it a case dumping Struts2 for Wicket. Wicket does look nice and simple. If I can do that - then I would consider it. Otherwise - I don't see the need to move onto another framework to get a nice frontend.
Lawrie
2008-05-16 05:08:27
Additional - I don't think the Wicket UI components have enough 'wow' when compared to YUI, OpenLaszlo & Flex.
Peter Thomas
2008-05-16 22:15:13
>> Could I, just the UI part? Wicket & Struts2 together?
>> Or is it a case dumping Struts2 for Wicket.


You can replace Struts2 with Wicket (yes, just the UI part). So you get rid of JSP / JSP-EL. You no longer need to hack JavaScript in your templates because Ajax partial updates to the DOM are driven through plain Java code. So no need for DWR either. SiteMesh is just a workaround to the lack of templating in JSP - Wicket has something called "markup inheritance" and compositing pages out of panels is natively supported. You can easily create dynamic tables by hand in Wicket (which I prefer) or use the readymade components in Wicket-Extensions so no need for DisplayTag.


>> I don't think the Wicket UI components have enough 'wow' when compared to YUI
I actually am using a couple of YUI components integrated with Wicket in a project. So if you really need some extra 'wow' nothing stops you from adding Dojo / Prototype etc in fact there are side projects that provide Wicket integration for these. But all your simple 'partial DOM update' needs can be fulfilled by Wicket core.


Since creating re-usable custom components is so easy - I rolled my own integration with the couple of YUI widgets I needed instead of using what the Wicket-YUI project offers.


You can have a look at the blog post link I posted a couple of comments above - for more thoughts.

Lawrie
2008-05-19 01:45:35
Thanks Peter - my interest is gathering...
Noah
2008-07-12 07:07:51
Thanks for this article! I read it about two months ago and it served as a really helpful starting point for my current project.


I ended up using Spring MVC and Flex together. I chose the former by following the line of reasoning you mentioned above - I was already using Spring core and JDBC for the mid-tier and persistence layer. However, Spring MVC's role in my architecture has been relegated to simply streaming XML responses to Flex HttpService requests. I don't use any Spring JSP tags, just some JSTL to quickly iterate JavaBean properties on result objects and shoot them back as XML. Basically, for me Spring MVC just "answers the phone" and its architectural pluses and minuses are irrelevant.


My cavalier approach to the web layer has everything to do with the fact that I'm using a rich Internet application (RIA) framework. I have to say, quite honestly, that Flex is awesome and has really raised the bar on web apps. It's not perfect but it's getting there and has a great dev team behind it. For any kind of non-trivial app, I'm not sure it makes sense any longer to settle for anything less than the interactivity that a RIA tool can provide. My litmus test for web frameworks is no long component vs. page flow, architecture, object-orientation, configuration vs. convention, prettiness of syntax, etc. - it's how rich and interactive a user experience can I provide, and how quickly can I do it? Haven't tried Laszlo or JavaFX yet but I have to say I'm a big buyer of Flex.


Thanks again for the great article!
-Noah