Excellent post Paul! Very well balanced, sticks to facts, hits a lot of important points... maybe you should convert it into a blog/wiki entry, I think it would be helpful to a lot of people...
Dario On 3/7/06, Paul Cantrell <[EMAIL PROTECTED]> wrote: > 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] > > -- Maybe this world is another planet's hell Aldous Huxley --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
