The only gotcha is Mouse ( aside from the standard CGI gotchas of "slow" )

Moose -> Moo -> Mo , no Mouse :)

See https://metacpan.org/pod/perlootut#Moo, <- Replace Mouse with Moo in perlootut - nntp.perl.org -> Replace Mouse with Moo in perlootut - nntp.perl.org

bah, ctrl key failing :) -> Moo versus Any::Moose

++ Thanks for these links: that's newer information than I currently had to hand.

-- Ken

No real gotchas. I prefer Moo to Mouse/Moose. I think the defaults are better and things like inline “type” checking more Perlish; more self-documenting; easier to remember.

Mouse is much faster than the other meta-OO options. So, if this were my project the choice between Moo and Mouse would boil down to the execution. If the app is persistently executed, I’d pick Moo, otherwise, Mouse. If it’s persistent then you should be looking at running/harnessing it as PSGI too, whether or not the base code is in CGI.

…Then again, some casual tests on the command line suggest the start-up speed of Moo is only 0.001s slower than Mouse so maybe Moo anyway depending on how many objects and how much access you’re wrangling. I have also had far fewer cross compat/build/deps problems with Moo than Mouse or Moose, FWIW; in a very static env this shouldn’t matter though.

++ Thanks for this excellent answer: good information on both Moo and PSGI.

-- Ken

> the start-up speed 

Maybe a silly question, but if start-up speed is so significant why isn't there a precompiled version of Moose?

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

PS: Je suis Charlie!

I don’t think it’s silly. The Mouse is precompiled essentially being XS (when built with it). I expected it to be faster actually but regular old Perl often surprises me with how fast it is. I tend to forget that most of why stuff at work is slow is awful DB code and not just the awful Perl we have. :P Doing thousands of objects and methods would probably make the Mouse a clear winner. So it would depend on how big/complex the code chains will end up.

Start up time is only a (serious) issue if running plain CGI as executables; which is a terrible way to do things but still the easiest. Our codebase at work is 50% legacy CGI that was finally taking 3 seconds to return simple pages—code bloat and universal loading of all the libs we have. Making it persistent (pre-compiled by a master server) fixed (most of the outward perception of) that.

For anyone possibly suggesting other combinations, the CGI component is fixed (that's out of my control).

Are you modifying existing code?

CGI is not the only module (family) that "speaks" CGI to the webserver.

Thanks for the reply.

I can't say too much as this is for a commercial project. I'm under contract to work on specific code; the CGI component is not currently within my purview.

-- Ken

Many thanks to all for much useful information. ++s have been strewn liberally. I'm going ahead with Moo instead of Mouse.

Thanks for the reply. I really was just after any issues that may have been encountered with the CGI+Mouse combination.

-- Ken

I've used Mouse and Moo under CGI in the past, and found response times with Mouse noticeably longer. However I wouldn't use Moo for new projects because of the anti-modular code that results from it.

I hope you wouldn't mind if I rephrase the question you didn't answer. Which of the following statements is correct?

1. You don't realise how anti-modular Moo is
2. You know that Moo is anti-modular but don't see that as a problem