# Mojolicious: a Perl real-time web framework that grows from one file to MVC > Mojolicious bundles an HTTP and WebSocket stack, a non-blocking server and a full MVC framework into one CPAN distribution. It suits teams already writing Perl who need long-running requests without blocking, and it is a poor fit for anyone who wants an ecosystem outside Perl. **mojolicious/mojo** — :sparkles: Mojolicious - Perl real-time web framework - Repository: https://github.com/mojolicious/mojo - Website: https://mojolicious.org - Stars: 2,749 · Forks: 590 - Language: Perl - License: Artistic-2.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/mojolicious-mojo ## What Mojolicious solves, and who it is for Mojolicious is a Perl web framework built by developers who previously worked on Catalyst, according to its README. The stated goal is a framework that starts as a single file and grows into a structured Model-View-Controller application without a rewrite. That growth path is the actual product: the same distribution serves a three-line prototype and a routed application with sessions, form validation, content negotiation and a testing framework. The audience is narrower than the feature list suggests. The README says the API is pure Perl with no requirements besides Perl 5.26.0, with versions as old as 5.16.0 usable if additional CPAN modules are installed. So this is a framework for people who are already in the Perl ecosystem, or who have a reason to be there. If your team writes Go, Python or JavaScript, the framework's advantages do not transfer; you would be adopting a language as well as a library. The real-time claim is the differentiator. The README describes Mojolicious as a real-time web framework allowing WebSockets and long-running requests without blocking. That matters for chat, live dashboards, notifications and anything that holds a connection open. In most stacks that means adding a separate async server; here it is part of the distribution. ## The Mojo stack: one HTTP toolkit under the framework Mojolicious is not only a router and a template engine. The README describes a web development toolkit usable independently of the framework, and this is where the architecture gets interesting. The stack provides a full HTTP and WebSocket client and server implementation with IPv6, TLS, SNI, IDNA, HTTP and SOCKS5 proxy support, UNIX domain sockets, Comet (long polling), Server-Sent Events, Promises/A+, async/await, keep-alive, connection pooling, timeouts, cookies, multipart and gzip compression. The server is non-blocking and built in, with support for multiple event loops plus optional pre-forking and hot deployment. That combination explains why a Mojolicious application can hold thousands of open connections without a separate process manager: the event loop is the same one the client uses, so an application can fetch an upstream URL while serving a request, as the README's WebSocket example does when it extracts a page title. There is also a JSON and HTML/XML parser with CSS selector support. In the README's example, a WebSocket handler fetches a URL with `$c->ua` and then calls `->dom->at('title')->text` on the result. The HTTP client, the parser and the DOM query are all in the same distribution, which is why single-file prototypes stay readable. The trade-off is coupling. Because the toolkit and the framework ship together, you cannot easily swap the HTTP layer for another Perl implementation without leaving the framework's conventions. That is a deliberate choice, and it is why the stack feels consistent but also why it is hard to use piecemeal in an existing PSGI application. ## Installing Mojolicious and running a first route The README gives a one-line install through cpanm and says it takes less than a minute. It also recommends a Perlbrew environment, which keeps the framework and its dependencies out of your system Perl. Run this in a shell: ```bash curl -L https://cpanmin.us | perl - -M https://cpan.metacpan.org -n Mojolicious ``` The command pipes the cpanm bootstrapper into perl, points it at the MetaCPAN mirror and installs Mojolicious without prompting. The README notes that Perl 5.26.0 is the baseline; older Perls from 5.16.0 may work but can require additional CPAN modules. A complete application is three lines. Put this in a file named hello.pl: ```perl use Mojolicious::Lite; get '/' => {text => 'I love Mojolicious!'}; app->start; ``` The `get` call registers a route for the root path and returns plain text, and `app->start` hands control to the framework. To run it with the built-in development server, the README uses morbo: ```bash morbo hello.pl ``` The README shows the output as `Web application available at http://127.0.0.1:3000`, so the development server listens on port 3000 by default. Confirm the route with any HTTP client: ```bash curl http://127.0.0.1:3000/ ``` You should see the text `I love Mojolicious!`. From here the README's growth path applies: the same file can be split into controllers, templates and models as the application expands. The documentation at docs.mojolicious.org covers the guides and reference material. ## Where Mojolicious is the wrong tool The framework's own positioning is honest about the boundary: it is a Perl framework, and the README says the only requirement is Perl 5.26.0. That is a constraint in both directions. If your organisation has no Perl developers, the framework's productivity claims do not apply, because the guides, the reference documentation and the third-party extensions all assume fluency in the language. Hiring for a Mojolicious role is harder than hiring for a mainstream stack. The second limitation is the extension ecosystem. The README points to hundreds of third-party extensions on CPAN and to spin-off projects such as the Minion job queue. That is a real ecosystem, but it is smaller than the ones around Rails, Django or Express, and the README does not document a compatibility policy for extensions across major Mojolicious releases. If your application depends on a plugin that lags behind, you are the one reconciling it. Third, the bundled server is a deliberate simplification that will not suit every deployment. The README mentions optional pre-forking and hot deployment, but it does not document a rollback procedure or a zero-downtime release process. Teams that need those guarantees typically put the application behind a reverse proxy or a process supervisor, and the README does not walk through that arrangement. Treat the built-in server as the development and small-deployment option, and verify the production topology yourself. ## Mojolicious compared with Plack and PSGI stacks The closest comparison in the Perl world is not another framework but the PSGI and Plack layer. The README states that Mojolicious supports CGI and PSGI detection, which means a Mojolicious application can run under an existing PSGI server rather than the built-in one. The difference in approach is where the async machinery lives. In a Plack-based stack, the web framework and the server are separate projects, and real-time features come from whichever event loop or streaming extension you assemble. Mojolicious inverts that: the event loop, the HTTP client, the WebSocket implementation and the framework are one distribution, and PSGI is a compatibility mode rather than the foundation. The benefit is that a WebSocket handler can call an HTTP client on the same loop without extra wiring. The cost is that you adopt the whole stack to get that behaviour, and you inherit its release cadence for the HTTP layer as well as the framework. For a team already running Plack with a stable middleware set, moving to Mojolicious means re-evaluating that middleware. For a new application that needs WebSockets and long polling, the bundled approach removes several integration decisions. That is the honest split: it is a better starting point than a migration target. ## Maintenance, licence and upgrade cost The repository is not archived, and the last push was on 2026-08-09, which is recent enough to call the project maintained. The README also points to CI badges for Linux, macOS and Windows, so changes are exercised on three platforms. There is no published release history to reason about here; the Changes file at the repository root is where that information lives. The licence is Artistic-2.0. That is a permissive licence, and it is the same licence family used across much of CPAN, which matters if you redistribute a modified copy or bundle the framework into a product. This is a description of the licence identifier, not legal advice; check the LICENSE file and your own obligations. Upgrade cost is the open question. The framework ships the HTTP client and server, so a Mojolicious upgrade can change behaviour in code you did not write, not just in your routes. The README says the API is pure Perl with no hidden magic, and the distribution includes a testing framework, which helps: you can pin behaviour with tests before upgrading. What the README does not document is a deprecation policy or a support window for older releases. If you are running a version that predates your Perl's baseline, that is the first thing to establish. ## Conclusion Adopt Mojolicious if your team already writes Perl and you need WebSockets, long polling or SSE without an external application server: the built-in non-blocking server handles those cases directly. Do not adopt it as a first web framework if your team has no Perl experience, because the guides and reference documentation assume the language. Before committing, verify the CPAN install path works on your target Perl, confirm the version of Perl you have meets the 5.26.0 baseline, and check whether the third-party extensions you depend on are still published. ## FAQ ### How do I install Mojolicious? The README gives a one-line install through cpanm: pipe the bootstrapper into perl, point it at the MetaCPAN mirror and install Mojolicious. It recommends a Perlbrew environment, and the minimum supported Perl is 5.26.0, though versions as old as 5.16.0 can be used with additional CPAN modules. ### What is Mojolicious used for? It is a Perl real-time web framework for building cloud-native web applications, with RESTful routes, plugins, templates, session management, form validation and a testing framework. The README also describes a web development toolkit with a full HTTP and WebSocket client and server, usable independently of the framework. ### Does Mojolicious support WebSockets? Yes. The README describes Mojolicious as a real-time web framework that allows WebSockets and long-running requests without blocking, and its example application defines a websocket route that reads messages and replies with the title of a fetched page. ### What Perl version does Mojolicious require? The README states there are no requirements besides Perl 5.26.0, and that versions as old as 5.16.0 can be used too but may require additional CPAN modules to be installed. ## Sources - [Issues](https://github.com/mojolicious/mojo/issues) - [License: Artistic-2.0](https://github.com/mojolicious/mojo/blob/main/LICENSE) - [mojolicious/mojo on GitHub](https://github.com/mojolicious/mojo) - [Project website](https://mojolicious.org) - [README](https://github.com/mojolicious/mojo/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mojolicious-mojo