Mojolicious: an unexpected result
While at the Italian Perl Workshop I was talking with a gentleman who does a lot of contract work (and gave me permission to anonymously share this story). Most of his contract work deals with the Web and he's fortunate enough to have worked with quite a few companies who are a bit more sophisticated than the old CGI.pm days. In fact, some of them use Mojolicious, an excellent Web framework that many developers are enjoying. Mojolicious is fast, flexible, robust, and has no CPAN dependencies.
This developer hates working for clients who use Mojolicious. I confess that I was surprised when I found out why. It's an exercise in "unintended consequences".
One of Mojolicious' primary design goals was to install cleanly without depending on anything from the CPAN. While there have been some criticisms of this, for anyone who's gone through the dependency upgrade hell of updating a major framework, it can really be a nightmare. Here's how it tends to work in companies:
- Developer: We should upgrade This::Wonderful::Framework
- Manager: Why?
- Developer: We're getting out of date
- Manager: So?
- Developer: But if we're too far out of date, we can't use the new features
- Manager: So?
- Developer: But the new features will make our life so much easier!
- Manager: So?
- Developer: I mean, a feature that took me a day to develop will now only take me an hour!
- Manager: And how long will the upgrade take?
- Developer: A few hours
- Manager: And can you guarantee that no other upgraded dependencies will break anything? Do you have a test plan to verify this? Do you have a rollback plan if things go wrong? Are other teams reliant on older features that might have been deprecated or silently changed?
If this seems ridiculous to you, now think about:
- Your programming language(s)
- Your Web server
- Your mail server
- Your operating system
- Your database
- Your version control system
- Your DNS servers
- Your firewalls
- Your CMS
- Your wiki
- Your ticketing system
- Your [insert any other piece of technology here]
You have many people in different areas using different technologies who want to upgrade. There are often many requests to upgrade and as a company grows larger and more complex, a manager's job is to manage complexity to make it, well, manageable. Thus, there's a strong, strong tendency to say "You can't upgrade until you have no choice." This has the upside of maintaining stable systems. This has the downside of being a right pain in the *** when it comes time to upgrade. Thus — and I've seen this many times — people often just do the upgrade and cross their fingers. It usually works, but the one time it doesn't work it's hellfire and brimstone to correct the damage.
Enter Mojolicious: with no dependencies and being a piece of cake to install a local version of, you minimize the risk of clashing with other pieces of software when you upgrade it. More than once I've upgraded large Perl modules and found strange failures in apparently unrelated places. That's less likely to happen with Mojolicious and to my mind, this can be a powerful advantage.
So what happens when this developer works with clients who use Mojolicious?
It turns out that are using Mojolicious because they don't like using CPAN. Install a couple of CPAN modules and that hundred lines of code is reduced to two lines of code. They'll have nothing to do with that. You better sit your tail down and write that hundred lines of code.
Obviously I don't have this contractor's first-hand experience, nor do I know if his experience is common. However, though it wasn't obvious to me at first, hearing that some companies adopting Mojolicious are averse to using the CPAN isn't that much of a surprise.
Note: if you're a developer of Mojolicious or you're a Mojolicious user who is reading this blog, you'll be far, far less likely to be CPAN averse (for reasons I think should be obvious). However, there are a lot of companies out there who aren't interested in the Perl community and don't talk to us. Thus, I would expect that most of us wouldn't experience this issue, but this lone contractor working in the wilds gave me a brief, but fascinating insight into the larger issues we're faced with.
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
I started a response, but it became an article: https://blogs.perl.org/users/joel_berger/2012/10/why-people-dont-like-mojolicious.html
I think Joel is drawing the right conclusion. The question we should be asking is what these folks would be using if Mojolicious didn't exist? CGI.pm or maybe even PHP? I see Mojolicious more as a gateway drug that will show them the way to CPAN. If you want better performance, SSL, IPv6 or interact with a database, you will have to install modules from CPAN. All we are trying to do here, is making it easier to get started.
Now that is a good response. And no, I'm not being cynical at all.
To be honest I see a sort of soft anti CPANism all the time. And its not related to Mojolicious. Quite often companies have trouble using CPAN (because they are using a system or built in Perl, not using local-lib, or using mod_perl which tends to be a bit hard to upgrade) so they give us. And then they build a one shop only stack that makes it harder to use CPAN even if they want to. And the programmers there don't bother to keep up with what's going on in CPAN and don't become part of the community etc which tends to just get worse and worse over time.
At least I've seen that at probably half the Perl shops I've worked at over the years.
I also don't understand that particular "no dependencies" design goal. As they say in economics, self-sufficiency is the road to poverty. I might (consider myself) the best in producing a certain piece of software, but I realistically am not the best in developing every piece of software. Why should I write everything myself?
But then, every developer (myself included) have been inflicted with the NIH syndrome every now and then.
BTW, I'm not refering specifically to the Mojolicious project.
I expect the real problem at these companies is that they don't know how to manage CPAN modules (or any other dependencies) properly.
At $work we use hundreds of CPAN distributions amounting to over 1000 modules, and adding another distribution is trivial because we've streamlined the process of packaging it, checking the dependencies, testing it, and getting it installed in development, staging and production.
Mojolicious comes into it only because using a dependency-free web framework allowed them to dodge the package/dependency management problem for longer than they should have, where most companies hit upon this problem and solve it fairly early on.