All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Really? You honestly think that a webapp framework should also ship with its own object system, its own cookie parser, its own HTTP server, its own HTTP header system, and to top it off, its own new templating system!

I look at Mojo and can only think that it represents the height of foolish arrogance, and I for one am repelled by it.

Catalyst is far from perfect, but at least the Catalyst developers can concentrate on building a web framework rather than reinventing all the underlying bits.

The problem with it is that it leads to even further fragmentation. Because of the no dependencies rule we get not just another web framework - but a whole lot of new, in bulk most probably simplistic, modules that duplicate functionality of available CPAN libraries.

And once people start coding to it they will not en masse 'move to the more complete and...' alternatives - this never happens. So this will stay and the simplistic nature will quickly be replaced by more complete and complex implementatio

You know, that's kind of how PHP started out. They've kicked our tail on what was our home turf in the 90s. And let's face it, Sebastian is not exactly a newbie. And I remember how people told Adam Kennedy that he was wasting his time trying to parse Perl -- sometimes people produce great things when trying to do more than we think they should:)

OK - but isn't it sad that they rewrite everything? I mean coudn't they get some co-maintanance or something to make sure that the prereqs behave as they want and ship them with their code instead of writing their own versions?

I am waiting for the promised Mojo docs for a deeper analysis - but from what I've seen it has a better API than Catalyst - it looks like there was at least some effort put into designing it. So I am not against Mojo as a whole - I am only concerned about that no-dependency policy.

When the policy is 'no dependencies' - i.e. 'rewrite everything that is not in core' - then there is much chance that some of those bad things will happen. And beside those obvious step backs - I still maintain that duplication of effort - i.e. of rewriting something in a way that is neither worse nor better - this is still sad - it means something failed in the CPAN ecosystem.

Something failed in the CPAN a long time ago. Having too much choice between modules (sometimes equally good and sometimes equally bad) means that there's been some serious fragmentation. This is one case where having CPAN so large has not been a benefit.

Apparently people can't install modules if they have dependencies, but they can install modules if they don't have dependencies. I don't really get it.

But anyway, reinvention aside, Mojolicious::Lite is basically the same tired CGI.pm ideas repackaged as new syntax. Great for blogging (like so many ideas from the Ruby community), but not so great for solving problems web application developers actually have.

> Apparently people can't install modules if they have dependencies, but they can install modules if they don't have dependencies. I don't really get it.

There's a large community of people in the world who don't know Perl, and have a simple FTP-upload shared hosting account.

What these people NEED is a zip file they can unroll into their local dreamweaver/whatever directory, tweak a config file or some well commented lines in the script header, and then FTP upload to their website.

BTW. I use both and will keep using both, but I strongly prefer Mojolicious dispatcher and routes system.

But, yes, I would much prefer have it all based on Moose.

As for the other complaints, you hit and miss on them. The Mojo HTTP framework is MUCH better than any other on CPAN, from a spec-compliance point of view. Maybe thats not something that yo care about, thats ok, but it is a fact.

I won't comment one way or another on what Sebastian's done because I honestly don't know his motivations, but I have a touch of sympathy for his position here. I can't tell you how many times I've discovered two things:

I think you're missing the target audience for this though. Let's be honest, whether you like the language or not, PHP ate our lunch here. Users can just upload some files in a directory on their web server, and it "just works".

In an enterprisey environment would I want Catalyst? Sure. But are users with their cheap hosting plans going to be able to install a Catalyst app? Prolly not.