On Jul 13, 2005, at 1:37 PM, Joel Trunick wrote:
I think WebObjects "got it right", and Tapestry supplied the Java
solution, along with now Shale (Struts 2.0), not to mention Wicket and
Japple. It's relatively clear to me that the Tapestry way of
separating
concerns is a winner and the approach should win out in the long
run (at
least for more intensive development efforts).
Ruby on Rails has figured out how to do OR with ActiveRecords, but
haven't figured out the presentation layer (still ala JSP), so it's
personally not yet interesting to me as a web framework.
I've been building an application with Rails for the past couple of
months and the JSP-like nature of its templating turned me off at
first glance. But don't let that influence you yet - there is a fair
bit of cleverness there that beats JSP and taglibs. For example,
templates are processed inside-out, similar to the @Border way of
doing things - the nested view could conceivably control what the
"layout" does. While there is no rewind cycle to automatically bind
parameters back to objects, the namespacing of form fields and Ruby's
elegant syntax makes this trivial.
Rails AJAX integration as well as spectacular DHTML effects are
trivial to use. In Tapestry it is complex still - even though the
tight Tapestry JavaScript glue is present.
While the complete separation of concerns of Tapestry is what drew me
there, it is not necessary to follow this strictly and dogmatically.
While this may be a tough thing to hear on this e-mail list, I would
venture to say that a skilled Tapestry developer would be slower to
build the same web application than a skilled Rails developer, and
that the Rails application would be able to have a much nicer modern
look and feel to it almost trivially while the Tapestry application
would struggle to compare. There are many other factors that can be
compared here such as maintenance, scalability, testability and
performance... and I would even go out on a limb and say that Rails
still has an advantage. Why is that? Simple the language it is
written in.
I don't want to sound fatalistic about Tapestry, but merely speaking
from my experience and observations. Tapestry would do well to
evolve based on such critique... simpler, not more complex, tight
AJAX integration, clean URLs and elegant ways to map into them,
simpler hyperlinking, and so on. This is an opportunity! The
community needs to pick up the ball and contribute in any way
possible to make this happen and to keep the positive momentum flowing.
Erik
The point is if you believe it's the technology for the long haul,
it's
a moot question whether Tapestry dies, can simply switch to whatever
makes it (as some WebObjects developers have done). But, you will be
ahead because you will understand the structure and concepts (same as
those that started learning OO on C++, Smalltalk, etc.).
Joel
-----Original Message-----
From: Ahmed Mohombe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 13, 2005 12:22 PM
To: [email protected]
Subject: Re: Future of Tapestry in questionable
Recent views expressed by Howard on his blog and discussions on the
net
makes me question the future of Tapestry. He is sounding more and
more
pro
Ruby on Rails and a bit anti Java. So the question is would Tapestry
end up
along the way like one of those abandoned OS projects with no
development
activity whatsover? This is something I think worth thinking about by
we
Tapestry users.
Interesting.
To be honest, I'm taking a serious look at Wicket now.
Well, what's the guarantee that Wicket won't be abandoned long before
Tapestry? :). Besides, it's a little to much buzz around Wicket -
something that looks like a soap bubble :) (IMHO).
What do you think?
An official statement from Howard would be the best IMHO :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
