Ovid posted an interesting article about why one Perler (not himself) dislikes Mojolicious.
I have read several articles, and had several conversations about why people don’t like Mojolicious. I have been meaning to write an article about people’s dislike for Mojolicious for a while now, so I’m going to take this opportinity do so while responding to that article.
Mojolicious is Pro-CPAN
Some people don’t like it claiming that it is “anti-CPAN” and in fact this comes in two flavors. First, they believe that because a tool is available from CPAN that it should be used rather than reimplemented. Second, if one really can reimplement it better, this tool should be forked out of the project and uploaded to CPAN for everyone’s benefit.
While of course this first claim is a concern, it does seem that the Mojo devs take the task of reimplementing these tools very seriously. To the second point, I have seen this question asked at this year’s YAPC::NA and the response is, just install the whole Mojolicious package. At first you might think, “why should I install a whole web framework just to get that DOM parser?” Well, because its not that big of a framework. The Mojo devs feel that it would be a bigger maintenence burden to maintain all the modules separately then just keeping it one toolkit. I was skeptical too, its true, but it installs on my netbook in about a minute. With better hardware and parallel testing it installs on better machines in seconds!
One further argument down this line is that Mojolicious insists on using its tools internally. The person who made this argument wanted to replace Mojo::JSON with their own JSON module even while being used inside Mojolicious (both for logging and the speed of XS). They would prefer that the internal JSON engine be configurable to allow for such. While I can see this point, I also think that its the perrogative of the developer to use their own tools for internal use, that’s why they developed them after all. And hey, this is Perl, if you really want to override Mojo::JSON and replace it with your own, you can do it, there are no protected classes in Perl after all.
In fact you can use your own templating engine, you can use Plack middleware, you can serve via plackup or starman, it’s database agnostic. It uses several optional CPAN modules if you have them installed. This hardly seems anti-CPAN to me. Perhaps a different flavor of CPAN, but try it, its tasty.
The Developers are Really Friendly!
Edit: After several comment have been posted, I have decided to remove my history of the developer Sebastien Riedel’s departure from the Catalyst project as I am not really qualified to write it. My understanding of the situation came primarily from reading this mailinglist entry, which seems civil enough.
Personally I have interacted with him on occasion. In my experience, the IRC channel is friendly. I have submitted patches, and yes, he and the other devs are very particular about what is included, but again, that is their perrogative. I haven’t been the subject of any meanness at all, and several of my patches have been accepted.
Back to Ovid’s Article
The reason presented in this article is a new one to me. This developer doesn’t like Mojolicious ostensibly because it allows companies to shy away from using CPAN. The company can use Mojolicious as the backbone of a webapp, but invent everything else in house.
While this is certainly an interesting realization, I would take a totally different result from it. If there are these tremendously CPAN averse companies out there, and if Mojolicious did not exist, do you really think that they would instead reach for Catalyst? I don’t think they would.
It sounds to me (and I could easily be wrong) that Ovid’s anonymous source is one of those people who are against Mojolicious for being “anti-CPAN”, and thus when they see this happen they think that Mojolicious encourages an anti-CPAN trend. I would say the opposite. Mojolicious is for these companies what the shallow end of the pool is for a young swimmer; dip a toe into CPAN and see that it feels good without fear of drowning.
Or perhaps Mojolicious is that gateway drug, the one that might bring them to CPAN. “Oh its just a little framework. You know an ORM would be nice. Well handling dates is harder than we thought, is there some CPAN-drug for that?”
Final thoughts
I’m not sure where it came from or why it started, but I see lots of people who are opposed to Mojolicious. Are there really people who hate a framework? We all love CPAN, but Mojolicious isn’t anti-CPAN, it adds to CPAN! Catalyst is great, but Mojolicious isn’t trying to kill it (or Dancer for that matter), certainly we can have more than one framework on CPAN. Go ahead use Mojo::DOM in your Dancer project! Or use JSON.pm in your side of a Mojolicious project. Someone might look at Test::Mojo (or at least its underlying Mojo::UserAgent) to test their webapp, whichever framework you use.
At times it seems almost prejudicial. There seems to be a lot of “I hate it and I won’t try it” or even worse, steering others away from Mojolicious because you have heard one of these criticisms, not because you have a real tangible concern. Again, I say “Try it!”
There’s no reason not to get along.