[dancer-users] Applicability of Dancer and Dancer vs. Dancer2

[Yanick Champoux]

Hi Lutz!

On 14-02-08 11:16 AM, Lutz Gehlen wrote:
> 1) I am trying to decide whether to use Dancer for a small to middle size
> web application. The key advantages that seem to keep coming up when people
> talk about Dancer is simplicity and light weight and that people recommend
> it for small or toy applications. That raises the question if there is a
> price to pay for this simplicity and light weight. So from your point of
> view, are there any important features missing or in general is there any
> reason not to recommend Dancer for serious and/or not-so-small
> applications?

That's a question that indeed resurfaces quite often. We should probably 
add it to the FAQ at some point.

Anyway, here's my slightly rambly take on it (and that's only my 
opinion. I'm curious to see what the other Dancer guys will have to say 
on the same topic):

When we talk about micro-framework and small applications, it's mostly 
referring to the super-low overhead to get going (I mean, it's hard to 
get lower overhead than perl -MDancer -e'get "/" => sub { "hello }; 
dance'), and the fact that Dancer isn't as much a MVC framework, but 
more of a route dispatcher / view one.

So when we talk about being optimized for small applications, it's more 
in term of size of the logic, and not in term of the bandwidth generated 
('cause Dancer is quite darn lithe and fast in its feet).

And the good news is: most applications are "small" in the sense that 
they will do maybe three-four things. For example, a e-commerce website 
will have a few web pages, a store (with the cart system and all that), 
and a rss feed. What I would consider a "big" application is something 
that does webpages, a forum, a bugtracker system, deal with offline 
processing tasks, a complex user privilege system, a timetracking 
subsystem, a REST API and an SMS interface. All of which can't, for some 
reason, be broken into smaller pieces.

In a more bullet-point fashion, I'd say that the circumstances where 
Dancer might not be as natural a choice as, say, Catalyst, would be:

1. The application uses several templating systems.

While you can use more than one templating system, Dancer is geared 
toward the assumption that you'll only have one of those (because, let's 
face it, that's what happens in most of the cases). Catalyst, by 
opposition, can have as many views as you want.

Note: this point is not as strong with Dancer2, which can in theory 
allows different configurations for different pieces of the application. 
So MyApp::StaticPages could have one templating system,
and MyApp::Store have another.

2. The application is a smattering of wildly different components.

Mind you, in those cases I would recommend trying to break the behemoth 
in several, smaller applications working together. But the MVC 
frameworks might be better, off-the-shelf, to deal with the segregation 
of many moving parts.

3. Huge team with very specific specialization for the Model part, View 
part, Controller part.

Again, just for the simple fact that MVC frameworks explicitly enforce 
the distinction between the three areas. Which can also be totally 
achieved with Dancer, don't mistake me. It just requires a little more 
thought.

4. Which plugins will make you happy.

That's a big one. The plugin ecosystem surrounding a framework is a 
vital extension of the framework itself. If your application is going to 
interact with Twitter and send emails, then you should look at what is 
already offered for that problem space, and if they jive with what you 
had in mind.


> 2) The second question I am facing is whether to use Dancer or Dancer2. I
> know that Dancer2 is a OO rewrite of Dancer, but I couldn't figure out how
> the two relate to each other with respect to the devoloping community.
> Intriguingly, the webpage perldancer.org does not seem to mention Dancer2
> at all. More specifically:
> a) Are Dancer and Dancer2 developed by the same people?

Yes. Some of us focus more on one or the other, but it's all the same 
gang. :-)

> b) Is Dancer2 supposed to supersede Dancer?

Eventually.

Dancer2 was actually supposed to be simply Dancer release 2.*, but since 
some design changes made it, for example, extra-hard for plugins to both 
work in the "classic" and "new-OO" codebase, the decision was made to 
give it a different namespace. That way, already-existing applications 
would not be broken, and the new stuff would not have to do painful 
behind-the-scene contortion to ensure total backward-compatibility.

> c) Is Dancer more mature than Dancer2?

Yes. Dancer was the first iteration of the framework. Dancer2 is the 
rewrite, which aims at keeping the same API but with a new engine under 
the hood.

> d) How do the two compare to each other with respect to performance?

That's a good question. They are both very fast, but I don't have 
numbers with me. One of the things I want to do at some point, actually, 
is to come with some performance benchmarks we could run across versions 
and D1/D2. That would be very interesting to see, methinks.

> e) In general, are there any reasons to prefer one over the other except my
> taste for procedure or object orientation?

Unless you plan to write plugins or the such, you should not even see 
any big difference. Because D2 is still a work in progress, it's usually 
prescribed to go with D1 if you want stability, and D2 if you want to 
take advantage of the latest goodies. The good news here is that the 
choice doesn't have to be final: D1 and D2 are very, very, very close 
DSL-wise, so migrating a project from D1 to D2 shouldn't be very hard.


Hope that helps a wee bit,
`/anick