I haven't used Reaction and I got the feeling the last I checked that I should not yet but I and a few others will answer Catalyst questions here (when I know the answers; the list is also quite good and responsive).

Using Catalyst (and DBIx::Class) in the last two days I ported the DB interaction (models/schema), login, splash, and a couple of forms of a legacy app. 80% of the time was spent on config settings and CSS. I expect to have almost the whole application ported by New Year's. All of it with tests (or so I say now but I've been keeping up pretty well) and much more stable than its prototype and doing things the old one couldn't like UTF-8 data and deployment with configuration changes instead of hard coded Perl changes per client.

For your first Catalyst project, that timeline is unrealistic. It has a learning curve; as does DBIC. But once you're in it it's freakishly pleasing how you can do things like an RSS/Atom feed in 5-10 lines of easy to read (in the context of the app and model) code. And how easily you can graft in legacy code and fix it when you have time. In an app I wrote a year ago I had a bunch of file handling embedded in controllers. I recently went back and broke it out into model classes and made it configurable (another strength of Catalyst; the configuration can come from several places in several formats and be easily overridden by location or whatever you please).

Catalyst can feel like an uphill battle at first but once you're sitting on a running app you'll be really glad you made the jog.

It occurred to me that there ought to be a canonical way of answering questions like this. The two methods that occur to me are as follows:
• Look at the reviews on CPAN. The weakness here is that I cannot find a way of asking for modules doing something similar.
• Look at the Q&A on perlmonks which does cover some questions of this sort (though in a discursive way).
How easy it would be to build lists of modules for a certain purpose (OO frameworks, CGI framework for example) based upon CPAN review ratings either in CPAN or perlmonks? I suppose one issue is that for most purposes there is a clear winner, but this is not the case for these two examples.

This "lists of modules for certain purpose" idea is being realized at the p5p wiki.

Update: There is also Task::Kensho a list of modules maintained by the Enlightened Perl organisation.

Well, the good news is that I am not-at-all unfamiliar with Catalyst, but I am obviously trying to be as up-to-date as possible ... to whatever extent might be prudent ... specifically at this preliminary-review stage. This is the one, and only, point at which “the ship has not yet embarked.”

There is no question in my mind that a high level framework must be used, and that it should be Catalyst. Nonetheless, I admit to being quite intrigued about what I see (and what I hear being said-about) Moose. The possibility of advantageously using mix-ins, and its relationship to Perl-6, and other reasonably “forward-thinking things,” ... well, now's the one and only very-best time to be considering this sort of thing, as all of us well know.

Reaction (although it has been mentioned in-“print” for about a year now) does not yet seem to be accompanied by a complete and articulate description (in the form of cohesive and complete perldocs) of just why it is so great. Nevertheless, “the brains behind it” are rather formidable. So, “I don't doubt it, but I don't see it (yet).”

I am “window shopping.” Very quickly. Catalyst is already an established definite-yes. And right now is the one best time to be canvassing the others.

Thanks to you Monks, one and all, for your (continuing) opinions on the matter.

You also can't forget that "very shiny" is awesome, but you can't let the up and coming new things get in the way of your work.

If you're spending more time trying to keep up to date than getting code written, you should probably reconsider some practices :-)

I find following something, say, an application, through from beginning to end is the only way to truly learn something. Then begin learning something new, etc. You can ALWAYS take time to rewrite something to do it the *right* way though. But remember, not always is new and shiny the *right* way immediately :-)

meh.

Well, I'm probably slitting my own throat here, but here goes.

My answer would be, for Reaction, a resounding "not yet". It has great potential, but it is a very long way from being ready for prime time, or really even ready for playing-with.

It is extremely cerebral - possibly over-abstracted but time will tell on that. Being overcerebral is forgivable if you've got great docs, featuring concrete examples - which the Reaction project certainly doesn't yet. In fact, most modules don't have POD at all, and those that do, are almost all doc stubs. I'm certain that it improve will eventually - but in the meantime, you'll be lost in a haze of terminology that is used inconsistently both in the scant docs and on #reaction.

