cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [RT] Is Cocoon Obsolete?
Date Mon, 03 Oct 2005 11:52:57 GMT
Tony Collen wrote:

> 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.

Well, at least I have built a production site using Cocoon. But it was a 
tough sell and we did it kind of as a last resort. It was really the 
only thing that supported an ASP environment at all.  However, there are 
several things Cocoon needs to do to become more accepted. Primary among 
them is to somehow dispell the notion that Cocoon is all about XSLT and 
that it has a lot of overhead. But even worse, when someone new wants to 
"learn" Cocoon I have to tell them it is going to take 3 solid weeks. - 
and it does.

> 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.

I just flat out won't do struts. Not that struts is bad in and of 
itself. It's just that it tends to lead to bad programming IMO.  
Unfortunately, in the U.S. 95% of the jobs list struts. Some speak of 
flash. And none, as of yet, list Ajax or Mozilla or some of the newer 
ideas.  Frankly, until Microsoft does something along those lines you 
can forget about companies like mine doing more client side stuff.

> 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 ;)

Yeah - me too.

> 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.

This is the whole idea behind "real blocks".  I think it will take this 
to happen before Cocoon will really be taken seriously.

To be frank, the real "problem" with Cocoon is complexity.  Once Cocoon 
can be viewed as something similar to maven - i.e. a basic framework 
with lots of plug-ins - then I think we will be making progress.  A 
secondary problem I have encountered is support.  In the U.S. support is 
non-existant.  You can't call up a company like JBoss and pay anybody 
for support.  You don't have that problem with struts and JSPs.

And believe it or not, the real competition I am seeing is coming from 
JSF, which blows me away as it doesn't separate the view from the 
controller at all.


View raw message