I prefer Dancer. Easy to get started, easy to extend, and the features that you start reaching for after awhile are there and not too hard to learn. The best example I've found is looking at the Perl Dancer Web site code itself, available at https://github.com/PerlDancer/perldancer-website/ That way you can look at the web site and the code to see exactly what it produces. Once you start templating it becomes very efficient to add content to your site instead of learning how to use the framework.
| [reply] |
Don't forget CGI::Application - it's pretty good, too.
Of the others, Catalyst has the steepest learning curve, and the greatest start up overhead (many modules to load), so it may appear slow unless you run it under mod_perl or FastCGI (i.e., not my first choice for use in a shared hosting environment).
| [reply] |
Reckon I have both sworn by, and sworn at, all three of ’em in my time.
Now, my own perspective might be a wee bit unusual because, in all cases, these were existing projects, that had all lately fallen on some hard times. They had been around for several years, were all in revenue production, and had been built by someone else who had since gone on to greener glades. (In one case, all the way to the Elysian Fields ...) In the case of Mojolicious, it seemed to have been a case of too-early adoption since that framework really wasn’t yet mature-and-stable at that time. But the frameworks were all doing their job acceptably well, and they still are today.
“Bugs,” per se, in all three cases, should not be a problem. At least not with respect to their code, heh. But it’s extremely important at this stage to look for a smooth fit to the entirety of what you want your web-site to do. Every framework, so to speak, “has attitude.” The designers have one notion of how something “should” be done, and they designed and built the software to do that, and in that way. (Incidentally, I do not mean that comment “personally.”) Like every architect does, they put scopes and boundaries on the project (all in different places), and to go outside of these they provide some sort of “plug-ins” and this is where you can run into trouble if you’re going to. Scope out your project completely and see what fits best. Don’t just think-so ... prove it.
Last comment is to, from the start, get to know Test::Most, and Selenium, extremely well.
| [reply] |
i investigate some time in balancing reasons pro/cons for Why not share what you investigated?
| [reply] |
| [reply] |
Hi,
I tend to find these things come down to personal prefrence. Give them all a good go, including building a small tester with all of them.
One important consideration that can be overlooked. If you have been put in charge of a team, check out their experience.
If they are all good with one of the frameworks, you have your answer.
J.C.
| [reply] |
| [reply] |