Remember that Trails (www.trailsframework.org) tries to reproduce some of
the functionality of RoR using Tapestry ("Note: Trails is not a port of
Rails"). I don't know if anyone has touched on this yet.
-----Original Message-----
From: Paul Cantrell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 07, 2006 11:25 AM
To: Tapestry users
Subject: Re: Ruby vs Tapestry
Interesting discussion, but I don't think anybody has hit on the
really important stuff yet. Those more knowledgable can correct me if
I'm wrong:
*** Rails is based on a dynamically typed language (Ruby), Tapestry
on a statically typed one (Java) with a dynamically typed template
language (OGNL).
That means that the two frameworks come with the tradeoffs of dynamic
vs. static types: Ruby code can be more concise, and can pull more
simplifying tricks by having, for example, all your page's fields
appear "by magic" with no declaration -- but that comes at the
expense of being able to catch many errors at compile time, have your
IDE do autocompletion of available methods, and generally having the
clarity of seeing during development exactly what members are
available to you and what their type is.
It's a big question, but in Rails vs. Tapestry, it we can sum it up
with the fact that in Tapestry you have to do this:
public abstract String getAddressLine1();
public abstract void setAddressLine1(String value);
...and in Rails you don't. If that feels like a burden, you'll like
Rails. If it feels like useful structure, you'll like Tapestry. Both
certainly have their place in the world.
*** Tapestry has a page template language that separates code from
pages; Rails uses the internal language as its template language.
Rails advantage: you have the full expressiveness of Ruby in your
page templates; no more wrangling with the bazillion parameters of
"@For".
Tapestry advantage: you have a clean separation between formatting
and view logic, and you can (fairly) safely hand pages over to
designers without worry.
*** Rails extends from the view down to the database; Tapestry keeps
its hands off the DB and deals only with view.
...and closely related:
*** Rails ties the database structure very closely to your object
structure, so your database tables look a lot like objects.
The Rails advantage here is that you can just model out your objects
and let the database take care of itself, with very minimal worrying
about tables. That ceases being an advantage, however, if you're (1)
integrating with legacy databases or sharing the DB with other apps,
or (2) your DB is large or complex enough that fine-grained schema
control is important. Then Rails' lack of robust O/R mapping really
starts to hurt.
Tapestry doesn't even get its hands in the DB, so you're free to use
Hibernate or Cayanne or raw JDBC or whatever you like. Hibernate is a
standard choice. Like Rails, it can autogenerate your schema if you
like, but it can also adapt to explicitly designed schemas much
better. Unlike Rails, it requires some extra configuration.
I personally like the fine-grained control over how my tables are
named and indexed, what foreign keys are created, etc. Rails doesn't
choose good names for tables, doesn't handle foreign keys well, etc.
On the other hand, if you want something running fast, Rails' lack of
flexibility in this area also means lack of up-front configuration cost!
*** Ruby doesn't have anything like the broad set of libraries that
exist in Java.
That will gradually change over time, to be sure. But when people
talk about Rails not being "enterprise ready," this is part of what
they mean -- you can find a library for just about anything under the
sun in Java (pun intended) ... but try finding integration for your
smart card reader in Ruby.
No reason to think it will always be this way!
*** Rails has a very strict memory-exists-only-during-a-request view
of the world.
This is because Rails uses CGI. If you want anything to live across
requests, you need to store it in on disk (how Rails handles
sessions) or communicate with a different process or something. The
performance tradeoffs are obvious: no load-once behavior, no in-
memory caching, no background threads, the whole module has to fire
itself up and parse your pages on every request ... but your app is
automatically clusterable if you keep your hands off the disk, and
you don't run into these "oops, I put it in a static variable and
didn't synchronize it right" sorts of problems.
*** To my knowledge, Rails doesn't really have anything to compare
with Tapestry's excellent component framework, or to Hivemind.
(But I may just be ignorant.)
*** One uses Ruby, one uses Java.
This is largely a religious one, but it's important to many people.
Some people love functional languages or have blamed Java for all
their problems, and thus swear by Ruby and loathe Java. Some people
are terrified of the unfamiliar and won't touch Ruby with a ten foot
pole. I personally think they're both great languages. (I really do!
Many Java APIs, e.g. EJB 2.0, are terrible and responsible for much
suffering, but the Java language itself is a beautiful thing. And
Ruby is cool and fun and promising.) But Rails / Tapestry debates are
likely to turn into religious Java / Ruby debates....
The bottom line is they're both exciting and interesting frameworks.
Ruby probably has a lower "minimum app complexity," and Tapestry
probably has a much higher "maximum app complexity," but both are
worthwhile, and for many tasks, both are good options. What I think
Rails really supercedes is PHP: I have trouble imagining a DB-driven
app where using PHP is a better idea than using Rails.
Hope that's helpful. I also hope it's correct, because really I don't
know Rails all that well -- I've only talked about it a lot. Maybe
I'll run this by the Ruby Users of Minnesota and let them correct me.
Cheers,
Paul
On Mar 6, 2006, at 3:19 PM, Edward Scanzano wrote:
> Hi All,
>
> I got the question today...What is the difference between Tapestry
> and Ruby (on Rails). I want some good reasons as to why Tapestry is
> a superior choice. Please feel free to comment.
>
> Thanks
> E
_________________________________________________________________
Piano music podcast: http://inthehands.com
Other interesting stuff: http://innig.net
---------------------------------------------------------------------
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]
