Hello John , Thanks for taking the time out to write a detailed account.
I have started writing a full mojo application and integrating yancy to it and using DBIC backend. I am linking it very much . Hope will be able to complete the application within deadline. regds mallah. On Thu, Jan 3, 2019 at 8:14 PM john napiorkowski <[email protected]> wrote: > Hi Rajesh, > > I'm also a long time Catalyst user (10+ years) who is exploring > Mojolicious. The 'TD;DR' version of this is that you really need to > try making an application and see for yourself. The docs are great > compared to Catalyst and there's a goodly number of example > applications around you can look at to get the idea. It really will > depend a lot on what you like and miss from Catalyst. That will help > you determine if you want to stay with Perl, or if the effort of > learning a new framework might push you to jump ship to a different > language. On that matter I won't speak. > > Here's what I can see as the list of major differences: > > 1) Full stack versus 'TIMTOWTDI'. Catalyst, despite having a > reputation as a heavyweight framework, is actually pretty minimal. It > doesn't even build in basics like static file support. Mojolicous > builds in everything you need (session support, views, etc) for your > week one+ development. On the other hand Catalyst offers a lot more > choices for components like Views and Sessions for example. > (Mojolicous does have alternative Views but its pretty clear to me (or > at least to me) that the Mojolicous community prefers you use the > approved Mojolicious stack of stuff. This even extends to using > Mojo::Base as your class builder (if you like Moose or Moo there's > nothing stopping you but I get the feeling like that's considered > 'going off the reservation'.) There's pros and cons to both > approaches, you have to decide what works for your style and if you > don't mind a walled garden approach. > > 2) Dependency count. Catalyst will require installing a lot of > dependencies to get to a useful workable place. Like I said, > Mojolicious gives you a ton of stuff with a single dependency. If you > find managing Perl dependencies hard you might like that. Even though > I personally don't find it hard I will say it was nice to note have to > deal with it when starting a new project. With Catalyst I find I > spend the first few hours of a new project setting up boilerplate. > That's a one time effort but it was nice to not have to worry about > it. I'd also say that some of the built in Mojolicous stuff (like the > great static file handling) made me immediately jealous. > > 3) Routing. Catalyst controllers use method attributes for routing, > Mojolicous has an API that you use to declare routes programatically. > This is probably the biggest visual difference. If you absolutely > loved the Catalyst approach you will likely find the Mojolicous > approach cumbersome for large numbers of routes (at least at first). > On the other hand in consulting on many Catalyst applications its > clear to me that many people find the Catalyst way difficult to > understand. So you might find the Routes API a breath of fresh air. > I'm still wondering if its suitable for application with large number > of routes, but again you have to try it yourself (and look at some > example applications with lots of routes and how people tried to > handle that to see if that seems a reasonable compromise to you). > > 4) Catalyst Components (Models, etc) versus Helpers. Catalyst models > are pretty powerful and in expert hands you can do a lot with minimal > boilerplate code. For example Catalyst will auto load and instantiate > models for you and you can control the instance lifespan. Its possible > to cleanly decouple your application from a particular instance class, > for example. But the API is complex and again as a consultant on many > Catalyst applications its clear to me most people never learn to use > it properly. Mojolicous Helpers are much easier to grasp immediately > and with a little munging can basically do most of the same thing, > minus the autoloading and automatic binding of configuration values. > You probably end up writing more boilerplate but people seem to > understand it better. This is probably my biggest sore point coming > from Catalyst FWIW. I find Mojolicous helpers encourage writing to an > instance not an interface but I am sure others will strongly disagree. > And FWIW everything about helpers I don't love could be fixed. > > 5) Advanced web features and support for async. You mentioned stuff > like web sockets, etc. Catalyst will never see that without effort > that clearly doesn't exist. If you need those things then Mojolicious > is the only game in town for Perl that is production grade. Catalyst > has experimental support for that stuff but its mostly there as a > pointer to what needs to be fixed in order to make it production > worthy. I haven't looked but I would say Dancer would have to be the > same since both are limited by PSGI. > > 6) Long term? Catalyst currently has no development goals, team, etc. > It does everything well it did well yesterday. You can see that as a > pro or as a con. If you are building an application for someone that > doesn't want to maintain it then Catalyst might be a good choice since > it has always emphasized long term compatibility. As a consultant on > many Catalyst applications I've seen people upgrade after years > without very much trouble. Mojolicous appears to be faster moving and > probably more suitable for an application that is seeing active > development and has an active team. For example if I was building a > small application for a non profit that just wanted it to work and was > not expecting the application to have a need for lots of changes over > time, then Catalyst would be a good choice. On the other hand if I > was kicking off a new startup and using Perl and had a team then I'd > likely choose Mojolicous. > > There's probably other things, and I'm sure some people will argue > with me (you'll probably find Mojolicioous supporters are gravely > enthusiastic) but those are my thoughts after about 9 months of > playing with Mojolicous after 10+ years of Catalyst. For me the jury > on 'use Mojolicious or jump to another language' is still out but > maybe it will be otherwise for you. Best of luck. > > -JNAP > > On Wed, Jan 2, 2019 at 9:54 PM Rajesh Mallah <[email protected]> > wrote: > > > > Hi List , > > > > I am coming from the Catalyst world after doing around 5-6 projects in > Catalyst. > > I linked Catalyst over what i was using earlier. Earlier i was using > HTML::Mason > > and before that Embperl :-) I am using perl for past 15 years and > intend to continue > > using it. > > > > The main reason of moving to mojo are as follows > > > > (1) A lively mailing list. Catalyst list is more serene. > > (2) Lively development: I see that mojo is more up-to-date > > with latest technologies (eg: recent support for graphql and old > support for openapi) > > I am hopeful that i should be able to use these technologies here. > I am thankful > > to the contributors who are relentlessly improving Mojo & Perl. > > (3) it is similar to Catalyst. > > > > Instead of converting my old projects from Catalyst to Mojo i would like > to > > do a new project in Mojo and experience the difference. > > > > I would also want to pen my experience as a migration guide for other > people > > willing to use Mojo and have prior Catalyst experience. > > > > A short question is what all i will miss in Mojo that is there in > Catalyst framework. > > Also how does Mojo compare with django as a web framework > > ( apart from the fact that the former is python and we are perl). > > > > Regards > > Rajesh Kumar Mallah > > ( https://www.redgrape.tech ) > > > > -- > > You received this message because you are subscribed to the Google > Groups "Mojolicious" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To post to this group, send email to [email protected]. > > Visit this group at https://groups.google.com/group/mojolicious. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Mojolicious" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/mojolicious. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
