[dancer-users] Applicability of Dancer and Dancer vs. Dancer2
davidp at preshweb.co.uk
Sat Feb 8 18:55:06 GMT 2014
On Sat, 8 Feb 2014 17:16:38 +0100
Lutz Gehlen <lrg_ml at gmx.net> 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?
Dancer provides the core functionality you need to develop web apps,
without getting in your way or forcing you to do things a specific
way. I find that flexibility invaluable. You can then use whatever
extra tools you require in your application. There's no reason a
Dancer app can only be simple.
At $work, we have an API application which consists of hundreds of
different routes and over 503,000 lines of code (although around
100,000 of that is test code), using DBIC, Moose, and various other
CPAN modules as building blocks. Dancer has never held us back - in
fact, it's allowed us to develop stuff our way, and Just Works.
> 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, primarily. Some new contributors are working on Dancer2 than were
around in the earlier days of Dancer1, and a couple of the core devs who
were working on Dancer1 are struggling to do much on Dancer2 due to time
constraints - I personally haven't had a chance to do much on D2, as
life and work keep getting in the way, but did much more on D1 - but
yes, same core gang.
> b) Is Dancer2 supposed to supersede Dancer?
Eventually; D1 isn't going away any time yet, though, but is considered
more in "maintenance"; it's not really getting any new features
(although you could argue that's equally because it now has all the
important features you'd need, and adding more would just be flaming
> c) Is Dancer more mature than Dancer2?
I would say yes; D2 is coming along well, though, and I know people are
already using it in production.
> d) How do the two compare to each other with respect to performance?
Interesting question; I don't know the answer to that one, but with any
"is $x faster than $y", a lot of the answer will depend on what in
particular you're doing with it. Best worked out by benchmarking
against your specific type of usage.
> e) In general, are there any reasons to prefer one over the other
> except my taste for procedure or object orientation?
D2's internal design is better - OO everywhere as you say, no global
singletons etc, and will work much better if you're trying to run
multiple Dancer apps within a single process without unwanted
D1, however, despite its design not being as nice, is very stable,
well-supported, has a wider range of plugins to make things Just Work
in a short amount of time.
Because D2 is API-compatible with D1, if you started with Dancer2 and
saw problems, or wanted to use plugins which aren't yet available for
D2, you could switch over to D1 pretty easily (or vice-versa, of
David Precious ("bigpresh") <davidp at preshweb.co.uk>
More information about the dancer-users