My first reaction to this was that Dancer would be overkill for such a small task. I've been working with Dancer lately and like it a lot, but using a framework for what amounts to a 10-line CGI? But then I reconsidered and tried it. I can't say it saved me any time or lines of code, but it did keep things cleaner and more organized. The rule-based structure of Dancer makes it very easy to see what URI is involved. Keeping the code separate from the HTML makes it easier to write one and then the other, without the back-and-forth in my head that I tend to do when writing CGI with HTML embedded in it (as functions like h1() or as strings), which is nice even for a small task.

And since I already had Dancer running and configured on this site, I could just add the rule and the template, without worrying about the path to the perl executable, or whether my CGI needed to go in the cgi-bin directory or have a particular extension, or any of that other fun stuff that made installing CGI scripts too difficult for most newbies. And if I want to expand on this utility later, to make it more robust by adding more logging and error checking, or perhaps to save the lookups in a database cache, the payoff from using Dancer in the first place will only grow as the complexity of the thing increases.

So I'm sold: Dancer is even good for small stuff. I probably still won't use it when I need to write a one-line script to run a one-time command on a server where I don't have shell access, like `rm annoying_file_owned_by_webserver_that_I_can't_remove_by_FTP`; those will still go in quick CGIs (or PHP). But I think everything else will be done in Dancer if it can be.