Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

UP-TO-DATE Comparison of CGI Alternatives

by iaw4 (Monk)
on Feb 26, 2017 at 22:18 UTC ( #1182902=perlquestion: print w/replies, xml ) Need Help??
iaw4 has asked for the wisdom of the Perl Monks concerning the following question:

A comparison of tradeoffs using various web technologies should probably be a FAQ and updated once a year. The web is important, and unlike ruby and rails (or python and django?), there is really not one recommended dominating web framework in perl to start with.

I am going to start this post with what I understand.

  • 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.
  • PSGI/Plack is expressly middleware. While powerful and stable, it really is not designed for writing websites, but designed for use in higher-level frameworks. The authors are not too happy with (or equipped to) handle large number of noobie requests on how to use it, and the examples in the documentation are modest.
  • The two primary choices for new modest-size websites are Dancer2 and Mojolicious. They have good documentation and are suitable for newbies. (Both frameworks are or can be users of PSGI/Plack, but this is transparent to the user programmer.) They are good high-level, but not stable. In particular, I know that Mojolicious is evolving---projects can break upon M updates. I don't know about Dancer2.
  • For large projects, Catalyst becomes a third alternative.

So, for someone new who wants to learn how to code a website, there seem to be two primary perl choices. If my reading of the landscape is not correct, then please correct it. And if someone could please post the pros and cons of Dancer2 and Mojolicious---so that one does not have to learn both first to start with one---it would be helpful.

Personal Observation: What I liked about CGI.pm and Plack/PSGI over the frameworks was that lower-level code makes it easier to determine what perl code was responsible for displaying a given web page. With the frameworks, by the time all routes, templates, injections, etc., are considered, it becomes hard to trace how the given web page has been built. Where web programs are one's primary responsibility and used every day for years, the linkage within the frameworks is not a problem. One remembers instantly what was where. Where web programs are occasional tasks, separated by long periods of neglect, this becomes more difficult.

thanks in advance to the experts for illuminating the issues.

  • Comment on UP-TO-DATE Comparison of CGI Alternatives

Replies are listed 'Best First'.
Re: UP-TO-DATE Comparison of CGI Alternatives
by Your Mother (Chancellor) on Feb 27, 2017 at 00:34 UTC
    • 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

Re: UP-TO-DATE Comparison of CGI Alternatives
by Discipulus (Monsignor) on Feb 27, 2017 at 09:07 UTC
    Hello iaw4,

    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:

    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.

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
      > 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,

        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).

Re: UP-TO-DATE Comparison of CGI Alternatives
by hippo (Abbot) on Feb 27, 2017 at 09:52 UTC
    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.

Re: UP-TO-DATE Comparison of CGI Alternatives
by stevieb (Abbot) on Feb 27, 2017 at 00:19 UTC

    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.

Re: UP-TO-DATE Comparison of CGI Alternatives
by nysus (Priest) on Feb 26, 2017 at 23:27 UTC

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

    $PM = "Perl Monk's";
    $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
    $nysus = $PM . ' ' . $MCF;
    Click here if you love Perl Monks

      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

Re: UP-TO-DATE Comparison of CGI Alternatives
by trippledubs (Hermit) on Feb 27, 2017 at 17:16 UTC

    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.

Re: UP-TO-DATE Comparison of CGI Alternatives
by ajmetz82 (Novice) on Jul 15, 2017 at 22:35 UTC
    Did anyone go ahead and start such a FAQ?

    I just discovered this conversation thread via google, and it seemed a great idea!

    Did anyone make a start on collecting opinions, or people's likes and dislikes of each, as suggested in this thread?

    I learnt Mojolicious in 2015, and Catalyst in 2016. Most of the sites I work on, were started in 2016 on Catalyst, only I'm contemplating whether I should do a few projects in Mojolicious again too, so I can keep up my familiarity with both frameworks, or whether it really is easiest to just stick to using one, ^_^. This led to me googling Catalyst or Mojolicious for which this thread (once limiting search results to the past year) was the top result.

      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/>.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1182902]
Approved by stevieb
Front-paged by kcott
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (5)
As of 2018-01-20 07:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How did you see in the new year?










    Results (226 votes). Check out past polls.

    Notices?