Platinum Partner
struts,webwork,jsf,spring mvc,seam,facelets,ajax4jsf

What server-side Java web framework will be the next for 2008?

Arguably, Struts 1.x is end of life. There are plenty of other Java server-side web frameworks: JSF (the standard), Wicket, Tapestry, Struts 2, Echo, Spring MVC, etc. Do you have any market data on what developers are adopting after Struts 1.x? If not, what is your gut feel? What will developers use in 2008 for new projects?

I asked my linkedin network this question and was surprised at how detailed the answers were. I share them now.

Will JSF ever esacpe the birth canal? Is there still a lot of life in Struts 1.x? Maybe these are the wrong question altogether. Perhaps 2008 will be the year of RIA via GWT, Flex + Java, JavaScript + REST, or?

Struts continues to do really well; it is still number 1. JSF did well in 2007. Let's put it this way: If job demand for the Struts framework and JSF were a stocks and you invested in it in April of 2005 by July of 2007 you would barely break even with Struts but with JSF your investment would have grown 700% as of July 2007. (According to

Names are withheld for privacy. Let me know if you want me to release your name.

No clue, but I'd go for Struts 2 or JSF, maybe Spring (MVC)

You probably can't go wrong if you pick the three most likely contenders. I prefer Spring MVC and JSF.

Where I used to work, many Java developers started using Ruby on Rails for web development. I have just recently started, and it is pretty nice. It takes some getting used to because it's focus is much more on conformance than configuration, but development is quick.

I worked for a hedge fund which used Java for all the trading applications, but when I left, there was a definite buzz around Ruby, with a few projects in the works.

Since Ruby can access any Java library via JRuby, that might be an alternative without having to migrate all your old code to another language.

Ummm... no comment.

In my opinion, current JSF implementations (1.1 or 1.2 spec) are not mature enough to be serious competitors. This might change when the JSF 2.0 spec (which addresses most of the issues with the 1.2 spec) is implemented. Spring MVC is too cumbersome in my opinion, as is Struts 2. So for now, I'd go with Wicket. Wicket is a very good choice, as it provides a clean seperation of view (clean HTML) and logic (POJO's). Also, it does not rely on XML-configuration. It's a good example of the 'less is more' concept.

But this is my personal opinion. Which is not necessarily the same as the opinion of my customers. From where I am standing (Dutch Financial and Public sectors) most of my customers are gearing towards JSF. Wicket is also rapidly gaining popularity, though not widely adopted yet. In the Financial sector, Portal and Portlet development is very popular, usually combined with Websphere or Oracle Portal.

I respond to this later below.

We currently use Struts 2 which has made a good effort at integrating Webwork into its codebase but has yet to go a while before documentation becomes easier. There are a few books starting to appear.

Personally, we love the choice of Struts 2 and are very happy with it.

However, I will let Matt Raible answer your question as per link below.



Good link. Thanks.

I think that JSF will take the lion's share of developers by virtue of being backed by Sun. Anyone who feels the need to move off Struts 1.x, and there will be some who'll hang around on it despite EOL, is likely to avoid the similar philosophy of Struts 2.

I also think that, as Mark mentioned, there will be some bleeding of developers to other languages entirely, namely Python and Ruby. Compounding this is the fact that these other languages allow you to do more with less while still providing mechanisms to integrate with Java. One of the big things that helps Java adoption is the ease with which one can make a program that works in Java. Though it may not necessarily work well, functional correctness is easily reached. I think with more options that make functional correctness even easier to achieve, some people will opt away from fully-Java solutions, or abandon Java entirely.

I'm biased, but I'd look to Ruby getting some major attention once a computationally fast Ruby interpreter is released; in terms of memory and install footprint it is very cheap and if the CPU utilization goes down it is a slam dunk for a language. Of course, a fast enough interpreter may never happen.

Python may always remain a niche language as it relies on syntactical features ( such as white-space expressed blocking ), that some people are dogmatically opposed to.

More people are using Python than Ruby according to Tiobe. There is also more job demmand for Python developers. But I mostly agree with this.

I think Spring MVC has a greater demand than Struts at the moment. Its more flexible than struts, however Struts 2 still has a strong following.

Frameworks also appearing for front end web app development I am using/have seen Echo 2, GWT, Open Lazslo, Ext Js (javascript front end).

I have ran into one company in the last four years that was sticking with Struts 1.x. I have not run into a single company that was using Struts on new applications. Most companies I ran into were switching to JSF or Spring MVC. Then again I work for a company that focuses on Spring, JPA/Hiberante and JSF so my experiences are somewhat skewed.

