As we say in French, Jamais deux sans trois, so for the third time on this blog, I’ll speak a little about Dancer2.
As explained earlier on this blog, we’ve decided to release Dancer2 under its own distribution, and at the same time, we decided to give Dancer a new maintainer (or should I use the Pumpkin term?)
Actually it’s not one, but two maintainers that now take care of Dancer releases: Yanick and Alberto! I’m glad to see that it took less than 4 days for a new release of Dancer to hit CPAN: Dancer 1.311!
Also, the last Dancer2 distribution (version 0.02) should be available on your favorite CPAN mirror.
I’ll also try to answer the most frequently asked questions since we released Dancer and Dancer2.
Should I upgrade my Dancer application to Dancer2?
If you’re happy with Dancer, and use many plugins/engines, then there is no reason to switch at this point in time. Don’t change something that fits your needs. That’s one of the rationale behind the release “split”.
You have the choice to upgrade, or not. It’s up to you. If you use many plugins/engines in your app, then it’s even a bit early for considering an upgrade.
So no reason to hurry the upgrade.
I’m going to write a new application, which Dancer should I use?
I’d really suggest to start right away with Dancer2. You’ll probably need a plugin or two that are missing, but our team is very active on porting all the ecosystem to Dancer2 (you can already see the first ports on metacpan).
Starting with Dancer2 will give more horsepower to your app, at the end of the day. Oh, and if you plan to use sessions, don’t even think about it, use Dancer2, it’s way better there!
Is Dancer2 production-ready?
It definitely is! We use it for a commercial product at Weborama, and it works like a charm. The app is powered by a couple of Starman servers and works as expected (using sessions, Redis, emails, and templates).
So yes, what you can use in Dancer2 is production ready. The real question is more the one about the ecosystem.
What are the benefits of switching to Dancer2?
No more app collisions, the power of Moo, less code in the framework (the footprint should be lighter), the performances are better and also, you have a strong OO API behind the scene if you need to dig behind the DSL.