Re: Constructive thoughts on Dancer2 v Mojolicious

[perlfan]

It's dealer choice and YMMV, etc. But I will point out that the "hello world" of Dancer2:

#!/usr/bin/env perl
 
use Dancer2;
 
get '/hello/:name' => sub {
    return "Why, hello there " . route_parameters->get('name');
};
 
dance;

and that of that of mojo are equally dead simple:

#!/usr/bin/env perl

use Mojolicious::Lite;

get '/' => {text => 'I <3 Mojolicious!'};

app->start;

Was moving from CGI::Application/::Dispatch (and there from CGI), I tried Dancer2 first and stopped there. I just needed something and it fit the bill. I do like that the route handler in Dancer2 is a subref rather than a hash ref, now looking more closely at the two. What did Dancer2 give me that I wanted so badly? Simple access to routing. As you can see, had I looked at Mojo first I may very well have chosen that.

Why did I choose CGI::Application over CGI? Because it was not overcomplicated and ridiculous like some of the other frameworks I had to choose from when I was looking. It was also extensible. But it didn't have routes (yes I used CGI::Application::Dispatch for a while happily), and when I learned what routes were, I knew that was the way to go.

Besides routes, it provided a simple introduction to PSGI. And I really liked the idea of never having to configure httpd again. This meant, control over where, when, and how I deployed the application. Both Dancer2 and Mojo provide this. Mojo does seem more suited for very precised composition of your application. If I needed all of that, I might (and may very well) give it a shot.

Here's my advice: no matter what framework you choose between the two, it'll be way better than what our options were in the first part of this century; the trick is to maintain clean separation between your business logic and controllers so that you can easily switch from Dancer2 to Mojo or vice versa (or the next leap in framework evolution) without much effort. By effort, I mean you should not have much if any framework specific bits buried in what you would classify as the essence of your application. This included: templates and other assets, business logic, authentication, database access, and all the stuff you do with it.