Dude.... Rails. on JRuby even.

Dude. No.

Well, it sure as heck won't be Cocoon...

I've been working with Ruby on Rails quite a bit, attending a couple of conferences and deploying enterprise-level applications both customer-facing and internal applications with various levels of success. I honestly believe that if the real RoR leaders can coalesce around what RoR can be and stop the amazing amount of petty bickering, it could really dominate internet applications, especially with a lot of the Java Back End integrations becoming available and platform-independent SOA opportunities.

I disagree with quite a few people that JSF is "the standard". For eCommerce applications that need to have a tremendous amount of mutability on the front-end, I believe that the complexity and backing-bean dependencies of JSF will hamstring a project quite a bit – It's tough to beat good 'ol JSP and/or Velocity(if that's the "way you roll") for making quick and frequent changes.

At the Enterprise Level, I constantly run across home-grown frameworks that have evolved over time. They are MVC2 and meet the needs of the organization based upon their numerous constraints.

We as engineers often look for the solution that is "most pure", and we can argue forever with respect to what "pure" is, but frankly we need to examine corporate and non-technical constraints more closely when specifying a framework. Process, the ability to "fix the plane while in the air", finances and other issues make things interesting, and many large organizations have deep and immutable ties to old source control systems, release management processes and in one case that I've worked, non-standard dpkg release requirements. You never know what you're up against until you're up against it, and instead of forcing a solution, be a real engineer and accept the constraints and work within them.

"If there were no constraints, the Golden Gate Bridge would have been made out of billet Titanium and plated in Gold and Platinum for decoration." – me

The answer to me is – it all depends – you can say that Struts 1.x is end-of-life, but I heard that three years ago. I've got an old Swiss Army knife that's not nearly as good as my Leather Man Tool, but when I need a corkscrew or a toothpick or a plain old pen blade, it's still my "go to". I also like the way it feels in my hand.

I agree it does depend.

...this is a question that interests us as well. We were just discussing the rapid growth of Wicket and wondering if it was the successor. I'll certainly be interested to see what you find out. And if you'd like to write a book about it, we'd be interested in publishing it.

I have heard a lot of good things about Wicket so far I don't agree.

In 2008, there's no question most IT managers are turning to JSF for most new projects. JSF is finally coming into its own and the adopt rate of JSF continues to increase exponentially. Tool support for JSF is still a bit flakey but there are still good tool options out there for companies willing to use a particular tool vendors flavor of JSF (such as NetBean’s JSF components or Oracle’s ADF Faces). Also, the availability of AJAX extensions to JSF such as Ajax4JSF and Apache Trinidad make JSF attractive to IT managers who want to flashiness of AJAX without the JavaScript developer skill sets required for frameworks like Dojo.

As far as what developers want, most are keen to start using Ruby on Rails. The speed of prototype development offered by the Rails scaffolding is extremely compelling and the restful controller resolves a lot of the complaints developers have had with JSF and Struts. However IT managers at conservative companies are often reluctant to adopt Ruby.

Developers are also very attracted towards Seam as it greatly reduces the level of “cookie cutter glue code” between the web layer and the database/services layer. I predict you’ll see Seam adoption increase significantly in 2008. However I’ve also observed that many conservative large corporations will continue to be fearful of Seam’s LGPL (in part due to the Linux GPL’s community’s recent use of the GPL to attack Microsoft, which only feeds the F.U.D. around the GPL and LGPL) and JBoss will remain unwilling or unable to dual license Seam under a commercial license that might resolve these companies concerns.

Longer term, the forces you’ll see driving the adoption trends are (a) the desire for more AJAX style applications, (b) the IT manager desire to tap offshore resources successfully. And unfortunately for the present they have competing skill set needs. Adding true JavaScript controllers to applications ala Google Maps and GMail requires a strong JavaScript developer and tends to be seen as increasing overall application complexity. Whereas off shoring to India and elsewhere drives IT managers towards easy to learn, easy to use, low risk frameworks like Struts, Struts 2, and JSF. With these two forces, sentiment towards JSF remains somewhat mixed. It’s currently perceived by IT managers as the safest way to add AJAX to an application while leveraging a Java developer skill set (although some may argue this on purely technical grounds pointing to GWT and other frameworks). However the need to assemble a hodgepodge of extensions like Facelets and Trinidad to do effective JSF development increases the learning curve for offshore resources, introducing risk most IT managers would rather avoid. This may push these IT managers towards Struts 2 adoption, but only time will tell as it’s too early to call.


Someone else who is pro JSF. I think JSF + Facelets + Ajax4JSF is a great combination for developing web applications. If you web application is more web than application then Spring MVC makes more sense.

I have no market data, but I would guess JSF is going to capture the biggest marketshare in the Java market.

I see.

I'd have to say: Rails, Grails or Tapestry 5 (see how open minded I am ). Rails has a lot of hype and is a great fit for many common in-house applications, though it takes considerable expertise to "draw outside the lines" and overcome some limitations in the database access layer, ActiveRecord. It'll be interesting to see if Rails using JRuby hits a real sweet spot.

Grails really takes a lot of the Rails goodness, without leaving the Java space. Groovy is a very interesting compromise language, between the full openness of Ruby and the dogmatic lock-down that is Java.

And then there's Tapestry.

Tapestry 5 currently skimps on some of the RAD features of the Rails/Grails set, but boy does it make up for it in other ways. I can personally attest (having written 95%+ of the code) that it is very developer focused, in ways that I could only dream of in earlier versions of Tapestry.

Instant class and template reloading. Powerful templates. True inheritance of pages and components. Super testable. Case insensitivity. Very high performance. Easily extensible. Really, really, really good feedback when things go wrong.

I know this sounds like marketing fluff, but I'm just very excited seeing T5 come into its own after a careful build-up of features over the last year and a half.

In addition, the Tapestry story has grown larger than just the code and the community; we'll be seeing true professional support for Tapestry early this year ... Tapestry finally has the last piece that it needs for true success: mature corporate backing, in the form of my new employer, Formos Software Development.

Tapestry 5 seems great. Most of my friends who were big advocates of Tapestry seemed to switch to RoR or some other shiney object. If I were a big company looking for a new web framework to use would I switch to Tapestry? It seems that Tapestry has backwards compatibility issues and switching from one version to the next is difficult. Tapestry 5 is not backwards compatible with Tapestry 4 at all. I have used Tapestry in anger. I have experienced some of these issues. If you are looking for an alternative from JSF to web component development, Wicket seems more stable. Whatever happened to Trails?

Anecdotal mostly (based also on my personal experience) - Spring MVC, then probably JSF

Again, you probably can't go wrong if you guess the top three. Unless Wicket is the black horse that dominates them all.

I'm not sure what the market data is on what developers are adopting for web frameworks. I can only use anecdotal evidence by what my collegues are using in other companies and what I saw in use at other companies while contracting. That was 100% Struts 1.x.

If I were to use or other job resources databases, I'm not sure I could formulate the appropriate queries to get at that data correctly. For example, most job reqs will list things like "Struts, JSF" together giving no specificity to what they are looking for (they'll take a person with either skill). This would inflate the stats for JSF and dilute the stats for Struts, particularly for Struts 2.x shops looking for just "Struts" people, regardless of version since the transition is painless).

