waswas-fng has asked for the
wisdom of the Perl Monks concerning the following question:

Folks,

I have recently stumbled upon the Catalyst web framework(offsite perl.org). What first got me interested in it was this article about it at perl.com. It looks to be a young MVC framework that is meant to solve a lot of the issues (I have at least) with Maypole, CGI::Application and OpenInteract. It seems to be the closest thing perl has to Ruby on Rails I have seen yet (AJAX, templates, quick prototyping, expandable API). I am wondering if this has caught other people's eye here at the monastery, and if so what do people think? I have written a few smaller apps with it and it looks to be way less painful to do apps that go beyond CRUD than the other web frameworks listed above. I guess I just want to get a feel for how much use it is getting right now (the documentation is pretty weak still as it is only a few months old). I don't want to dive into a new web framework only to see it dwindle and die a few months down the road. Also if you have tried it out, does it "feel" like a better model to you than the others listed above? That is really what won me over -- but I am not sure that I just have not given my mind enough time to wrap around what I consider limitations (mostly that they are geared towards CRUD, and anything more complex seems to start fighting the API) of the other frameworks I have tried.

You are welcome to take a look at my slides and code examples from YAPC for a comparison of the same small app in OpenInteract2, CGI::Application, and Catalyst. (Most of the interesting stuff is in the code examples.) I will be updating this for OSCON next month.

Yeah I saw those already and have followed the chain of emails on the list. I must say that I have had some of the same experience as you with the very limited documentation so far, but that I seem to still be enamored by the toolkit. I find it feels very natural to my style of coding web apps. I hope that you would put some effort into expanding the documentation where you had found it to be very light as you update your slides for OSCON. I plan to where I can as well.

My experiences with Catalyst after about 2 Weeks developing with it:
- Developing is fast! I switched a 2-month running project to catalyst in about 3 days.
- The developers and contributors are _very_ helpful!
- I've not really reached it's limits yet. Everytime I thought, I was just being wrong.
- it "feels" good to use it.

I have been lurking for a while on the mailing list archives, it looks pretty active. I really like everything that you guys have done so far. I just wanted to get more of a feel for how much people here had been using it in the wild -- I have gotten bit on some newer frameworks that seem to have a good start but peter out over the next few months.

Have done some CRUD with Maypole, but performance is not amazing, and read the documentation about Catalyst, and had the same question, about how long it would be actual, maintained, how devel, etc... So it's nice to see that there're more people on the same position that I'm. And of course, great to see comments from the authors!

I was thinking about using Catalyst for the refactoring of a complex internal webapp. It'll be a long timing task, it's Perl+C, but the person who wrote it, was learning Perl on the way, strange style and don't use the nifty things you would expect...

Ruby is definitely a sleek language and I have desired to build app with Rails. I heard about Catalyst, but haven't make myself familiar with MVC framework. I definitely like to work with Catalyst as I can leverage my existing Perl-work\ and CPAN.

I think the dispatching is neat but does anyone else feel that the stash is kind of icky? I have not used catalyst yet but from the docs it looks like just a reference to a global hash with nothing to stop actions using conflicting names within the stash.

I have in mind to use a 'namespace' per controller or to assigning to the stash with a set method so I can check I'm not blowing away an existing value; unless there is a defacto standard between people working on catalyst modules?

The first I heard of Catalyst was in the past few days on the CGI::Application mailing list. I haven't had much time to check it out yet, so I cannot really address many of your questions.

I do have some questions for you, however. Why to you lump CGI::App into those that you feel "are geared towards CRUD"? The reason I ask is that CRUD is not typically what I develop with CGI::App. The stuff I develop with CGI::App varies widely, but is typically of the landing page-search results-view individual variety, or data capture (vs full-blown CRUD).

(A cursory glance at Catalyst indicates that it shares one important thing in common with CGI::App: a page is a method (cgiapp uses the terminology run mode). With this paradigm, your class indicates what the available run modes are, what to use if none is passed or an invalid one is specified, and you go from there.)

Additionally, you indicate that "anything more complex [than CRUD] seems to start fighting the API". Could you explain what your experience is, and why you find this to be so? I've developed many complex applications with cgiapp, and your statement doesn't seem self-evident at all. I'm curious if it really applies to the other frameworks you list as well.

From the buzz I've heard and my cursory glance through its docs, Catalyst sounds quite well-designed. However, the other frameworks you mention have been around for quite some time and have active developer communities; I'm curious to know what sorts of applications you have in mind that they would not be able to address. I'm wondering if it's more a matter of Catalyst more closely matching your personal coding style than the inability of the other frameworks.

Sorry I did not mean to group CGI::App with the CRUD comment. My problems with CGI::App are that I tend to feel like I need to recreate the wheel every CGI::App app I create. It seems to be so lightweight that you have to build up a ton of the inner workings that make sense for the web framework to provide. After I am done -- I am left feeling as though I spent half my time writing code to make the framework, you know, work. I get the icky feeling every-time I build around CGI::App that I could have done the same thing quickly just building a quick dispatcher on my own. Catalyst seems to add much more groundwork, but at the same time I can overload and change its core behavior pretty quickly without much hassle.

Your comments seem very much in line with Perrin's analysis in his slide
presentation: CGI::App is suited for those who want high flexibility so they
have control over their site. The syntax and methods are both flexible and
extremely simple -- making it both easy to KISS, as well as to overdevelop ;-)

My personal experience is that I develop a framework for each site I work on,
and wrap utility methods/common functionality into a CGI::App superclass. The
application framework -- cgiapp -- lets me choose what needs to be present, and
what doesn't need to be. Every site is a little different, and I don't like to
have more functionality in the application than is necessary.

As an example, I might want a class that simply loads template content into a
sitewide template. I have one run mode, and setup a default page if none is
passed. Done.

Another site might consist of several applications. The body content needs to go
into the sitewide template, and I need breadcrumbs to the application. These
items go into the superclass, and the individual application classes provide
hinting so the superclass can do its job at the end.

I appreciate larger frameworks -- they're great for prototyping more complex
applications -- but in the end I've found that a lighter-weight framework like
CGI::App suits my personal needs as a developer, because it allows me to build
frameworks tailored for the sites I'm developing.

It sounds like Catalyst more closely suits *your* needs, however, and that's
what you need to think about. If you're worried about the longevity of the
project, you can always step up as a developer... ;-)