[Catalyst] Why Catalyst instead of Ruby on Rails?

[Philip Edelbrock]

Jules Bean wrote:
> Ovid wrote:
> 
>> I'm wondering about two things, though.  First, why would someone want
>> Catalyst over Ruby (or vice versa)?
>>   
> 
> 
> http://dev.catalyst.perl.org/wiki/VersusRails
> 

I started that wiki page and did most of the maintainance (initially, 
anyway).  We were about to launch into a new project and were trying to 
settle on a MVC framework at the time.  Having used Perl forever, I was 
leaning towards Catalyst.

What did we choose?  Rails! ;') I wasn't the lead, so it wasn't my call. 
  It's not as scary to dive into as you might think, though.

A few notes:

+ Ruby/Rails are CPU and memory hogs.  It almost certainly must have 
some sort of caching and/or acceleration scheme for deployment (and it 
helps for development, too).  Perl/Catalyst runs faster and won't bog 
down your computer/server as much.

+ Ruby and Rails are changing and can break each other as the releases 
come out.  For Ruby being around 'so long' it still is changing rapidly.

+ Finding ISPs with Rails support can be a hassle, and some stock 
distros have 'broken' ruby installations (MacOS, RedHat, etc.). 
Luckily, we have a dedicated server that we can set up any way we want.

+ Scaffolding (Catalyst or Rails or whatever) is way, way overrated.  On 
a project that takes a month or so, you'll scaffold for a day, and then 
basicly go through and rewrite it all the rest of the time.  I found the 
default scaffold code not very well done anyway (e.g. forms are static 
and don't change when schema changes).  It can be handy for creating a 
crummy, ugly CMS, but that's unlikely to be acceptable.

+ Ruby syntax is a lot like Javascript, imho.  It's simple and has some 
basic conventions that make it faster to work with than explicitly 
calling out things as constants, etc.  I wouldn't put too much weight on 
the decision based on the language.  You're likely used to switching 
between different scripting languages like Javascript, Perl, and perhaps 
some other things (PHP, ASP, etc.), anyways.  I've just used a few 
simple web sites as Ruby references when I need them.

+ I think Rails has better end-to-end consistency and integration.  CPAN 
can be a mixed bag (what's stable, what's not, why are things like 
documentation, naming, and other convetions not consistent, etc.).  On 
the flip side, there's a lot of great stuff in CPAN that isn't in 
Rails/Gem.  A problem we had was lack of support for GnuPG, so we're 
handling that outside the scope of Rails.

+ 'Going with the flow' and using the built-in concepts and functions in 
Rails make for quick work.  You always have access to raw SQL 
connections or whatever, if you need it (which I found I still 
occationally did).  In other words, you aren't pinned down to doing 
things a certain way, but it does help if you do.

+ The 'it only took me 123 lines in Rails, vs 1000 in XYZ!' comparisons 
for the noobs are a little misleading.  'Convention over Configuration' 
means there's a large pile of code behind the scenes that you *still 
need to know* or else you'll be reinventing the wheel.  As you know, 
this is true in Perl, too.  I.e. how would you know a particular CPAN 
module would do the work for you if you didn't know about it or couldn't 
find it in a search?

+ The pluralism thing is weird and sometimes confusing.  I understand 
the rational and justification behind it, but in practice I'm not used 
to having to refer to the same things in different pluralities based on 
context.  It gets weird for not-so-simply named tables.  I've got a 
table called 'features and services', the model is called 'features and 
service', a category table is called 'features and services category'. 
When I refer to these things, it makes me stop and think, which is what 
I don't want to do if I can help it. ;')

+ Rails documentation is OK, but not great.  The mailing list hasn't 
been useful to me.  It's perhaps more active than the Cataylst list, but 
there are a lot of noobs and cheerleaders.  Get the Pragmatic Programmer 
book on Rails (and perhaps on Ruby, too) and rely on that instead.

+ Lastly, playing with Rails doesn't mean that you have to dump or 
forget about Perl.  I've been using a lots of Perl to do lots of search 
and replace, replication, etc. of Rails files.

Sorry for the ramble.  If you have some specific questions, I can try to 
answer them since I might know more about using Rails than others on 
this list(?).


Phil