New Internationalist

Exploring Perl web frameworks

A couple of years ago I started looking at options to deliver common “front end” functionality for sites using Bricolage, the content-management system that is used at New Internationalist

Initially, what I had in mind to provide this front-end functionality was a “swarm” of micro-applications, where each little application provided one simple, specific, function, e.g., user registration, comments on content, voting and rating, sharing content, etc. There were other people thinking along these lines too, and – eventually – I came across the MicroApps project, which stated its philosophy as: 

MicroApps are small REST applications that are designed from the ground up to be integrated with other applications. Usually, they are not directly useful on their own, but must be integrated into other applications (this is what differentiates a MicroApp from a regular REST application).

Unfortunately, the project appeared to be at a standstill, and my experience with Python was pretty limited. Most of my experience is with Perl, so my investigation headed in that direction, and eventually lead to the topic of this post: Perl web frameworks. 

While they may not often be used for micro-applications, Web frameworks are all the rage. You’ve probably heard of Ruby on Rails, and you may have even heard of Django (a Python-based web framework) or Symphony (PHP). Put simply: these web frameworks aim to make web application development faster and commonly “bake in” some best practices. 

Yes, Perl has CRUD too

Perl, though frequently dismissed by the youngsters, is not a language that likes to get left behind, and there are now several Perl web frameworks to choose from. 

Around the time of thinking about micro-applications, I stumbled on Jifty. Jifty was developed by Best Practical – an established software company in the Perl world – and was used in the production and delivery of their Hiveminder application

I had heard of Gantry, Maypole, and Catalyst (and – of course – CGI::Appliation) but I had not really given them much attention until I first read about Jifty

Fast forward to 2009. We’re underway with a number of initiatives of strategic importance to the New Internationalist – re-launching NI’s various web properties – and so it’s time to start thinking again about the technologies that will carry NI forward. 

My colleague Charlie had been recently experimenting with Jifty and Catalyst, and – in the interest of the experience to be gained by getting one’s hands dirty – I also decided to jump in and re-explore the state of Perl web frameworks. 

This time I thought I’d look at the three most active, or promising, options: Catalyst, Jifty, and Mojo/Mojolicious. (I also took a pretty close look at CGI::Application, but decided to pass on that for now.)

So, far from an evaluation, I thought I’d just jot down my first impressions of where these frameworks are by exploring how easy it is to get up-and-running and working through their tutorials. 


My development environment for this adventure was VMware’s Fusion on a MacBook Pro and a stock Debian 5.0 “Lenny” installation. 

I started with the Catalyst installation documentation and followed their instructions for an installation using aptitude. Though the basic installation went well, it seemed to leave me with many missing modules, including Catalyst::Devel (which is odd, as that appears to be a rather critical piece). After various attempts to create an application skeleton or start up the web server, I was able to get the various missing bits installed via CPAN and to get everything working. On to the documentation and tutorials…

My first impression was that the documentation was very well maintained. The tutorials are abundant and thorough, and make attempts to address the various versions of Catalyst that are out there in the wild. Thanks to the tutorials, I was able to get a simple test application set up relatively quickly. 

However, what Catalyst makes up for in documentation, it lacks in simplicity. As the Catalyst documentation states:

Catalyst is designed for flexibility and power; to an extent, this comes at the expense of simplicity. Programmers have many options for almost everything they need to do, which means that any given need can be done in many ways, and finding the one that’s right for you, and learning the right way to do it, can take time. TIMTOWDI works both ways.

Compared to the competing Perl web frameworks or web frameworks in other languages, I found that Catalyst required more effort to get started and doesn’t provide an out-of-the-box experience. Not a bad thing but a consideration nonetheless. 


For Jifty, this time I went with the suggested apt-get install route to get things downloaded and installed. Unfortunately, the first thing I ran into was this rather intimidating warning:

WARNING: This key is not certified with a trusted signature!

Moving right along, I installed the package anyway and tried to set up my first application. Like Catalyst, I was presented with various errors about missing modules. One Google search and several CPAN installations later, as promised, I got a Pony. 

One nice thing that Jifty gives you out-of-the-box is an administration interface, making it easy to start adding test data to your model. The other really helpful thing that Jifty provides is, well, everything. Part of what makes Jifty so cool is:

Out of the proverbial box, Jifty comes with one way to do everything you should need to do: one database mapper, one templating system, one web services layer, one AJAX toolkit, one set of handlers for standalone or FastCGI servers. We work hard to make all the bits play well together, so you don’t have to.

Which means trading off options (as in the case of Catalyst) for simplicity.

Jifty’s documentation is a little rough around the edges, but the tutorials are up-to-date and I was able to get my test application running and doing fancy, AJAX-y, stuff in no time.


Mojo is a “A next generation web framework for the Perl programming language” and Mojolicious is a MVC framework built on top of Mojo. The primary author of Mojo – Sebastian Riedel – was one of the founders of Catalyst and, with Mojo, he sets out to create something more like Jifty – or, if you prefer, “the web in a box.”

Mojo was by far the easiest to install: just a straightforward tarball to download and a few Perl “make” commands and Mojo was up-and-running. 

Unfortunately, the fun stops there at the moment. Mojo is very new and provides fairly limited documentation to work from. And, idling in the IRC channel, one can see lots of activity and signs that there is much work to be done before Mojo becomes a practical alternative to Catalyst or Jifty. However, once it does, it’s going to be one to watch. 


So, a few parting thoughts on my exploration of Perl web frameworks:

  • I worry that some of the installation issues I ran into will discourage other people to try these incredibly powerful frameworks. It’s been years since I’ve looked at any of the competing frameworks in other languages, but my guess would be that most installation issues are ironed out and the process is dead-simple. 

  • However, any time I ran into a problem, I was able to hop into the IRC channel for the project and find friendly and helpful advice. All three project’s channels are active and filled with idling contributors. 