I recently (October 2008) consulted on a project in which the project lead - a big Catalyst fan - was talked into using Reaction (by the Catalyst and Reaction projects founder's consulting group). It was a fairly straightforward web app, mostly CRUD but with some interesting summarization needed for reporting. The project was repeatedly delayed by the need to address the lack of documentation - longwinded lectures from the consultants being the only solution. The project came in late with reduced functionality after many long hours and frayed nerves. I don't know about you, but I want a framework to make my life easier, not worse.

So, overall, for production work, I think Reaction is just way too immature at the moment. You can always implement in Catalyst, and then moving to Reaction won't be very painful once it's ready.

If you insist on using Reaction - which I can't advise against strongly enough, for the time being - I'd suggest becoming a regular on #reaction and/or hiring the aforementioned consultants - it's unfortunately the only way to get the knowledge you'll desperately need to work with this complex system.

All that said, if you've got time to play with it, I'm sure they'd be eager to get docs patches.

Okay, that settles it for me. I'll wait. Thanks.

“Slitting your own throat here?” Heh... That's why we invest our time here. “Blunt professional honesty = Priceless.”

And... lest anyone from the Reaction group think that this is “a negative reaction” ... I think that it is quite fair to say:

• Rome was not built in a day... neither was anything else on CPAN. “We can wait!”
• “We shall make no wine before its time.”
• Meanwhile, we all have customers to serve.   :-D

I, like you, am very interested in Reaction (and based on my code-reading this evening, I am...), and willing to wait-a-bit for its maturity. I see now that I don't have to “shut the door on” using it effectively within the scope of even this project. To leap onto this bandwagon prematurely ... is quite unnecessary.

Thanks again.

Being the project lead clwolfe refers to above, allow me to diatribe my view:

To fully take advantage of Reaction one needs solid working knowledge of Catalyst, M(F)CV pattern, OO, Moose, and most likely an ORM such as DBIC. These skills don't come overnight or a even in a fortnight, but for me me they are valuable skills to seek.

IMHO, Reaction breaks an application into more than just the three traditional parts of the MVC design pattern. For instance, it requires splitting the model into two parts: business domain and an interface between the business domains and the controllers/views. The views divided into widgets and layout (nested containers for the widgets). In a simpleton's world you may say Reaction carves the app up into 5 or more parts.

It is true that Reaction is in an early stage and the documentation is growing from sparse to better, but needs community help. What isn't true is the claim that I was talked into using Reaction. It was a choice I made based on a number factors, some better than others:

* The success I had with mst's perl contributions, even modules at early version numbers.
* The idea of diversifying the model into multiple components.
* Being involved with an open source project at an earlier stage.
* Securing the interest of busy consultants to help us with a substantial project with very short turn-around time.
* Expand my comfort zone
* Move away from homegrown components of a framework to standard libraries, or at least libraries being standardized.

One can see that there was some risk involved being an earlier adopter, but the project did not come in late. In fact we achieved one of the few major deadlines in the entire contract so far. Did we get on each other nerves some in the process, hells yes. Did we have reduced functionality? I would say not. What we had was the (I should have known) moving of the goalposts. Do we need such and such feature (from previous system we were redesigning in similar but not exact business domain)? The answer would be no at first then change to yes in midstream of a super-tight deadline. We delivered all the original functionality and more on time. We hadn't planned on scrapping the whole data model we were forking from a similar project, but at the last hour possible we did. That created the most stress, but that data model change from the old cankerous model to the intelligent design model has been a builder's stone worth creation. Changing the data model allowed the the whole application to coalesce using Reaction libraries and Catalyst in short time, and it smoothed the way for data population and computation.

Reaction is definitely not for everybody, and it probably isn't but for the minority of perl web app. devs, but it is a vital project that delivered a solid application for us on time. If you are comfortable with Catalyst or another M(F)CV and would like to enrich that experience then Reaction is definitely worth investigating.

Docs may not abound, but there are some examples and I be willing share our code with anyone interested. Reaction evolves quicker with action not words.

Get your fingers dirty with it. I did. And it's helped me even developing straight Catalyst applications that don't use Reaction.

#reaction on irc.perl.org would be more than happy to help you decipher anything that needs deciphering. I'm actually working with mst and jnapiorski on writing up some Reaction documentation to help people understand how to use it and how it will help your Catalyst application.

Feel free to /msg me if you have any questions, Reaction is REALLY cool.

/me reads my original post, thinks better of it, and tries again... <blink> :*{ </blink>

Okay, this is what I have done now:   I grabbed the latest Reaction distro from CPAN and went to the appropriate directory in .cpan/build and started looking around for .pods.

Anywhere I could find them in there...

I found some of the “new” ones (as well as the old ones, which are apparently the ones now on search.cpan.org)...

The file in blib/lib/Reaction/Manual/Intro.pod is very informative compared to the last one, but it is still only the barest glimmer... of something that, nonetheless, looks very shiny...

And so, I'm doing the next thing:   reading the code.

What I really need most right now is some complete example.

There are a few examples in the Examples/ directory. Namely the Vienna-TT example, the Mailer example, etc. And did you drop by #reaction on irc.perl.org like I recommended? :-)

meh.

Inversely proportional?

Yea, maybe if you're using Rails :-)

That's kind of the point of Catalyst, is to stay out of the way but provide you a ton of leverage when you have a large scale web application that you're putting together and you need all kinds of flexibility. Most likely if it's that big of a web application, it's going to have some sort of effect (positive) on Catalyst's core code and will be integrated one way or another. Or at least provided as a set of nifty plugins/CatalystX:: modules :-)

meh.

Good luck with that. My experience is that the only frameworks that don't get in your way on a complex project are the ones that do almost nothing to help, e.g. CGI::Application. As soon as a framework tries to make things easier by helping out with sessions, databases, page widgets, etc. people who are trying to do something unusual start banging their heads on it. This is not a Catalyst thing or a perl thing but rather a general software thing. Software problems are just not as easy to generalize into frameworks as we would like them to be.