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

On Sat, 8 Feb 2014 17:16:38 +0100 Lutz Gehlen <lrg_ml@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 logo syndrome).

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 interactions. 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 course). Cheers Dave P -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github