Stefano Mazzocchi wrote:
<snip/>
If you ask me, the current infatuation with Ruby on Rails and friends,
while understanding and to the point (the need to avoid XML pushups,
so true), will fail dramatically short in scale to complex systems.
Just like M$ Word is great to write one/two pages and it fails
miserably to help you with your thesis, something like rails is
awesome for your blog or single-handed ecommerce web site, it would
kill you no less than PHP with a massively complex web site.
<snip/>
How do you feel about this?
I have a couple thoughts on this. Actually it's more of a brain dump. ;)
1. (Like Berin) I am admittedly infatuated with Rails. This may be the
infatuation speaking, but the "Rails doesn't scale" smells like FUD to
me. I'm still infatuated with Cocoon, too, BTW. I've been building
Struts apps for the past 6 months and I am constantly cursing JSP. JSTL,
taglibs, etc. (see #2B, below). I can't wait to /stop/ building Struts
apps, but my dislike for Struts may pollute my opinion of JSF when the
company I work for eventually decides to move in that direction.
1A. Stuff I've done in Rails I have liked, but was always sort of
wishing for more "Cocoonish" -- Flowscript, Sitemaps, etc. Ruby has
native continuations, so there might still be hope. One thing I was
trying to do that's very simple in Cocoon (or HTTPD for that matter) is
something like this:
<map:match pattern="docs/**/*">
<map:generate src="xml/{1}/{2}.xml"/>
<!-- whatever else -->
<map:serialize />
</map:match>
In Rails, you have to setup some sort of "TemplateController", manually
inspect the request path, parse it out, and then send the file on the
local disk as text/html. I think part of this stems from the fact that
Rails is more of a webapp framework than a publishing framework (where
obviously the opposite was true for Cocoon for quite a while). In this
sense, Rails still has some maturing to do. Likewise, Rails'
ActiveRecord covers probably 80% of the use cases for building webapps.
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.
- Borrowing another buzzword, how can we move Cocoon "The Idea" into the
Web 2.0 era? I really hated to invoke it, but I think it's important.
I'm not necessarily talking about how we can make Cocoon serve "Web 2.0"
apps, but more along the ideas of Better, Faster, Lighter. Maybe I'm
mixing my ideas of Web 2.0 and "better Java development practices" here.
----
Tony, who feels like he dumped a lot of stuff from his brain because of
Stefano's RT.
