in reply to Constructive thoughts on Dancer2 v Mojolicious

Disclaimer, I tried Dancer2—well, Dancer—early on and didn’t like it and the only time I went back since v2 to look again—from a problem/question posted here—I saw code that I thought was… smelly, so stopped again without retrying. Plenty of good hackers like it so don’t discount it merely on my experience. That said, I am extremely experienced. :P I’ve written three blog platforms and two of my own webframeworks.

Mojo is a full toolset. Its testing and content parsing in particular are deeply valuable. I have still not written anything serious with Mojo because I know Catalyst and CGI.pm and naked Plack and my own nonsense well. I would almost certainly choose Mojo for a real, shared or public, project specifically because it makes test driven development semi-trivial and it is keeping up with security and new technology better than the other frameworks. It also just feels Perly, terse and DWIM. Sidenote to that, the chief architect of Mojo also created Catalyst and had one other framework between so Mojo represents a LOT of accumulated wisdom applied to the workflow of writing and maintaining web applications.

  • Comment on Re: Constructive thoughts on Dancer2 v Mojolicious

Replies are listed 'Best First'.
Re^2: Constructive thoughts on Dancer2 v Mojolicious
by 1nickt (Canon) on Jun 04, 2020 at 18:29 UTC

    For the record Dancer and Dancer2 are completely separate toolkits. Dancer2 is *not* version 2 of Dancer. Dancer has been described by the project leads as "a big collection of abuses of globals." On the other hand, Dancer2 is by far the most Perlish framework I have used.

    Mojolicious has also undergone breaking changes, but uses major version numbers, and then deprecates/uses an EOL schedule for earlier versions. So you wind up having to pin a version anyway.

    I use Mojo at work and it works. I dislike a lot of things about it, all mostly centered around the personality/culture of its core development group. For example, Mojo 8 includes Mojo::DynamicMethods.pm, which despite its doc breaks our code using can ... 

    monkey_patch $dyn_pkg, 'can', sub {
    my ($self, $method, @rest) = @_;
 
    # Delegate to our parent's "can" if there is one, without breaking
+ if not
    my $can = $self->$caller_can($method, @rest);
    return undef unless $can;
    no warnings 'once';
    my $h = do { no strict 'refs'; *{"${dyn_pkg}::${method}"}{CODE} };
    return $h && $h eq $can ? undef : $can;

    [download]
    Talk about EETOOMUCHMAGIC!

    Adopting Mojo is a bit like getting jumped into the mob: there's no exit, and the rules are the rules. I find Dancer2 app development to be much more intuitive, light, and fun.


    The way forward always starts with a minimal test.
[reply]
[d/l]
[select]

      I did qualify my take with saying good devs like Dancer!

      Magic is concerning but if the dev team is behind it, I don’t mind. That code looks clean and safe to me.

      So you wind up having to pin a version anyway.

      Yeah, some of the speed releases early on in Mojo are what kept me from investigating it for years. Plus I can’t use it at work because *SIGH* we’re still on 5.8. That said, professional software should specifically set every version of every package it contains. A good test suite generally makes updates to libraries easy; or at least quickly finds what can’t or shouldn’t be updated.

      It was basic Dancer2 backend code that kept me from trying it again: badly scoped variables. And again, the reason it took many years to even consider this stuff is I’m pretty thermally energetic feces with Catalyst. :P

[reply]
      >Adopting Mojo is a bit like getting jumped into the mob: there's no exit, and the rules are the rules.

      Never thought of it quite this way, but now that you mention it I got the same feeling from early Perl frameworks like PHP and Mason, not to mention this sentiment applies to Moose and it's elk.

[reply]

In Section Seekers of Perl Wisdom