Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

lachoy (1663)


I am actually Chris Winters; I am actually living in Pittsburgh, Pennsylvania, USA; I am actually married and have three cats. (Guess what one of them is named?) I am the "OpenInteract" guy, which could be good or bad.

Journal of lachoy (1663)

Thursday December 11, 2008
05:15 PM

Perl webapp frameworks: what to explore?

[ #38076 ]

I've been working pretty much exclusively in Java for the last few years. However, we have a subproject to do some system/application automation work that's written in Perl. It's currently a CLI tool that allows us to install/upgrade our application remotely, restart the service(s) (the app runs on Solaris), and other fun stuff.

We're not only expanding its scope, but we're giving it a nice shiny GUI shell via a website. After working for years on Perl webapps I've been out of the loop for years. That can actually be a worse position than not knowing anything, because I have outdated ideas and biases as to how things 'should' work.

And now we get to my question. It looks like people are commonly using Catalyst, CGI:Application, Jifty. Are there others? And what's the "best" one to use?

Some constraints/ideas:

  • I hope to not have to deploy an RDBMS, so if a framework requires one it's out,
  • Built-in REST support would be nice,
  • Gobs of dependencies aren't too scary. We're hoping to deploy this in a Krang-like fashion, entirely self-sufficient and black-box[1],
  • Easy to start and easy to maintain (should go without saying, but these shouldn't be a trade-off),
  • Team composed of solid Perl folks but webapp newbies or webapp geezer (me).

Perl is supported at our company for a nifty internal testing/automation suite, some build automation, and probably under-the-radar stuff, but that's about it.

By comparison, this is a project we're not only hoping will be long-lived, but it will be deployed on servers not in our control (thus the Krang-like deployment above), and used by people (mostly IT staff) not in our control.

Will they freak out that this is a Perl app? Unknown -- what do you think? (This is IT in healthcare, FWIW.) Do we even need to tell them it's Perl (e.g., "it's a black box")? Unknown, but IMO we likely do.

Reading the recent 'perl is dying/dead' threads here [on use.perl] also makes me wonder about hiring. Hearing that quality organizations are having trouble finding competent Perl developers is disturbing, whatever the reason. For instance, take Grant Street. From what I've heard, they have a solid team that gets to work on pretty interesting stuff, not your typical CRUD tedium. You'd think with that combo they'd attract competent people like honey attracts bears. But they're always looking.

There's always an argument that you can hire someone smart and they can just "pick up" the language/platform. I think that's true if you have 6-12 months to burn. It's easy to learn a language, even Perl. It's harder and more time-consuming to learn its ecosystem -- which modules to use and not-use, idioms, approaches for common tasks, etc. It's not that these things are required to get things done, it's that the rest of the team will have to go over all of the new hire's work much more closely.


[1] Wasn't there a project to extract the Krang build logic into something self-contained? The projects occupying that area of my brain are 'Smolder' (which is aimed at code coverage and reports) and 'Matchstick' (which looks to have been abandoned). Is there something else?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • If you write it like a perl app from 10 years ago, they will probably freak out. If you tell someone who doesn't read source code that it is a perl app, they might freak out.

    If you write it like most Catalyst devs say to, you'll probably have a well-engineered and maintainable app.

    Disclaimer: I'm not a webapp developer.

    • The "freak out" comment was more about it being in Perl than the technology. I suspect that if we pitch it as a black box that does HTTP we'll be okay, but I'm a little wary -- because of inexperience, not because I don't think Perl can do what it's supposed to.

      Good words about Catalyst though, thanks.

  • A pre-written app like webmin [1] might suffice.

    But if you're writing it, I suggest starting with CGI::Application.

    As for a database, I'm doubtful you will do well without one, so add BerkeleyDB [2] to the mix.

    [1] []

    [2] []

    • Regarding no database: you can do an awful lot with the filesystem. I have a couple of reasons for wanting to ditch the database:

      1. Acceptance: It's another piece of technology for end-users (IT folks) to object to -- "Perl's okay, but we're an MSSQL shop!"
      2. Complexity: Typical ORM mismatch foo.

      Good thought about BerkeleyDB though. Even though it's gained a lot of complexity you can still use it very simply.

  • It pretty much satisfies all of the items you require, especially if you look at the Catalyst::Plugin::ActionClass::REST (or whatever it's called) on CPAN. I've deployed sites without a database (in fact my geneology [] site has just a single static file as it's "Model". CGI::Application is also a fair choice, though I've never used it directly.

    As for Grant Street Group. I've sent my resume into them twice and never heard from them (not even a confirmation that my email was received). I know others who have ap

  • It is actually quite easy to separate the build system from krang. I did that and use it in my projects. I have put it on google []

  • If you're looking for something with low dependencies and low learning curve, CGI::Application is definitely the way to go. You could also use something like Titanium which is pretty much just a bundle of C::A and some of it's more useful plugins.

    As far as self-contained apps go, you could go the Krang, PAR or CPAN route. All of which have problems:

    PROS - This is what I did for Smolder and it makes installation fairly simple if you know what platforms you're going to deploy to since you can prebu

  • Catalyst has some builtin PAR support. []

    Reading the recent 'perl is dying/dead' threads here [on use.perl] also makes me wonder about hiring.

    They're not dead/dying but sometimes they think life stops, unless/until Perl get the best OO model, easiest deployment, best libraries and so on, and so on. They're just so demanding to their selfs.

    • If we can't improve Perl beyond fixing bugs, why is there even a p5p? When did Perl become the sound of the wall I'm beating my head against?

      • I think we can/should/will (improve Perl 5), but meanwhile we must learn to live with the shortcomings it has. No language or environment is perfect. This wouldn't be a problem, unless clueless people start to believe the FUD arising from this self criticism.

        I really wouldn't like to distract the focus from Perl 6 since it will be a great step forward for the whole world of programming, but there are success stories written all the time with Perl 5. Not seeing this and appreciating it alienates unaware peop

        • The existence of Perl 6 is no excuse not to improve Perl 5. The fact that you can declare a class in Perl 5 with the package keyword and subclass a parent with use base or pushing onto @ISA does not mean we can never add a little syntactic sugar to make that code clearer and more convenient.

  • If you're allowed to build things a bit from the ground up, you should play with Continuity. I've found it to be fantastic for almost direct ports from command line to web interfaces.