My gut would say that they would eventually migrate to Struts 2.0 since it is able to leverage the experience of developers and provides for a low risk migration/upgrade path (you can run slices of the same application using Struts 1.x style side by side with slices running 2.x style.) This then allows a company to migrate at their own pace. There is almost no downside to this approach.

The fact that Struts 2.x is substantially a Webwork re-branding is accurate, but also somewhat academic. "If it walks like a duck and quacks like a duck..." Struts 1.x people will feel at home in Struts 2.x and incur almost no loss of productivity. There's a lot of upside to that.

On the JSF side, the fact that it's now a Sun/Java standard is also accurate, but also somewhat academic. EJB 2.x was a standard, yet people looked at it, used it, and Spring and Hibernate just took over. They conceded that EJB 2.x was the standard; they just didn't care and opted for a more suitable solution for their needs.

Finally, I'll even be so bold as to question if Struts 1.x truly is end of life. My personally belief is that we need not keep reinventing the wheel to the same problems over and over. We can't keep switching to the web framework flavor of the day, only to do basically the same thing. The value in the app is not the web framework, it's the business logic. Imagine if we changed the syntax of Java every 3 years or important subsets of it such as the Collections. I guess I am of the view that a company is not an R&D shop. They have "real" work to do, and thus "should" place more value on productivity and continuity of acquired skills, than experimenting.

That said, Struts 2.x gives you the best of both worlds: an upgrade path if you absolutely have to be using more recent techniques (i.e convention over configuration), while still retaining a base of knowledge and skills allows the developers to be immediately productive.

