• There are a few other frameworks, new and historical. This is part of why no one will ever maintain a current webframework FAQ for Perl. It’s too much work and I daresay there is no single JAPH who has the breadth of expertise to do it easily.
• I don’t think Dancer(2) is considered unstable by anyone and Mojo would be debatable.
• Catalyst is fine for any size project if you know what you’re doing, it’s just a deep framework that is harder to learn.
• There is nothing wrong with CGI for tiny projects or expert users per se but it’s not worth learning if you don’t already know it. All Perl webframeworks RFC:SHOULD use PSGI as their interface layer. CGI can be used through PSGI.
• There are deeper concerns than façade and basic structure in frameworks; testing, support, community, longevity, bug density, extended documentation, adoption. I’ve seen few Dancer jobs. I see lots of Catalyst and Mojo jobs. Catalyst and Mojo are both easy to test; I have not enough experience with Dancer to comment on its testing.
• Deployment concerns are probably the biggest hurdle for devs. It’s the only reason PHP ate Perl’s lunch in the end. A deployment wiki/guide would be a bigger help than a framework page.
• Views and Models are not hardwired in (most) frameworks. Even comparing Catalyst against Catalyst could be a 9x9 grid with combinations of 5 or more view layers and 5 or more model layers.

I applaud anyone who attempts to do what you are suggesting. I warn those who ask, “Why the hecking heck isn’t there already such a guide?” that such a guide would have to be simplistic, and minimalistic, to be maintainable.

All Perl webframeworks RFC:SHOULD use PSGI as their interface layer. CGI can be used through PSGI.

Except that as discussed a few weeks back it is very slow with PSGI in a non-persistent environment. Too slow for me to be useful but YMMV.

Yes. Sorry, I should have mentioned. But all webframeworks are slow without a persistent layer and CGI is probably going to be among the fastest. And in any large application, all of them will be too slow for practical use and some, like a big Catalyst app, completely unusable.

Except that as discussed a few weeks back it is very slow with PSGI in a non-persistent environment. Too slow for me to be useful but YMMV.

You're saying CGI program running under PSGI is SLOER than same program running under CGI?

Sounds like a broken program, see CGI to mod_perl Porting. mod_perl Coding guidelines

what you ask (an yearly FAQ dedicated to the Perl Web Panorama) will be a real gift for the community. I fear no one here around has the time and the whole view to write such a thing or maintain it.

Here at the monastery you can collect opinions: many monks have (good) experience in web programming but the number of combinations is such that seems very difficult to get out from the opinion's field.

Even if i'm not an expert in Perl Web programming I have the sensation that Dancer2 is the easier approach for the beginner (even if I remember here some criticisms about the way Dancer handles the routes definitions...).

In the proposition to help you to collect more information (opinions?) i put here some sparse material reference:

• perl as a php alternative your precedent intervetion about Perl web panorama
• CGI Alternatives where I put a lot of links
• Dancer Dancer2 Plack PSGI on my homenode
• Understanding Catalyst

In addition to directly Perl dev web related choice, i think it is worth to mention Template::Toolkit as widly appreciated tool to produce the appearence of Perl web output.

I want to put some emphasis on the ++YourMother sentence: Deployment concerns are probably the biggest hurdle for devs. I think this is damn true! Here the number of combinations become disarming.. The deployer is almost another entire job per se. Choice the appropriate way to deploy a web application is harder than choice a framework.

• Plack/PSGI Application Deployment has good link on deployment (with a good hint about uwsgi)
• Scalable application with perl

L*

> it is worth to mention Template::Toolkit

I'd add Text::Xslate as an interesting templating option, too. If you need template inheritance (smarter inclusion of templates), this is the way to go.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Sorry for a late follow-up but I want to ++ and add: Text::Xslate is dramatically faster than Template::Toolkit. For at least 15 years I have adored TT as a kitchen-sink mini-language and tend to use it via Template::Alloy but I have been reaching for Xslate more often lately because of its speed, it forces good View practices, and it has better web security baked in (HTML escaping is opt-out, |mark_raw, whereas it is opt-in in TT).

