2. In the 4-or-so years I've been involved with the community, I've *never* built a production website with Cocoon, and I highly doubt I ever will. It hasn't caught on here in the states as much as Struts has, or JSF could. I was holding out hope for a Cocoon type job, but as soon as I graduated University and needed a job, all of the J2EE jobs were Struts-based, and Spring is *just* starting emerge as something companies are investing in. See #4, below for more thoughts.

2B) I've seen some stuff at work where I have said, "Cocoon does this," but Struts didn't, so it was implemented (poorly) in Struts, causing all sorts of headaches.

2C) The only reason I have a job however, is because of all the exposure to *other* J2EE stuff that Cocoon got me into. Maybe I should have moved to Belgium ;)

3. More functionality is moving to the browser, but the apps will still reside on servers. I can't see that moving away. I always knew server-side XSLT was sort of a stopgap until browsers could do it reliably.

4. I have to agree with Berin's point about convention and simplification over configuration. With things like Spring, and books like _Better, Faster, Lighter Java_ (and XP themes in general), there's a move to make things easier to understand, maintain, and be concise at the same time. IMO Rails hits these points pretty nicely, not only because Ruby is a concise, elegant language, but you also get a lot of "Good practices" for free. You get the separation between development, test, and production environments/databases. You get a lot of unit and functional testing for free when you generate your code. You can even get webapp controller tests for free, which is more than I can say about Cocoon. And the free stuff goes a long way.

In conclusion, I don't think Cocoon "The Idea" is obsolete, but perhaps Cocoon "The Implementation" is. Here's where I put on my "I have a bunch of good ideas but none of the skill to implement them" hat:

- Simplify Cocoon. What's the bare minimum we can get away with? Not only functionality, but also actual amount of code? Ugo's work with Spring and Butterfly probably is a good starting point.