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.