Dancer, global thoughts about our philosophy

If you follow Perl5 blogs you may have been aware that Dancer was put under the spotlight recently (even if that spotlight was meant to be showing the weak points of Dancer, it was still an enlightenment).

I’m going to use that event as an opportunity to give my point of view on Dancer, this entry will be a reference for exposing the philosophy of the project.

1. Is Dancer a port of Sinatra ?

No. It clearly isn’t. It’s written quite everywhere in the documentation that Dancer was inspired by Sinatra. But the project clearly took its own path.

Don’t expect Dancer to be a Perl 5 clone of Sinatra, it isn’t and will never be. Dancer is a micro-framework, based on the concept introduced by Sinatra. But it provides features of its own, may do things differently and address other issues than Sinatra.

That being said, Sinatra has been a huge source of inspiration.

2. How is Dancer being developed?

Dancer quickly attracted lots of users. Lots of feedback received mentioned “a feeling a fresh air thrown in Perl5″ and we are very glad to see such support from our users. We give a lot of attention to users, we take every suggestion seriously and most of the time, a feature is added because the community itself agreed on the concept.

Dancer is clearly community-driven. As the project-leader, I make decisions when there is some kind of hesitation, but as long as an idea makes sense, I don’t see why I should refuse it.

Dancer is a young project: it’s going to be one year old in august, so we’re aware the code isn’t perfect. That’s why most of our energy is spent in refactoring and bug-fixing. The only priority for me is to release Dancer 1.2 which should be a rock-solid release.

Our code base is very well tested (we have near 1k tests, about 90% of code-coverage).

We are very pleased with the feature-set, our users don’t stop telling us they’re very happy with Dancer, and actually enjoy working with it. This is the best thing that can happen when you do free software: seeing that your work is enjoyed by others).
So, our priority is to make the whole thing robust and well-designed.

Once we have something like that, Dancer 1.2 will be out. And the beer will flow all the night. Yay.

3. How are planned the new features?

One of the attacks was about the fact we stole features from another framework, so I understand people can start thinking this is true.

Of course it’s not. And if it was, I would undestand that as a greeting to the related framework, anyways.

As I said in the section above, we plan our development mostly according to our user requests. Almost all of the issues reported on our tracker originate from our community.

Of course, when a good thing happens somewhere, we may start paying attention to it, like websockets. Some of our users asked for websocket support and we started investigating. I now understand it may look like we started stealing code (what does “stealing” mean if the code is public anyways?) but we’re not, we’re following our users, as we always did.

4. What’s Dancer philosophy regarding other Perl 5 frameworks?

We are definitely Perl lovers. That means we truly think that there is more than one way to do it. Dancer is one way to go. If you don’t choose that way, that’s perfectly understandable, maybe it lacks a feature you have in another framework, maybe you don’t like Dancer’s syntax, whatever the reason, we understand we can’t be the only way to go.

But we know, on the other hand, that Dancer addresses one way to do web development, and it clearly looks like lots of people like that way.

We think that having many frameworks out there is a good thing for Perl 5, and a sign of vitality of the language. We want nothing more than a peaceful cohabition between Perl 5 frameworks. That’s why we don’t think that attacking another framework is a smart thing to do, we don’t see why we should be aggressive if we’re pleased with our project.

We do think that friendly competition is better and let good ideas flow between different implementations.

Let me end this article with Tolkien, in a poetic way:

Three Frameworks for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.

One Language to rule them all, One CPAN to find them,
One PSGI to bring them all and in Plack bind them

Don’t forget, enjoy your code. Whatever happens.