The Exception That Rather Proves the Rule

I had really wanted to stay out of the recent commentary on CGI. I really did. I was going to be able to until a recent article was published in which the authors try to step in on the side of CGI. I believe the authors to be talented perl developers posting in good faith, but the result really pushed me to reply. The application developed as a case for CGI and preventing “overkill” is a perfect example of why a framework is needed.

The Plack App

First of all, although the authors initially signify that they feel that frameworks are overkill, they do in fact quite quickly reach for one. Plack is the reference implementation of a micro framework build on the PSGI standard. It isn’t the lack of a framework, it is the lack of a full framework, by design. So while the authors seem to be saying is bad (at least we agree on that!) and CGI the protocol is good they neither use the protocol directly nor avoid using a framework by say using PSGI directly.

Next they proceed to develop their application, leaving hooks all over the place for testing (and yes testing is good) but the result is almost a new micro framework on top of a micro framework (Plack). Classes for configuration, templates in configuration so they can be overloaded for easier testing, a home rolled logger. BTW they are only classes in that they provide methods, but notice that all of them are class methods, you don’t instantiate this. The result is surprisingly hard to read for such a small app and one that is intended to convey the simplicity of small when small is all that is needed.

Then we get to the footnote. The authors quite quickly noticed that their home rolled framework doesn’t handle utf8 parameters correctly. They had to add more code to properly handle it.

In looking at their code, I also noticed that because they don’t handle exceptions, their own exception thrown if the response isn’t a JSON object would result in no response being sent to the client. A simple oversight I’m sure. They also don’t seem to have a landing page with the form, which likely means that it is in a static directory that they didn’t bundle, but it means that I don’t see it and it has no tests.

A Mojolicious Alternative

Now I’m on the Mojolicious core team, so I think its probably no surprise that in working out a response I reached for Mojo. I even made a Lite app rather than compare apples to apples and make a fully OO “full app” because once you strip out most of their “framework”, you really don’t need it. That said I believe that most of what I’ll write following this could be applied to any modern framework like Dancer(2) or Web::Simple or what have you.

I didn’t time it, but given the lightness of dependencies, I highly suspect that Mojo installs more quickly than did the dependencies of the presented application. Dancer probably is comparable to the presented application. Catalyst … well, ok, Plack is probably better at that consideration. Mojolicious apps can natively run as CGI. PSGI apps like Dancer can be deployed as CGI as well. So for all the fuss over ease of deployment, I don’t see much benefit for the presented application over alternatives.

Anyway, my alternative implementation is on my Github at Given the head start of cribbing from their app and owing to a lot of experience I was able to write this replacement and tests in about an hour. Without that it probably wouldn’t have been too much more than that amount of time plus the time to figure out how to interact with slack.

The biggest feeling I have looking at the result is how much easier it is to read. There’s a logger and a user agent available. Exceptions are handled natively (I just replaced the default template) as is UTF-8, JSON and rendering a response with headers appropriate to the response type.

One thing Mojo does give me over other frameworks is a testing framework and especially the ability to inject a mock service to replace slack. It lets me use CSS selectors to test the rendered responses, even the initial form. Note that you can use Test::Mojo and/or Mojo::UserAgent in your non-Mojo applications too if you’d like.


Again I want to stress that I’m not trying to attack the authors of this article. In fact I applaud them for showing code that they use and sticking up for technologies that they believe in. That said I think this article, rather than making the case they intend in fact makes the opposite case. Even when you want to do something small and build a webapp that will be used infrequently, an application written in a proper framework is still the way to go.



How much of a role does Plack play in that app? It parses the request parameters. That’s it. That’s the entirety of the reason that their codebase doesn’t qualify as raw PSGI. They don’t even use Plack::Response (I often don’t either).

I think that example reflects on Plack about as much as it relies on it. The fact that it’s overcomplicated has nothing to do with Plack.

For that matter, Plack is not a framework, micro or not – unless the term “framework” is meaningless anyway. To me, something is a framework if it owns the control flow and you write code to slot things into that. I don’t know any other coherent definition of what makes something a framework. That one accurately describes Mojo, Dancer and Catalyst. It does not whatsoever describe Plack. It doesn’t describe the code of the app in question either.

Do I have to be bothered to rewrite your example to use just Plack::Request in order to prove that the reason for how much better it is isn’t Mojo? Or can we take just that as a given, now that I’ve said so, and spare me the exercise?

Ultimately… “Mojo core developer bangs out example that uses Mojo well to good effect” is not an earth-shattering takeaway, nor is “Mojo core developer finds code that makes good use of Mojo super-easy to read”, no? 😊

If you have some argument for why the presented code is preferable to other frameworks, I’m all ears.

It’s the one you won’t want to hear.

I have some Plack CGI scripts on a machine where I do not have root, served by an Apache I do not control, run by the system perl, using only OS vendor packages for Perl modules. The machine has had regular security and system updates since… (almost) none of which I’ve ever noticed, despite my scripts being hit regularly by cronjobs from my end. (The ones I noticed were for reasons unrelated to the CGI scripts.)

I’ve never touched the scripts again since I wrote them… back in the days of Mojolicious 2.x.

I will concede the fact that Plack is an unfortunately heavy dependency to install. 😕 This is in no small part due to the disease of configure-time dependencies that has gripped CPAN in recent years. That was better once.

If you absolutely cannot maintain your scripts (ie want them to live forever unmaintained)

It’s not that I can. It goes back to the question you posed: “what does [maintaining such a script to keep it running] gain for the user?” My scripts have served my needs with no changes whatsoever. What would I have gained from maintaining them?

You can mitigate this by ensuring that your dependencies don’t move

But I haven’t had to. What would I have gained from it relative to the situation as it has been?

Also, is “just run ancient versions of everything” a great answer to “upgrading stuff requires a ton of make-work”?

Leave a comment

About Joel Berger

user-pic As I delve into the deeper Perl magic I like to share what I can.