And, for me, the current prize goes to Jifty for being friendly to developers of all experience levels. For rapid application prototyping, Jifty makes the set-up process fast and easy, provides a full stack for application development, and makes a lot of relatively unimportant decisions (database mapper, Javascript toolkit, templating language, etc.) for you right upfront. 

I’m anxious to see what Charlie comes up with during his explorations of the same. 

Comments on Exploring Perl web frameworks

Leave your comment


  • Maximum characters allowed: 5000
  • Simple HTML allowed: bold, italic, and links

Registration is quick and easy. Plus you won’t have to re-type the blurry words to comment!
Register | Login

  1. #1 David 21 May 09

    I'm surprised by your Catalyst on Debian experience. Catalyst::Devel looks to be part of the libcatalyst-modules-perl package which libcatalyst-perl depends on, so it should have been installed.

    Though I am running Debian unstable and I noticed they updated the Catalyst packages recently (within the last month), so perhaps something was fixed?

    I also run Catalyst right on my Mac, which you might try too, though it takes something like 100 CPAN modules. They all just work though. I think the only non-CPAN dependency I needed was libmysql for the DBIx::Class stuff.

    I used Catalyst on a consulting project and enjoyed it very much. I can't wait to try something with the new Moose based version.

  2. #2 21 May 09

    A Framework is for Life

    There's a good reason that Catalyst has a bit of a learning curve. It's like getting a puppy, there's a lot of up front effort required with toilet training etc, but in the end you get a valuable addition to your family. Hopefully by the time the [a href=’’]new book is out (on July the 12th 2009 ) we'll have made it a lot easier to install Catalyst, at least for testing/evaluation purposes.

    Moving away form the puppy analogy, the payoff from Catalyst isn't from getting it up and running in the first 5 minutes, it's 6 months into your project when development is just as fast as the early days (or faster if it's your first project and you had to get through the learning curve).

    In any case, the maxim is definitely true, a framework is for life, not just for Christmas.

    p.s. I'd love to see the NI running on Catalyst, that would be brilliant.

  3. #3 ciderpunx 22 May 09

    Thanks for an interesting post, Phillip.

    I wanted to preface my thoughts by saying a little bit about [a href=’’]Rails. I've used Rails a fair bit. I like working with Rails, but it regularly seems to get in my way. The ORM, ActiveRecord is convienient, once you've got the hang of its rules and [a href=’’]limitations and as long as you don't want to actually do much with your (single, ) database. It makes [a href=’’]writing raw SQL tricky. The templating system, ERb, is nice, but being an undisciplined sort of a chap I had a tendency to put code in there way too often (OK, I can't blame Rails for that!).

    What I'm after in a framework is something that gives me the simplicity of Rails without treading on my toes quite as much. Either Jifty or Catalyst seem to be good candidates, I tested both, and I'm now trying Catalyst on the live NI site. Incidentally, I didn't have the same install problems as Phillip experienced with either framework installing from [a href=’’]FreeBSD ports, or on [a href=’’]Debian Sid with from apt.

    [a href=’’]Jifty is a lovely bit of kit, very slick, very easy to get running on. As Phillip says, Jifty's approach, like Rails is to ’[trade] off options ... for simplicity’. Because its built from the ground up it has a more integrated feel. It did do some things that I don't really approve of. For example, when you define your Model you need to do something like this:

    column body =>
            type is 'text',
            label is 'Content',
            render as 'Textarea';

    It seems wrong to me to have the model know about something that only the view ought to know (how to render the body column).

    Anyhow, on to [a href=’’]Catalyst. I found the Catalyst approach more perl-ish than Jifty's. It glues together a bunch of really nice [a href=’’]CPAN modules rather than being an ’out-of-the-box experience’. Now, I'm all for being out of my box, and for simple projects that may be enough. But all too often today's simple project ends up being tomorrow's critical piece of infrastructure. The thing that sold me on Catalyst was that it didn't impose a box on me. If I want to use a different RDBMS, that's fine; if I want to use Mason rather than Template::Toolkit, that's fine too. I can even use [a href=’’]Jifty's ORM.

    Phillip's observation that ’what Catalyst makes up for in documentation, it lacks in simplicity’ is perhaps true. Though simplicity isn't necessarily the same as intuitiveness. Simplicity can end up requiring lots of workarounds. I'd add a corollary; what Catalyst lacks in simplicity it makes up for in flexibility.

    In the end that's what sold me on trying Catalyst for the NI site. At the moment we're only using it for some fairly trivial forms, like the [a href=’’]letter to the editor, so we don't need much of Catalyst's power or flexibility. But, like having good speakers, it reassures me to know the power's there if I need it.

    On a side note, singingfish mentions the [a href=’’]new book. I look forward to reading that. I have a copy of the [a href=’’]old book which is a bit out of date and has a bunch of errors in the text. I'd recommend sticking to the [a href=’’]docs for now.

    Finally of course we haven't discussed [a href=’’]the ultimate framework. I don't know how anything can compete with that ;-)

  4. #4 phillip_at_newint 25 May 09

    ’what Catalyst lacks in simplicity it makes up for in flexibility.’

    Nicely put, Charlie.

Subscribe to Comments for this articleArticle Comment Feed RSS 2.0

Guidelines: Please be respectful of others when posting your reply.

Get our free fortnightly eNews


Videos from visionOntv’s globalviews channel.

Related articles

Popular tags

All tags

The Tech Blog

This is where New Internationalist Web Team documents the free and open software used to build this website and its services, discusses emerging issues in the technology space, and provide critical analysis, news and commentary on all things IT and web.

The Tech Blog