Here’s my take on Mojo 0.8.7, a new web framework for Perl.
The primary author of Mojo, Sebastian Riedel was once as a primary contributor to Catalyst. There are clearly some similarities, and it’s easy for me to see Mojo as an evolution of Catalyst.
One major difference with Catalyst sparked my interest in Mojo. Catalyst now depends on Moose among other things, with a very long overall dependency change. How long? I downloaded Catalyst 5.8 along with all of it’s non-core Perl module dependencies. The result was over 250 modules, not counting the Catalyst modules themselves, or anything in the Test::* name space. Bleh.
What to see for yourself? Get my “self-contained” patch out of the local::lib tracker and run the following. It will install Catalyst and all it non-core dependencies into a “Catalyst” folder. Be aware, this could take half an hour or more… (The TinyURL points to a Catalyst 5.8 tarball)
perl -MCPAN -Mlocal::lib=--self-contained,Catalyst \ -e 'install "http://tinyurl.com/5hbzoo"'
Leaning on dependencies can be a great thing. It works well when you are able to outsource part of your needs to an external module that is already well written, documentation and tested. I’m sure there’s some of that happening in the Catalyst dependency chain. But there’s also a good deal of duplication, as different authors solve things different ways. For example: Exporter.pm, Sub::Exporter and Moose::Exporter all serve the same function, and are dependencies somewhere along the way. Class::Accessor::Fast competes with MooseX::Emulate::Class::Accessor::Fast. And this is where a long dependency chain can start to look and feel like bloat, and it can be difficult to overcome if the owners of the dependencies don’t share the projects preferences about how to export subroutines or build accessors.
It could perhaps be said though that Mojo suffers from re-using too little. Mojo::Base is yet-another accessor-generation solution, like Class::Accessor.
The potential I see in Mojo is the summed up in the following:
- No dependency chain, for less complexity and easy deployment
- Built-in support for several backends, for portability
- A rewrite of HTTP request and response objects, as a sanely designed evolution of what CGI.pm has been used for
- No ties to a specific framework design beneath the server/response-request object layer, for flexibility and potential code sharing between frameworks based on it.
It is this last item that has allowed me to ignore the bundled Mojolicious framework for this review– It’s not required for use with Mojo and could use it’s own review.
Overall, I feel positive about the Mojo project, although I have no current plans to quit developing with Titanium-style projects myself. In theory, they could be used together. Mojo could provide the backend-server support and query object, and CGI::Application could run inside the Mojo handler() in much the same way CGI::Application apps can run in a mod_perl handler. Now, CGI::Application can already run under various servers and with different query objects, so whether or not you’d actually want to use CGI::Application with Mojo is left up to the reader.
I don’t recommend using Mojo yet– it needs more documentation and tests for my taste. It’s Mojo’s clean, scalable and extensible design that make it a project worth following. I’ll be keeping my eye on Mojo.
This post is being discussed on reddit.com