Okay so you like Struts and not JSF. Got it. I agree that Struts 2 provides an upgrade path to WebWork which has a much better design than Struts 1.x and Struts 2 will likely do well.

Most of the time developers are not doing the picking. So this is one of the key variables. Another variable is whether application is green field or not. I would imagine if developers had a choice they would pick something they are most familiar with or if the framework was end of life something close to what they are familiar with. I am sure there are some exceptions to this rule, operative word being exceptions. I do not have any data, but I would be hard pressed to come up with an argument to use Struts 1.x unless it is a legacy application or all other applications in the shop are Struts 1.x and there are no plans to switch.

Now coming back to the point of who is doing the picking. If you have a competent development manager and the application is “green field” the choice of the framework would consist of the following analysis: (1) Resource Availability; (2) Framework Maturity; (3) Testability; (4) Standardization; (5) Available Tools; and (5) Problem Fit. I would do them in that order. It might seem odd that the problem fit is a last on the list, but if frameworks to be competitive they need to address majority if not all of the common cases. Unless you have a unique problem #5 becomes academic.

All things being equal my choice would be between JSF(MyFaces, Seam, etc) and Spring MVC. If a development manager is less competent or company mandates using well accepted standards JSF would still be a choice. Other choices may still include Spring MVC or GWT because they are big names and it is hard to go wrong.

So in short, JSF, Spring MVC, and maybe GWT. I couldn't agree more. Time will tell.

I am currently doing a project for a major Hospitality chain - we are replacing all of our Struts with HTML, DOJO, and JSON talking to a back-end service architecture. I am finding DOJO a bit buggy (digits) and there are some ok tools (firebug, aptana) that make Javascript palatable. But in the end - we are still writing code and building frameworks.

WOW! That is a lot of JavaScript development. Not sure I envy you much. I worked with DOJO and had a similar experience. Makes me hope that GWT is viable choice for RIA or perhaps Java FX or even Java + Flex (which people are starting to use in droves).

As an Ajax vendor, JSF is not there yet and people seem to be liking Spring and Struts 2 (hell Struts 1 for that matter). While JSF has been on the horizon for a few years now I think that other new frameworks like GWT are gaining ground a lot more quickly - GWT, next to ASP.NET is the most popular server side Ajax framework around. Haven't tried Wicket too much but Tapestry has had its day and Seam is a dark horse that might really explode this year.


..., Struts 1 is not "end of life".

Struts 1.3.9 was released in August 2007, and work continues on Struts 1.4. S1 is mature and stable, and Struts 1 will live as long as there are volunteers to support it. As an open source project, we have no economic incentive to discontinue support. All that matters is that people continue to use the product, and that the community around the product remains active.

If you check the Struts user list, you'll find that people still recommend Struts 1, depending on the circumstances, and many of those people are Struts committers.

Statistically, even after all these years, more job posting cite Struts (as in Struts 1) than all other web frameworks combined, including JSF. If anyone is adopting anything else yet, it's still a statistical blip. In practice, most people seem to be standing pat. Rick knows this, but to do some research on your own, has an interesting Job Trends tool.

Incidentally, one thing both Struts 1 and Struts 2 lack is support from corporate volunteers. To date, I don't know of anyone who has been paid to work on Struts as part of their day job. But, still, we keep on keeping on


My response to T:

Not only do I know this. But I have discussed it on my blog at length many times. I am not trying to hide Struts continued success. Although from a technial stand point, I feel Struts 1.x comes after JSF, Spring MVC and WebWork/Struts2.

That said, Struts is a case study in how you run a successful Open Source project. For a lot of companies, Struts was their first open source project that they used so it has openned a lot of doors. The number one download on TheServerSide in 2007 (and probably 2005, 2006) is a book I wrote on Struts so I get it (The book was written in 2004).

I do think using Struts 1.x on a new project is a mistake (more on this later, see blog). Struts 2, Spring MVC or JSF would be a much better choice.

The problem with is since there still is not as many folks with JSF skills or Spring MVC skills, Struts is even listed if a company is looking for JSF developers or Spring MVC developers. Also, there is no reliable way to differentiate between Struts 1.x and Struts 2.0 since many job requests don't list version numbers. Also many people who are using Spring just assume Spring MVC as well so they don't list it.

In short, it is hard to tell how many people are moving from Struts 1 to Struts 2.

