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 <mallah.raj...@gmail.com> 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 mojolicious+unsubscr...@googlegroups.com. > To post to this group, send email to mojolicious@googlegroups.com. > 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 mojolicious+unsubscr...@googlegroups.com. To post to this group, send email to mojolicious@googlegroups.com. Visit this group at https://groups.google.com/group/mojolicious. For more options, visit https://groups.google.com/d/optout.
