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 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Heh. Sukria released Dancer at about the same time on the CPAN, and the two packages do roughly the same thing. Too bad they did not communicate on the matter a little bit earlier. The two projects look like really fun alternatives to ruby's Sinatra. :) http://search.cpan.org/~sukria/Dancer-0_0.99/lib/Dancer.pm [cpan.org]
    --
    oz.

    • Actually they did know about Dancer.

      After the Dancer release to github, vti wrote a dancer clone using Mojo. Eventually he re-wrote it using Mojolicious, and that was the spark that ignited Mojolicious::Lite development.

      Best regards,

      --
      life is short

        • Uh, that's a little unfair. I've been using Mojo since November last year and it from the git log you only put Dancer on github a few weeks ago.

          Mojolicious::Lite is just a variant on the Mojolicious code to allow you to have apps in one file, like you have in Dancer. It's not a fork.

          --

          -- ask bjoern hansen [askbjoernhansen.com], !try; do();

  • I agree that posts with content are a form of marketing, and this one that I am commenting on is fine as it points at a useful module. It's just all the meta about how we need a marketer that bothers me. I'm fine when people talk about that and pursue hiring a marketer or whatever, but just talk about marketing is, at least to me, not helpful.
    --
    --fREW
    http://blog.afoolishmanifesto.com

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

    • That sure was an angry note. I share much of your analysis - but this kind of polarizing does not bring us closer to any resolution.

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

        That is EXACTLY the reas

        • Exactly.

          I don't mean to say that having a lot of dependencies is bad, it's just daunting sometimes to figure things out.

          I'm not afraid of them [blogspot.com] nor am I fully embracing [catalyzed.org] them either.

          Adam and others are working hard to get a more reliable dependency chain, but as Adam mentioned simplicity counts for a significant amount.

          Barrier to entry is important.

      • There's a big difference between "installing" a module and unpacking it in a directory. Almost anyone can do the latter.

        And I can't agree with your comments comparing Mojolicious::Lite to CGI.pm. I'm very familiar with the latter module and it doesn't, out of the box, support this:

        # /foo/*
        get '/foo/:bar' => sub {
            my $self = shift;
            my $bar  = $self->stash('bar');
            $self->render(text => "Our :bar placeholder matched $bar");
        };

        # /*something/foo
        get '/(:b

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

      --
      life is short

      • And was it really impossible to work with existing authors to improve their modules? No, of course not, and it's obvious SRI had no interest in doing so.

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

          1. They built a wheel for a car and I need one for a motorcycle but I'm criticized for "reinventing the wheel" [perlmonks.org], even though the available wheel's won't fit my vehicle.
          2. They built a wheel for a car and it has a flat, so I point out that it's punctured, offer to patch it, offer to jack the car

          • My issue is more with you promoting this as a good Perl example.

            SRI can do whatever he wants, and should feel free to experiment and have fun.

            But his marketing, while good from a marketing perspective, is a turn-off to me because it ignores all the existing solutions.

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

    • Most of the "reinventing" is very thoughtfully done - and in surprisingly little code.

      The template thing is indeed a little silly; but it's a very simple template module and Mojolicious has extensive support for plugging in other "renderers" (a bunch already exist on CPAN).

      It's all trade-offs (of course).

      With Catalyst there's a good deal of "having to learn the underlying bits" to really understand what's going on. In Mojo there's less code and it's more internally consistent.

      (That being said, I do think

      --

      -- ask bjoern hansen [askbjoernhansen.com], !try; do();

  • "See what happened? Sebastian was trying to communicate the benefits of his software to a potential consumer and it piqued my curiosity. You know what that's called? Marketing. It may have a different end goals and customers, but it's still marketing."

    +1

    "Marketing isn't just ads. It's not just articles in newspapers. It's not just viral videos. It's not just guys walking around in crazy costumes handing out leaflets. It's also people touting their latest Web framework in their blogs. It's people teaching

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