That said is a great indicator. It can't be the only one though. And it has some problems. I was hoping for others.

As goes, JSF growth was fairly slow until January 06. Then is started to take off and grew very quickly. Demand doubled in less the a year and then double the next year as well. Why? I am not exactly sure. My guess would be the AJAX component frameworks for JSF (like Ajax4JSF, Avatar, IceFaces, etc.), composition components via Facelets (and perhaps Clay), Seam, improvements in JSF 1.1 and JSF 1.2, and folks coming up with workarounds for JSF problems, etc. There seems to be a lot of interests in JSF in the Java community and growing job demand to match.

Let's put it this way: If job demand for the Struts framework and JSF were a stocks and you invested in it in April of 2005 by July of 2007 you would barely break even with Struts but with JSF your investment would have grown 700% as of July 2007. (According to

JSF 2, which is forming, incorporates Facelets concepts, adds native Ajax support (similar to Ajax4JSF) and makes JSF component development easier. JSF 2 should further enhance ones investment in JSF. The new model has partial page rendering via Ajax, which is available today from tools like Ajax4JSF.

With the above said, JSF is still plagued with issues (some technical, some community) and is far from perfect (which I will blog about this year).

I am not tied to JSF. When I wrote Crank (a Java CRUD framework), I made sure it was not tied to JSF so I could switch to Struts 2, Spring MVC or Wicket if I needed to (or was paid to do).

Does anyone have any market data other than

