Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Mojolicious::Lite 9 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • The fact that it has no dependencies makes it even more compelling.

    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

    • What's wrong with a framework that has such a low barrier to entry?

      As Ovid wrote, there is very little required to use it. It's almost like baby talk for a Perl web framework.

      What would be wrong with getting to learn about frameworks with Mojolicious::Lite and when you understand them, try to move to the more complete and "grown up" Catalyst.

      From alias's Heayy100 [ali.as] Jifty has a dependency of 188 modules and Catalyst isn't in the Top100 so I can only guess (I'll take a WAG and say 100). Which is easier for the

      • 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.

            • ... isn't it sad that they rewrite everything?

              Rewriting in and of itself isn't necessarily bad. Rewriting poorly, ignoring discoveries of art about what does and doesn't work, and fumbling through well-avoided mistakes is bad.

              • 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.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.