in reply to Constructive thoughts on Dancer2 v Mojolicious

are all things equal between these two frameworks

I don't use either of them. Now and again I go back and have another look as many fellow monks are wont to rave about one or the other but neither has yet enticed me enough to dive in. That said there are clearly some differences between them and that may or may not influence a decision to go with one or the other. It depends largely on which attributes you deem most important.

Non-core direct deps28none
Open issues10646
Issues resolved this year1329
Metacpan ++115 (47 PAUSErs)427 (181 PAUSErs)
Last release27th May3rd June
Non-dev releases this year417
Test coverage84%90%
Kwalitee150 (96.88 core)156.25 (96.88 core)
Reverse deps (direct)168 (148)964 (858)
LicenceAs PerlArtistic 2

Numbers correct at time of posting (E&OE). No doubt you can pick other metrics of importance to you. Given the recent releases from both, comparing the smoke tester pass/fail ratio seemed not to be useful (and they both have good records there anyway).

  • Comment on Re: Constructive thoughts on Dancer2 v Mojolicious

Replies are listed 'Best First'.
Re^2: Constructive thoughts on Dancer2 v Mojolicious
by 1nickt (Abbot) on Jun 05, 2020 at 02:46 UTC

    Thanks hippo,

    As I have stated I use both frameworks both at my job in a big org. The main app is built in Mojo. Personally I choose Dancer2 at work and at home and I have contributed to the project.

    Here's my perspective: none of the metrics you shared are of much use in evaluating the comparative worth of the two projects. Let's take the two most divergent ones, and the two that most embody the philosophical differences between Dancer and Mojo. Both the non-core deps count and the metacpan plusplussers count are in my experience merely indicators of the cult-like nature of Mojolicious. Dancer2 on the other hand is much more like an open source framework.

    Mojo is likely to evolve into an OS at the rate it is reinventing all the wheels. I like my app framework to be more of a scaffold. I want to be able to pick up my entire route-handling codebase and drop it into another scaffold if I choose; no way I can do that with a modern Mojo app.

    Again from my perspective: more dependencies nowadays means (or should mean) that the app is more Perlish, not that it is bloated; fewer releases means it is more stable; open issues is a shame but could easily be housekeeping -- I know from experience that the Mojo core devs are very aggressive in closing tickets with WONT_FIX.

    It's one of those things where Mojo has clearly won the popularity war, but not necessarily because of quality. I used to surf with some guys in SoCal that could surf just as well or better than anyone on the WCT, but either because of circumstantial fate, or because they were more of a spiritual surfer than a competitive shredder, they were less known, even anonymous. Most of them liked it that way, and I know I enjoyed being in the water with them more than with the pros.

    I have way more fun working with Dancer; I find that I am able to be a more expressive developer. But hey, some people use IDEs ... cada cabeza es un mundo ...

    The way forward always starts with a minimal test.
    A reply falls below the community's threshold of quality. You may see it by logging in.