CGI.pm was a simple low- or mid-level framework. It has been deprecated. It is still supported for existing projects, but no one should start a new web project with it.

I'd like to address these points specifically because they will serve to reinforce some misunderstandings about CGI.pm if unchallenged.

Firstly, I don't think anyone would call CGI.pm a framework in the modern sense of the word. It is a module which implements the CGI protocol and is only one of several which do so. Some of the frameworks which you and your respondents have mentioned may even use CGI.pm as a frontend but it hardly qualifies as a framework in itself. Note that for smaller sites a framework might be neither necessary nor even desirable. There are of course pure CGI frameworks such as CGI::Application - perhaps this is what you were thinking of?

CGI.pm has not been deprecated. I cannot stress this enough. Some of its methods have been deprecated and with good reason - these are covered in the docs. However, the rest of the module is alive and well and is being maintained. It had 10 stable releases last year.

The thought that "no one should start a new web project with it" is misguided. Anyone thinking of starting a major new web project (multiple servers, distributed data, single-sign-on, etc.) will probably find it much easier to use a framework instead but for simpler scenarios CGI.pm or its equivalents can be very well suited indeed.

You might think of CGI.pm as the IRC of its field. It is eschewed by the hip crowd looking for the flashy new features but if used properly it can get the simple jobs done well and with the minimum of fuss.

I've done one web project in the last 10 years, and I chose Dancer2, simply because I know (not directly) some of the core developers, and the IRC channel gets fast results.

I don't know whether Mojolicious is better or worse for changes that affect your projects, but I did dabble there, and it looks pretty similar, and as effective.

Out of curiosity, you spoke of a couple other languages. Mind pointing out what the de-facto standards there are?

I think Mojo is better than Dancer simply because it is more lightweight and has less dependencies than Dancer. And let's face it, the fact that Dancer has to have a separate 2.0 interface only goes to show that it was not planned as well as Mojo.

I actually agree with you about which is better but not your reasoning. Dependencies, if stable, are not an automatic negative and Mojo makes some opinionated choices with which I disagree; though don't argue it's the developers' purvue. E.g., Mojo::DOM should not be in Mojolicious. It is useful on its own and would be exactly the same overhead as a dependency.

Mojo has 100ish code modules in it. This means it's not necessarily more stable than a package of, say, 30ish with 20 dependencies. I recognize differing versions come into play here but not as a hard rule.

What about mod_perl? I've used it in combination with jquery. I'm no expert, but it was very fast.

on CGI.pm deprecated: I just followed what the maintainer himself wrote: all_software_is_legacy.

on other languages, I am not an expert, either. however, I *do* know that when someone starts webprogramming in ruby, there is one framework everyone learns first: rails. when someone starts in python, everyone seems to start with django. and php is sort of its own (braindamaged language and) web system. it's only advantage is that the web is built in. In a sense. CGI.pm was the web-built-in in perl. all of the above languages offer alternative (quasi-)frameworks, too, but this is what almost everyone starts with.

I think it was a good idea that perl would switch to a better standard web system than CGI.pm, but I don't think it is helpful that there is not one standard that starters should first goto. I think it hampers us. yes, there are many way to do things in perl, but some basic methods (design patterns ;-) ) are useful. for example, I believe Moo* is now a standard for object layers. Perl6::Slurp is now quasi standard. chomp(). etc.

HELP: in the absence of complete comparisons, why should anyone start with Mojolicious over Dancer2, or vice-versa? who should start with one or the other? /iaw

Agree 100%++. I would love to see Mojolicious become the universally and dogmatically recommended Perl web framework. I think it is the best competitor to php that Perl has to offer, much easier to use, learn, start, grow.

I’ve used them all and I am firmly in the Mojolicious camp. Now, I will say, the Catalyst BOOK is one of the best Perl books you can buy. I think it has great software engineering, Test Driven Design principles.

Where is the evidence for claiming that Mojolicious is not stable? Or that it is not appropriate for large projects?

