Dancer2 is a Perl web framework built on Moo and built to be fatpacked

The whole hello world is three lines

Dancer2 describes itself as a lightweight yet powerful web application framework written in Perl, and the example the documentation leads with is three lines long.

    use Dancer2;
    get '/' => sub { "Hello World" };
    dance;

That is the shape of the framework in miniature. You import Dancer2, you declare a route with the get keyword and a path, and you call dance to start the server and serve the routes you declared. The route handler is a plain Perl sub, so the request handling is ordinary code rather than a separate vocabulary.

The interesting part is the comparison the documentation draws. Dancer2 is the evolution of Dancer, and it is based on Moo, which it describes as a lightweight object framework for Perl. That is a deliberate architectural choice: Moo gives you roles and accessors without the compile time and the memory cost of the older object systems, so a framework built on it stays small.

The user is a Perl developer who wants a small web framework rather than a large one, and who values being able to read the whole thing rather than learning an ecosystem.

The homepage is perldancer.org, and the documentation is a mix of MetaCPAN pages, a GitHub wiki, a mailing list and an IRC channel on irc.perl.org.

Fatpacking is the constraint that shaped the design

Dancer2 can optionally use XS modules for speed, but at its core it remains fatpackable through App::FatPacker, and the documentation explains why that matters in plain terms: it lets you deploy Dancer2 applications in environments that do not support custom installations of CPAN modules.

That is a real constraint, not a hypothetical one. Shared hosting in particular is often limited to what the operator has already installed, or to a CGI-style deployment where each request is a fresh process. A framework that can be collapsed into a single file and dropped onto such a host works there, while a framework with a long dependency tree does not.

The design consequence is visible in the choice of Moo, in the optional rather than mandatory XS acceleration, and in the general aim of keeping the core small. It also explains why the project ships a quick start guide alongside the tutorial, since bootstrapping an application in a restricted environment involves decisions that the larger frameworks never have to make.

For an operations team, the fatpacked artefact is also easier to reason about than a tree of installed distributions: one file, one version, one thing to deploy. The cost is that the fatpacked file is generated, and the project documentation does not describe in detail how to keep that generated artefact in step with your application, so that part is yours to design.

A DSL with a keyword guide, and configuration that needs reading

Two pieces of the documentation matter most for someone writing a real application rather than the hello world.

The first is the keyword guide, which the documentation says documents the entire Dancer2 DSL. Route declaration is only the visible part of that DSL, and a framework whose whole interface is keywords needs a complete list of them somewhere.

The second is the configuration guide, which is described as a complete reference to all configuration options. The documentation frames it as being for when you need to fine tune your application, which is the right framing: defaults get you started, but a deployment behind a reverse proxy, with a specific serializer, or with different error handling behaviour is configured, not defaulted.

Around those two sit the practical manuals. The Quick Start is for installing Dancer2 and bootstrapping a new application, the Dancer2::Manual is the comprehensive guide to the framework, the deployment manual covers getting an application onto a real world host, and the cookbook holds recipes for common tasks.

The documentation index also includes a migration guide for people starting from Dancer 1, which is a fair indication of how much of the original Dancer's surface changed. If you have written Dancer 1 code, that guide is the first thing to read, because the DSL, the configuration and the plugin model all changed with the rewrite.

Plugins are separate distributions you choose deliberately

Dancer2 does not bundle a large set of features. The documentation handles that with a plugin guide, which it describes as a curated list of recommended plugins, and a separate plugin author's guide for the case where you want to write one.

So the model is the opposite of a framework that ships everything. Authentication, templating beyond the basics, sessions, serialisation, background jobs and anything else you need are separate CPAN distributions, and choosing between them is a decision you make rather than a set of defaults you inherit.

That has a clear upside and a clear cost. The upside is that your application depends only on what you actually use, which matters for the fatpackable deployment the project cares about. The cost is that the shape of a Dancer2 application is partly determined by which plugins you pick, so two Dancer2 applications can look quite different from each other.

The deprecation policy is a related piece of the documentation and it is unusual to see documented at this level. It defines the process for removing old, broken, unused or outdated code from the codebase, and the documentation says the policy is critical for guiding and shaping future development. For a framework with a long history and a migration path from Dancer 1, knowing how old interfaces get retired is genuinely useful, and it is the sort of thing that is usually left implicit.

Contributing, testing and the shape of the repository

The repository root describes how the project is built and maintained. There is a dist.ini, which is the Dist::Zilla configuration that produces the CPAN distribution, and a cpanfile listing the dependencies. The Changes file holds the release history, and Releasing-Dancer2.md documents the release process in a file of its own, which tells you that cutting a release is a documented procedure rather than a maintainer ritual.

The test layout is split. There is a t/ directory for the test suite and an xt/ directory, which is the conventional place for author tests that are run at release time rather than on every build. There are also tools/ and script/ directories, a share/ directory for template files, an examples/ directory with a single entry, examples/single/, and a .perltidyrc configuration for code formatting.

The continuous integration files are old fashioned in a way that shows the project's age: an .appveyor.yml for Windows builds and a .travis.yml. The contribution guidelines are described as covering how to set up a development environment, the Git workflow, submission guidelines and coding standards, and there is a separate Code of Conduct file.

The last push was on 2026-10-19 and the repository is not archived, though the project publishes no GitHub releases, so versions are tracked on CPAN rather than through tags.

Security reports have a named address, and the community has a policy

A web framework holds credentials, sessions and user input, so the way it handles security reports matters as much as its features.

The documentation gives a specific route: to report a security vulnerability in Dancer2, send all pertinent information to [email protected], or report it via the GitHub security tool. The documentation says these reports will be addressed in the earliest possible timeframe.

A dedicated security address rather than the general issue tracker is the right shape, since a public issue about a vulnerability is a disclosure. Having both a mail address and the GitHub advisory flow gives a reporter a choice of how to reach the team.

The community side is documented just as explicitly. There is a core and community policy and standards of conduct that defines what constitutes acceptable behaviour, what is considered abusive, and what steps will be taken to remediate it, and participation in any public forum for Dancer or its community is agreeing to those terms. That document is available as Dancer2::Policy.

The support channels are the same ones the project has used for years: the dancer-users mailing list on preshweb.co.uk, which the documentation says you are welcome to join, and the #dancer channel on irc.perl.org.

Editorial conclusion

Dancer2 fits a Perl team that wants a compact web framework with a routing DSL, a configuration system that can be tuned per deployment, and the option of shipping a single fatpacked file to a host that does not allow CPAN installs. It does not fit a project that wants a batteries included framework with a large bundled plugin set, since plugins are separate distributions you choose yourself, and it does not fit a team unwilling to read the configuration guide, because the defaults are a starting point rather than a finished deployment. Before adopting it, read the configuration reference and the deployment manual for your target host, check the plugin guide for the pieces you would otherwise write yourself, and plan for the Perl runtime and web server the host actually provides, since Dancer2 is the application layer and not the server.

Frequently asked questions

Official sources

1. Issues
2. PerlDancer/Dancer2 on GitHub
3. Project website
4. README