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.

Perl Dancer meeting #1 report

Here is my quick report of the first Dancer meeting that took place last thursday in Paris.

  • We started the meeting by demonstrating how Dancer and Plack middlewares can be powerful and easy-to-use. We did a live demo of a scaffolded Dancer app configured to run with Plack::Middleware::Debug. That was neat. Just editing the config file allows you to enable and disable middlewares, you don’t even need to know about Plack::Builder, Dancer does all the black-magick for you. I ended the demo by showing how to get all your logging messages in your Firebug console thanks to Plack::Middleware::ConsoleLogger and Dancer::Logger::PSGI. That was a piece of cake:
    1. $ sudo cpanm Plack::Middleware::ConsoleLogger Dancer::Logger::PSGI
    2. in config.yml :
      logger: "PSGI"
      plack_middlewares:
        - ConsoleLogger:
      
    3. restart the app with plackup

    And that was it. Impressive :)

  • We talked about the implications of supporting mountable Dancer applications inside Dancer’s core, in order to fix the whishlist item #82. We all agree on the fact that this would allow lots of good things (like generic reusable application bricks); but the rewrite needed is massive. We may wait for 1.2 to be released before starting wroking on that.
  • We plan to write three articles for “Linux Magazine France”. The money earned by those articles will be spent in a pro GitHub account. The first article to be written is an introduction to Dancer, the second one should present PSGI/Plack and the third would explain how to use Dancer with Plack middlewares.
  • Franck plans to work on an asynchronous handler so Dancer can be non-blocking. This would allow support for websockets.

Next meeting will probably occur in september as we may be very few in Paris during august.

Perl Dancer meeting #1

As explained on the mailing list, we had the idea to schedule a monthly meeting in Paris for people interested in Dancer’s development (users are welcome as well, of course).

The first meeting takes place this evening, in order not to come with empty hands, I’ll write down here a list of topics I’d like to discuss with the team:

  • “Linux Mag” articles : Franck and I have planed to write a serie of three articles about Dancer and Plack for the french “Linux Magazine”. I already have a first draft of the first article
  • Dancer 1.2 release : discussions about plans, key-feature, and maybe a timeline for the next major release of Dancer.
  • What about the mountable feature ? A recent whishlist item was posted to our issue tracker, the idea is pretty interesting, but implies a major rewrite of Dancer’s internals. Should we open a new branch where Dancer’s core willm be basically rewritten?

    Stay tuned for the report…

Get Adobe Flash playerPlugin by wpburn.com wordpress themes