[cgiapp] Dancer

[Mark Stosberg]

> Thanks for your insight Mark. Very useful.
> 
> I am still using my trusted CGI::App framework, and enhancing it, but
> I am also following Dancer very keenly. Seriously, Dancer is a breath
> of fresh air, part of the new line of apps such as Plack and its ilk,
> Mojolicious::Lite and the kind.
> 
> Alexis Sukrieh, Dancer's creator, has a blog post on his logic for
> abandoning CGI.pm, and I see nothing wrong with it. Frankly, I never
> really did use CGI.pm. I always used CGI::Simple, and then, I never
> really used anything that CGI::Simple provides other than grabbing the
> get and post variables.

Now that I co-maintain CGI.pm, so I've gotten to know it closely. I
agree CGI::Simple is a better implementation of the idea, but it forked
from CGI.pm many years ago, and does not have all the bug fixes that
CGI.pm does. For example, CGI::Simple hasn't yet released an update to
address the CRLF issue, although the maintainer has been notified about
it.

Pragmatically, CGI.pm is stable and reliable with a fairly complete
feature set, and it's compatible with a *lot* of code out there that
expects the CGI.pm interface. Technically, I agree that some new
implementations of the same problem space are cleaner. I've looked
closely at how Mojo handles HTTP requests, and it appears to be well
thought out and generally correct and complete (in terms of the specs,
the Mojo documentation may still have some gaps).

Dancer traded a dependency a core module, CGI.pm, with a non-core
module, HTTP::Body, which in turn depends on LWP (via HTTP::Headers),
which in turn depends on HTML::Parser, which in turn depends on a C
compiler. That aspect is unfortunate. I have started to work with Gisle
to split up LWP a little bit and remove the dependency on HTML::Parser
(and by extension, the C compiler) when it is not needed. He is open to
that idea, but I have not had time to follow through with helping with
the work.

> Here is what I want in a web framework --

I'll offer my impression of how CGI::Application handles these.

> 1. clear and complete documentation

I link to think we do well here.

> 2. easy download and install without tortuous cpan deps nightmare and
> compilation

CGI::Application does well here, but Titanium is still not as easy to
install as I would like. I would like a way to ship the dependencies
with it, and offer Pure Perl options for any modules that require a C
compiler.

> 3. built in webserver that can be changed to Apache/Lighty/FCGI,
> whatever, with minimal lines of code.

Titanium has CGI::Application::Server, and our PSGI support will address
this goal. Other frameworks currently make this easier.

> 4. readymade scaffolding to get started

Titanium documents using cgiapp-starter for this.

> 5. clean URIs (routes) without screwing around with bazillion settings

To make this super-easy, you have to use a built-in Perl web server,
an idea I find increasingly attractive. Otherwise you have copy/paste
a small amount of mod_rewrite code into your Apache config or .htaccess
file. CGI::Application::Dispatch offers the code for easy copy/pasting.

> 6. a couple of popular templating system support
> 
> Both CGI::App and Dancer have that. CGI::App has the maturity and test
> of time, Dancer has the freshness of the new debutante on the dance
> floor.
> 
> Good for all of us.

Yes. I appreciate the alternatives and learn from them. Each has
something different to offer.

    Mark

-- 
http://mark.stosberg.com/