Wicket has had the most active mailing lists for over a year now (see and it's downloads are currently skyrocketing. Wicket In Action is almost done, and in the mean while another title is written on Wicket (and possibly one more in preparation). If you're looking for a 'winning' Java web app framework, consider looking at it.

Now, personally I don't think it matters what market data says. Hire developers with solid foundations and let them learn a framework on the job. It's not rocket science, and companies should not go for choices that are less than best fits just because they assume it might be easier to find people for them in the market place.

I think good choices for frameworks are: Wicket if your UI is very complex or you need to reuse UI functionality over multiple applications. GWT if you can go Ajax all the way and you work with relatively large teams. Or - again if you can go Ajax all the way - consider just using Javascript frameworks (YUI for instance), maybe combined with something minimal like Restlets if you work with small, able teams.

Is it the most active mailing list because the docs are so poor and people need to ask a lot of question or because Wicket is popular? I've never used Wicket but heard good things about it.

I don't believe there will ever be a dominant framework again like Struts 1.x was. I think many folks have realized it's possible to have more than one framework in their organization and they use one over the other depending on their application's needs. For example, using Spring MVC when the need is speed, using Grails when rapid prototyping is more important.

For request-based frameworks, I believe Struts 2 and Spring MVC will be the leaders, with both of them stealing more and more ideas from Stripes. Stripes will have a hard time taking over either unless they start writing books and putting more efforts into marketing.

For component-based frameworks, I believe JSF will dominate only because it's a standard - not because it's technically superior. Wicket continues to impress and I'm sure Tapestry 5 will not be disappointing. I believe that companies that adopt Wicket will be happier than those that adopt Tapestry 5 as Tapestry has a bad track record of backwards compatibility (sorry Howard).

I believe if Grails beefs up their Wicket Plugin, and Seam adds support for Wicket - it could quickly become the dominant component-based Java web framework.

I do believe all-in-one starter frameworks like Seam, Rails, Grails and AppFuse are excellent. However, I also believe they're solving a problem that only 10% of companies have. Most companies don't have the ability to start applications from scratch - unless they're a startup. Most companies have an existing infrastructure in place for the backend and they simply need a better web framework to slap a pretty face on it. I don't know the best solution for this, but it seems like a logical choice to RESTify the backend (possibly with a web framework) and then use a modern web framework for the front-end. IMHO, the best web frameworks for a RESTified backend are Flex, GWT and Appcelerator. If nothing else, these appear to be the most promising web frameworks for a REST architecture in 2008.

Well put. Well said. I agree. Will this be the year that Java + Flex and GWT take off? Is server-side Java EOL?

Hey Rick, great question. I'm seeing a strong trend in my (non-geek) client firms (those for whom IT is primarily a functional solution and who are more concerned with issues such as familiarity, skills acquisition, and company or government compliance) towards JSF adoption. This seems to be largely to the standardization, products and support led by Sun, inclusion into the J2EE spec. Features and ease of use vs. other technologies are of secondary importance to this sector.

There's the camp that will go with what they know, which is Struts, meaning they will continue with Struts 2. In a large company, that has invested time and developer training on their Struts 1.x apps it would be a logical choice. Then there's new projects. I doubt there will be dominance in one framework. The determiner will be architect or development manager, which has to make decisions on staff resources, maturity, supportability, and project requirements.

Staff resources is that same problem when C# came out. The language was written in such a way that it could in theory pull hordes of developers away from Java, or so it was marketed as such.

Maturity and goes in hand with standardizations. With thes two comes the ability to find resources or developers should problems arise during the project lifcycle. You can hope to expect to find an actively supported framework.

Finally, project requirements. This is a tough "holy grail" for any framework. Projects not only have to meet delivery deadlines, but support any requirements in the future, and this is where we see good implementations of frameworks go bad over time.

My gut says that there won't be a single framework, and although JSF is coming along, it's not here yet. It will help recapture and solidify the ability to grab the Swing developers.We are seeing some of the ideas from JSF spill over to swing in the idea of EL bindings and validation, which are in JSR 295. I think a lot of developers are hesitant because of the EJB debacle, and oters started java application development in Servlets, Struts, or templates(velocity, jsp), and may have never done swing/awt development.

I see. Struts seems like such a poor choice to me. After using Spring MVC and researching WebWork, I don't see how anyone can stick with Struts 1.x. But, Struts 2 is backwards compatible so now you can use your investment with a new framework that is more well thought out (a.k.a. WebWork).

I agree that Struts 1.x is not dead.

Probably the reason is that Struts 1 is terribly simple to learn (I don't remember who told this, probably Ted himself, anyway notice that this sentence is not mine ). Every other framework has its own point of view, with different capabilities, different approaches and a various way to say that their product is "the best".

Sincerely I would like a framework that has the power of Wicket, the simplicity of Struts 1, the elegance of Struts 2, the configuration scheme of Mentawai, the conventions of RIFE, the "standardness" and the paradigm of JSF, the approach of Spring WebFlow, the glue of Seam. Maybe it's Ruby on Rails

Rails? Maybe. Probably not though.


My two cents.

JSF appears to be gaining some market share. If you consider the fact that Oracle had integrated tools with their IDE and has been actively marketing JSF. I tech reviewed the new SCWCD for Sun Microsystems and there is a lot of JSF involved with the certification. So industry support helps, but does not enforce adoption.

Struts. I have always been a fan. I am using Struts 2 but I am also extending Spring framework. Using the Struts 2 controller with all of Springs offerings. That has provided some solid foundations.

Then there is Spring itself, controller and all. I really see this being a large market leader in the future. Especially seeing large consulting firms, (wish I could drop names) implementing Spring solutions for multi-million dollar contracts. This will leave a lot of Spring framework code out there to be maintained by someone.

I think most importantly all these frameworks have value. Or there would not be some many folks using, playing, adopting, and implementing. I really focus on what the frameworks have to offer and what the implementation really needs.

If I go with the gut...I would put Struts 2, JSF, and Spring (MVC) at the top.

The real value comes with maintenance. How readily available are resources to hire. If you look on Dice you can put in the framework and see the demand. When the dust settles you will want to build something that can be easily maintained at an affordable price.

Just my opinion.

RE: I use JSF and Spring MVC frequently. I would put Struts 2, JSF, and Spring MVC at the top as well.

Spring + Hibernate + ACEGI is a powerful combination. We've been using this for the past 18 months as a back-end with Adobe Flex on the front-end.


I’m seeing an uptick in business for JSF, primarily from larger corporations. Other than that, I’d say the big names these days are Grails and GWT. GWT, because of Google’s marketing muscle, is getting a lot of mindshare. I don’t know how that’s translating to actual jobs, though.

Good to hear.

Most work I have seen centers around Struts 2.0, JSF, or Spring MVC.

Although I am starting to see a bit of Adobe Flex as an alternative to Ajax-infused views.

Adobe + Flex with a Java back end seems to be something we run into every now and then as well. It seems like a good stack.

I don't think there will be one new big framework like Struts was. Nowerdays people can pick the framework that suits their specific needs.

The most populair frameworks today are JSF (component based) and Spring MVC (request based). But modern developers need to feel confortable with multiple frameworks IMHO because different projects suit different webframeworks.

It is not like the good ole days eh? Everyone used Struts or their own custom request framework. Now there are real choices and some of them are quite good.

rick hightowercto of arcMindbloglinkedin

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ }}
{{ parent.authors[0].realName ||}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks