Response to an Anonymous Critic
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.
As I delve into the deeper Perl magic I like to share what I can.
I was initially interested in Mojolicious, but when I asked about benchmarks a while back on the IRC channel, sri immediately went off on a angry rant about the uselessness of benchmarks. I immediately lost all interest in the project because I would not want to rely on an important piece of architecture that was headed by someone so antisocial. As an aside, I wonder why the Perl community has so many angry geniuses (other examples: mst, mlehmann).
Well I’m sorry to hear that. I personally haven’t had that experience. I do think that programming attracts some of these interesting personalities, I don’t think that’s unique to the Perl language.
You’re missing a lot of background regarding both the Catalyst “fallout” and the vti “fallout”. In fact, there had been numerous “fallouts” which involved curses, abusive behavior, trashing on forums, IRC, CPAN reviews (including ones that actually included impersonating actual Perl community members in order to trash others, srsly!) and so on.
It happened when people wanted to still use Catalyst, it happened with users (coughvticough) actually tried to help and warned core devs (both in Dancer and Mojo) about security issues, it happened without provocation (though one is always claimed), when users tried to help with documentation, when users asked questions, when people tried to criticize and compare projects, and so on.
Basically it’s a blazing hail storm of idiocy and childish tantrums. I’m sorry you don’t know more, but there are a lot of reasons people simply prefer not to work with certain people or their projects.
FWIW, I noticed Mojolicious before Dancer, but picked Dancer purely out of technical reasons. Even though Mojolicious is a great technical project (and has a very skilled core team - each and every one), I know the abuse I’ve experienced there (without even using it!) was enough for me to never use that framework. Ever.
Just to be clear: the Perler in question (who wants to remain anonymous lest this impact his chance to pick up contracts with new clients) never said anything to me about his personal feelings regarding Mojolicious. He wasn’t complaining about Mojolicious, he was complaining about the mindset of companies that choose it: they do so to avoid using the CPAN.
Again, I don’t know how true this is, but this person apparently experienced this more than once and the rationale behind this experience seems understandable (though not something I personally agree with).
I did join Perl long after these events occurred. I had tried to find out the nature of the dispute and I found this including a response about the professional manner of the handling by all parties. I guess I put too much faith into this statement. Sawyer, you know I trust your judgement, so I will defer to your knowledge of the situation. Personally, though SRI does have a distinctive personality, he has been helpful when I have ask questions on IRC and has had productive comments on pull requests I have submitted. Perhaps he has mellowed or perhaps I haven’t set him off yet, but I like to think that its the former.
Ovid, true, I rolled my comment on your article into a larger post that I had been meaning to write on the anti-Mojolicious feelings I had seen. I’m now rather wishing I had excluded the comment on SRI’s personality as my bigger point had meant to be about the anti-CPAN charge. Still perhaps I see now that the personality clash is bigger than I had understood.
Upon reflection, I have removed my history of the Catalyst situation. I’m not really qualified to write it. Regardless I haven’t had any reason to dislike SRI either professionally or personally, so please don’t regard my removal of that content as evidence of either.
chimerix: Good benchmarks are very valuable, it’s just micro benchmarks like “rps for a hello world in 10 frameworks” that i have very little interest in. A rant regarding this wouldn’t be totally out of character for me, but i certainly didn’t mean to offend you, please accept my apologies. Most conversations about that topic usually go more like this. http://irclog.perlgeek.de/mojo/2010-07-30#i_2641921
Sawyer X: I’m not sure where you’re coming from, to my knowledge we have never worked together or had so much as a conversation. I’ll let your insults speak for themselves.
Joel: There seems to be a lot of hyperbole going around about the Catalyst thing, but in reality there is no bad blood and i’ve worked together again with pretty much everyone who was actually involved back then.
Oh, and like i said on Ovid’s blog, i agree with Joel’s conclusion. https://blogs.perl.org/users/ovid/2012/10/mojolicious-an-unexpected-result.html#comment-219304
Saying “I’m not sure where you’re coming from” just implies not understanding something I’ve explained specifically. Funny though, I bet I could easily round about 40 different people (who we both know IRL) who have witnessed conversations (often heated and with a smell of pure assault) between us. I know at least some people have logs of the way you spoke to us and people in our channel.
Saying “hey, I disagree” or “it’s all water under the bridge” is one thing (and I’d applaude that). Acting like you or I have amnesia is something else altogether. :)
However, I do apologize if I hurt your feelings. This is no place for quarrels and I’d rather have none.
I’d be happy to buy you a drink (of your choice) and sit and talk web with you. Seriously, what do you say?
I would very much appreciate links to those logs, then everyone can form their own opinion and doesn’t have to rely on yours. Just make sure quotes from me are not taken out of context.
Well…
I just looked up and found this: http://irclog.perlgeek.de/mojo/2010-07-09#i_2534706.
It would appear that you wrote a nasty tweet and tempire mentioned “you’re throwing some gauntlets” and asked if you’re sure you want to “generate more negative feedback”.
You framed your tweet as “an attack on Dancer” and said it was “pure marketing”. Pure genius.
Now, how about that drink? :)
Nothing wrong with highlighting the strengths of your product by pointing out flaws in the competition, that’s good marketing. I surely wouldn’t call that “a blazing hail storm of idiocy and childish tantrums”, which is probably more offensive than anything i have ever said.
I guess this could go back and forth for quite some time, but i have no interest in quarrels either, just wanted to set the record straight. Let’s just end this here and i’ll take you up on that drink some time.
@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.
Exactly! I think the same.
I have to say I rather strongly disagree with the whole premise that using Mojolicious means you are or are tending towards anti-CPAN.
Our company now uses Mojolicious + Mason, having started out with CGI.pm, Mason, Catalyst + Mason. We moved off of Catalyst due to its positively incredible dependency radius, that made practical application installation effectively impossible. We looked at Jifty as well. Jifty’s dependency radius, the set of modules you had to import and install in order to make this run, dwarfed Catalyst’s. Catalyst’s was huge.
This is an extremely important point. I cannot just start on a new fresh machine with a single installation and a few minor dependency modules.
No.
I have to install a positively massive dependency tree. This is part of what I am complaining about, but not the full item.
Without naming module names (other than to note the word “Mechanize” is prominently featured within them), some of the dependencies upon which Catalyst depends are hopelessly broken and non-installable without a force option. This has not changed over the 6 years we used Catalyst.
At the end of the day we had to deal with the costs associated with these failures. These modules would not work, and modules that had tests that depended upon them would not work. This was across many linux distros, windows, and other OSes.
What we longed for, what we really wanted, was a framework which installed with the minimum of dependencies, which just worked, without any drama.
Mojolicious is this.
Note that I haven’t said anything about CPAN.
We have a private local mirror of cpan at http://cpan.scalableinformatics.com . We use it, regularly. We point all of our installations over to it as the primary point from which to pull modules. Part of our new system bring up involves pulling modules from CPAN.
The two points are being conflated with an assumption that one implies the other. Mojolicious solves a very hard problem for us and does so elegantly and simply. Stuff works, doesn’t break, and there are no dependencies upon things that are broken. This is ABSOLUTELY CRITICAL to being able to install something in a provably correct manner. The lack of dependency upon CPAN for its core functions is irrelevant.
As for companies not wanting to use CPAN, we see this via insistence on using RPM as the preferred package management system (or apt-get, or some windows variation). The important aspect of this is to make sure that when new modules are created, we can generate new OS specific install-able packages on the fly as part of the process. The people who most vociferously complain to me about CPAN are complaining about package management. This is a different issue, and one we collectively, should address. That and getting Red Hat to start using a modern Perl.
Sorry for my lack of English skills. So did you mean your decision to choose Dancer over Mojolicious is technical or not? (I’m reading it as the latter).
Technical. I guess I should have written “purely for technical reasons”.
After using and enjoying Dancer and its community I decided to try and fix things and add features. How I ended up being a core developer is still a mystery. :)
What I like about the no-CPAN “feature” is that I can easily install and develop on a customers GoDaddy or “whoever” service provider.
It also provides beginners with a cheapo shared hosting plan a low barrier to entry with a modern Perl framework. What moden Perl web frameworks are the beginners hosting services providing today? Definitely not Catalyst… Dancer? When beginners start in web development there really aren’t many modern Perl options.
This is fun, so to spice it up a bit I am going to suggest people use Gantry/BigTop which is on CPAN and uses many dependencies.
http://www.usegantry.org/
The author even wrote a book for it, http://www.lulu.com/shop/phil-crow/building-web-applications-with-gantry-and-bigtop/ebook/product-18811773.html
I’ve used Catalyst, Dancer and Mojolicious. I’ve use Catalyst, Dancer and Mojolicious. There are no silver bullets, one-size does not fit all, variety is good, TIMTOWTDI, etc, etc.
I concur, as previously mentioned by someone else, that Mojo/Mojolicious doesn’t appear to me as anti-CPAN at all, after-all, it’s on CPAN and installable using any CPAN client.
I’m willing to bet there are many other distributions that have re-written existing modules or maybe even entire libraries specifically for their distributions. I don’t see this as anti-CPAN either. I’m sure we could easily identify others, but who would volunteer to do such an asinine thing as source-code driving to determine what packages are completely rewriting something that already exists. Maybe its the advertising of the fact that there are no external dependencies which ruffles feathers? Pish-posh.
… which begs the question, “Who really gives a $#!+?”, clients (“the company”) doesn’t, they like this idea of -no dependencies- (as ridiculous as it is), novice Perl developers don’t, they like the idea of writing code that can easily run on shared hosting environments (as ridiculous as that is), and experienced Perl devs can’t (I imagine) because they should/would/could know how CPAN clients work and how to install dependencies easily.
Additionally, you won’t get very far (building a modern web app of average sophistication) without having to consult the CPAN. Mojolicious doesn’t ship with Geo::IP, Facebook::Graph, DBI* this-and-that, so … theres that.
I will say that there can be an air of harshness in many support channels for the aforementioned projects (and you’d be lying to suggested otherwise), but I will also say that all of those projects have magnificently written documentation which can be leveraged (shall we say) without the need for social interaction.
— alowicious
What sort of limitations do these cheapo shared hosting plans have, which prevented running a CPAN client like cpanminus to install modules? Disk space? Availability of compilers? RAM?
Perhaps a tool to bundle Perl modules can help, so that installing Catalyst and its non-core dependencies is just a matter of doing something like ‘tar xfz catalyst-bundle-20121016.tar.gz’.
Hmm. It was a problem in the early days (remember CatInABox?), but installing Catalyst with just a
cpan -i Catalyst::Runtimeand then going away for half an hour has not been a problem for me in many years. (Well,cpanmnowadays – which didn’t even exist back when I stopped having problems.)Nowadays I need to the
cpanmtwice – once with flags to enable parallel testing and once again with those flags off, because a bunch of test suites are not concurrency safe. But with parallelism off, everything installs right away. (At least on Linux and MacOS. Never cared to try on Windows, but frankly I would be (positively!) surprised if things work smoothly there.)@Steven: I think the main limitation with hosting providers is complete lack of shell access. You install stuff by FTPing it over to the host.
This rules out XS, but a fatpacked app with many non-XS deps should work (in theory).
Sorry for my bad english, Perl Hackers, I has (near) 6 months with Perl, I has come from PHP, Python and Ruby languages, so, Perl is Uglyness than all? No, may be, or not, (Uglyness for me is bad structured and modularized code) but Perl is so far the most flexible language that I learn. I still study Software Engineering course based (with small things about Computer Science) here in the Brazil. My Intro to Development Web teacher was working with Perl in the 90’s years, but now he is work with C# (He was work with too, before, Assembly, Fortran, Cobol, C, etc…, good people). When I say that I study Perl, he says “Perl is Hardcore…” to the class, yes, Perl is Hardcore. After it, I speak to he small changes that Perl has, slowly evolve from 2000 years. Yes, I talk about Moose, Perl 6, various Perl 6 implementations, many moderns Web Frameworks, etc… but here in the Brazil, i still has a great chance to catch a work with Perl that i need to maintain 20 year old code, yes, none like to maintain so old code, even Perl is compatible with older versions. Many beginners (different than me) want to learn PHP, Python, Ruby and C#, because this languages still to evolve so much. I think that Perl has make a wrong way, but now I believe that it is change. In the begin, CPAN for me was a 7 head Monster, i try to install a package that need anothers packages recursively, seems no-newbie friendly it. Catalyst is good, it help to make some Perl fame about this Closed Island, but now, Perl need to be more beginner-friendly too, great system can be written with Catalyst, middle and small systems can be written with Mojolicious, prototype and RAD systems with Dancer. Perl has a feature that PHP, Python, Ruby hasn’t: Web Frameworks here are for different purposes. Thanks for fun my day, give me Perl, Perl Hackers. ;)
Oh Sawyer X, i like so much your Dancer presentation for Python Programmers, thanks.