I would start by showing off how immaculately Mojolicious is maintained on github, but that may not be objective enough. So maybe that is the first step, building a set of objective criteria. I am so down to help with this project. SO DOWN.

I had a mojolicious website that was built 2 years ago and was running...and then it no longer ran. I needed to hire an expert to figure out what was wrong. wasn't a big deal for the expert, but not possible to find out for a non-expert. (CGI.pm never broke. I presume plack/psgi don't either. All low-level enough. I presume Dancer, Mojo, and Catalyst need some tending...)

Can I renew my call for a basic question: why Dancer2 over Mojo? why Mojo over Dancer2?

(Incidentally, are any web frameworks planned to work with perl6?)

/iaw

Boring. If not Trolling.

I think it's unlikely that you'll get any useful answer to this question. The chances of anyone being familiar *enough* with both frameworks to say "this one is better" with authority are very slim.

Most people try one or the other, or both, or others, for simple experimenting, get turned on or get turned off, and then stick with one. Only thereafter do they begin to become competent enough to offer any really useful advice. So you'd have to get the apples report from the apple seller and the orange report ...

If you want useful information instead of asking for something no one can tell, ask people to say what they like and don't like about what they use. Then parse the info, make some choices, try some things ... You are asking for someone to save you the work of deciding whether you like scrambled or fried eggs.

And for the love of all things Holy please don't conflate "Perl6" in this discussion. It's a different language and you might as well ask about frameworks in any one of dozens of them: the answer, if there is one, will not be relevant in the slightest.



The way forward always starts with a minimal test.

I am so down to help with this project. SO DOWN.

Hello Trippledubs. I saw you were happy to help with this project. Did it begin at all? Has any work been done so far?

Was it intended that the guide be on PerlMonks, or elsewhere?

No one has started it. Should it be started, the right place is github, not PM. Github makes it trivial to collaborate and that would be crucial for a project like this.

the Catalyst BOOK is one of the best Perl books you can buy. I think it has great software engineering, Test Driven Design principles.

Which Catalyst book specifically are you referring to?

The Definitive Guide to Catalyst: Writing Extensible, Scalable and Maintainable Perl-Based Web Applications, ISBN 9781430223658.

Agree 100%++. I would love to see Mojolicious become the universally and dogmatically recommended Perl web framework. I think it is the best competitor to php that Perl has to offer, much easier to use, learn, start, grow.

Why ?

Seems like some kind of misunderstanding

php is a language, like perl

and Mojolicious is a framework , written in perl

The two things aren't competitive with each other

The whole of why php gained an edge over perl is because of big web hosts, mod_php under apache... , for faster than cgi, lighter than mod_perl...

With passage of time and the rise of virtualization and things like nginx/fcgi/uwsgi.... the hosts have caught up and what they're selling these days is choice, anything the developer wants he can install

I would say Mojolicious does compete with php in that they both perform the same function and using one mostly precludes using the other. Just like using Mojolicious precludes using the other frameworks. So choices have to be made. I'm just unequivocally saying that Mojolicious is the best. Other opinions are like, well "they all do the same thing" or "well you might try this if situation x". Or, "I was telnetted to a dancer server one time". Yeah, no. I'm saying one is far better than the others.

See this node in the thread.



The way forward always starts with a minimal test.

Thanks! =D

That post points out a minimal and simplistic guide would be easiest to maintain.

Do we know though, if anyone who expressed interest in this idea on this thread, has begun such a guide yet or not?

The point on the usefulness of a deployment guide in that linked to node, is also heard.

I found this node the same way and am thankful that this question was asked and discussed. I have not tried any framework yet and was trying to find which would be the easiest to learn and I think I got my answer.

It's Mojolicious!

You might be right that it's the easiest but it does have a bit more off-center DWIW magic than the others. What I think it does do best is its helper (like Mojo::DOM) and testing utilities. Please avail yourself of the testing especially. I don't think anything else makes it easier to write tests against web applications; Selenium being an exception perhaps because you can record tests and they respect JavaScript too.

Update: added <abbr/>.