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.
Ralph
- Re: [RT] Is Cocoon Obsolete? Ralph Goers
-
