The first time I took a look at Mojolicious was almost a year ago if I’m not mistaken. My Perl was really rusty back then and the Mojolicious’ documentation, or rather the lack of it, didn’t help much either. Still, with interest I followed the project through GitHub. Development on the project, and especially the last few months has been very active. The author, Sebastian Riedel, seems very devoted to the project and his productivity is very inspiring.
By now Mojolicious has matured a lot in my eyes. Documentation is a lot better than it was and is still being improved. To my understanding he’s nearing a feature freeze which means a proper stable 1.0 version will be out soon. This also means for me that I can start using Mojolicious without the agony of backwards incompatibility with every small update.
What I like about Mojolicious is that its pretty lightweight, has no dependencies besides core modules and is already supporting HTML5 features like Websockets. Now, I don’t know yet precisely what Websockets are good for (the Wikipedia entry isn’t very helpful either), but it shows that Mojolicious is geared toward support for modern techniques. To my understanding it allows for the browser to keep a connection open with the webapplication so you don’t need a polling system to retrieve updates. Which is something Ajax is being abused for at the moment.
Because Mojolicious doesn’t use any other modules it has its own templating system as well. It’s pretty feature complete, but I can’t coop with the syntax. Others have blogged about this as well. Templates look horrible and are unreadable. Which is a shame. A more Template-Toolkit like syntax would’ve been nicer. But that would also mean reinventing the wheel, again. Which is what Mojolicious is doing quite a bit (e.g. Mojo::JSON). Nothing wrong with that though, as on of the key points for Mojolicious is to be independent of other modules, except for core modules.
Luckily, it’s easy enough to replace the default renderer with another one. MojoX::Renderer::TT nicely wraps up Template-Toolkit. Inside the startup method of your application it’s easy enough to set it up as the default renderer.
One tiny thing I’m missing, and maybe I’ve overlooked it, is a standard way of using configuration files. I’m used to the Catalyst way of doing this, which is a breeze, but so far haven’t found a standard way to do this in Mojolicious. I suppose I can easily fix this with using Config::Any myself.
So far my hands-on with Mojolicious has been small, but it did the job for me. All I needed was a simple web application that can log usage through a REST API. Together with Test::Mojo writing tests was a breeze. I did have to go through the documentation quite a bit to figure out where and what everything was. But this is no different with any other framework you’re learning. Whilst testing I had run into a tiny problem which turned out to be my fault, not Mojolicious’. Still, Sebastian was kind enough to promptly respond to my question at IRC and was very helpful.
I didn’t use Mojolicious::Lite by the way. Whilst it would’ve worked perfectly for my use case I don’t understand yet how it’s easy to convert a Mojolicious::Lite webapplication to a normal structured Mojolicious webapplication. It would’ve made implementing the REST API easier since Mojolicious::Lite has routines for setting up PUT, POST, GET, DELETE and HEAD requests. But since the webapplication will scale to something bigger in the future I don’t want to rewrite the Lite edition to a structured version. I don’t have time for that.
Compared to my experience from a year ago it was fun to use Mojolicious this time. I’m certainly going to use it for more small and low traffic webapplications. For now I’ll stick with Catalyst for the big webapplications. But that’s because there are already a lot of extra modules for it, has excellent documentation, it’s highly configurable and I bought an expensive Catalyst book (don’t worry, I like it and ordered it through the Catalyst website so the Enlightened Perl Organisation gets a donation).
It is actually very easy to convert your Mojolicious::Lite app into a structured Mojolicious one. You can even mix them together so the transition is gradual (if at all). From the Mojolicious::Lite documentation:
——8render(text => ‘It works!’) }
package main;
use Mojolicious::Lite;
get ‘/bar’ => sub { shift->render(text => ‘This too!’) };
app->routes->namespace(‘MyApp’);
app->routes->route(‘/foo/:action’)->via(‘get’)->to(‘foo#index’);
app->start;
——>8——
A special guide covering just that will soon be available as Mojolicious::Guides::Growing, so stay tuned! Also, everyone’s invited to join the party and get involved, or even just have their questions answered over at #mojo in irc.perl.org, or via the mailing list http://groups.google.com/group/mojolicious.
As for a standard way of using configuration files, Mojolicious::Plugin::JsonConfig comes bundled, and can take advantage of Mojo::Home to load specific files at your request.
Have fun!
Sigh, the code came out bogus on the comment. Here’s another attempt:
In case a lite app needs to grow, lite and real Mojolicous applications can be easily mixed to make the transition process very smooth.
package MyApp::Foo;
use base ‘Mojolicious::Controller’;
sub index { shift->render(text => ‘It works!’) }
package main;
use Mojolicious::Lite;
get ‘/bar’ => sub { shift->render(text => ‘This too!’) };
app->routes->namespace(‘MyApp’);
app->routes->route(‘/foo/:action’)->via(‘get’)->to(‘foo#index’);
app->start;
Can’t believe I missed Mojolicious::Plugin::JsonConfig. Thanks for the pointer.
So basically you plug the app into the lite app? I was thinking the other way around actually.