I love the high level of polish and integration with other modern techs. Mojolicious has achieved. What I don't understand is the miunderstandings of the dependency and CPAN use design decisions: anyone using Mojolicious will notice the whole package is often smaller and faster than one of the specific packages they criticize Mojolicious to reimplement instead of just using, and most of such specialized packages are either useable or, when appropriate, simply used when available anyway. In the same vein, different kinds of APIs are exposed over the same efficient implementations (Mojolicious::Lite, B() ...). I find this an efficient and modern approach all new Perl projects should adopt and just count Mojolicious as a part of my core package tool chest (even when not writing a web application).
Go Mojo! (And ty kraih!)
It's actually a fully-featured framework that can be set up in whatever way you like. The realtime part is special because it's one of very few web frameworks that have integrated WebSockets from the very start in the core.
Mojolicious is more tightly integrated, and yet if anything -less- opinionated about how you structure your controllers etc.
Plus it's focused on adding cutting edge features and cleaning cruft out the codebase regularly, which means it tends to be shinier but less backwards compatible.
"better" is relative; if you want to be able to pick up an app you last worked on three years ago and upgrade its dependencies under it and expect everything to still work, you'll do better with Catalyst. If you want to be able to write code to elegantly support the sort of push-based async code that wasn't really even a thing three years ago, you'll do better with Mojolicious.
For everything else ... it mostly depends on if you need the wider ecosystem and full-Moose-OO that Catalyst offers, which I consider pretty much necessary for large scale projects ... but if don't already understand why you want that, I'd say either is a pretty good choice.
Different. Not better. Each has their strengths and weaknesses. Mojo has websockets, catalyst has excellent backwards compatibility, proven scalability and works well with large teams of developers. Although catalyst has more dependencies, but that comes with the featureset.
As for quick prototyping, they're both good for that once you know how to use them, and they both have excellent docs, although catalyst has been around for longer and has more deployments and realworld examples, which is always good.
Overall though, they're both constantly being improved, and competition is healthy, and it all depends in what you want, websockets, extra rapid prototyping and no deps, or reliability, support, large feature set, excellent scalability and a proven track record both in production and during development ;)
Well, mojo seems to try to escape catalyst's dependency hell by providing everything by itself. That's considered a pro or con depending on the view point. The websocket integration is definitely a plus.
Mojolicious for one doesn't have the dependency tree of Catalyst, this is kind of against of the Perl mantra of don't re-invent the wheel.
That said I favor Mojo over Catalyst for almost every project these days, it's very easy to work with and quick to prototype an application using the 'lite' mode.
I've used Mojo for a personal project, and Catalyst yeaaaars before for a simple project I forget.
I haven't used either well enough to compare, but I will say that Mojo seemed very easy to get started with, and I say that as someone who pretty much hates modern web development.
[+] [-] kvorg|11 years ago|reply
[+] [-] ixmatus|11 years ago|reply
I've had a similar idea for something in Haskell and it's cool to see someone doing this.
[+] [-] Mithaldu|11 years ago|reply
[+] [-] kasperset|11 years ago|reply
[+] [-] hernan604|11 years ago|reply
Thanks for this mojo!
[+] [-] tmaly|11 years ago|reply
[+] [-] jusob|11 years ago|reply
[+] [-] mst|11 years ago|reply
Plus it's focused on adding cutting edge features and cleaning cruft out the codebase regularly, which means it tends to be shinier but less backwards compatible.
"better" is relative; if you want to be able to pick up an app you last worked on three years ago and upgrade its dependencies under it and expect everything to still work, you'll do better with Catalyst. If you want to be able to write code to elegantly support the sort of push-based async code that wasn't really even a thing three years ago, you'll do better with Mojolicious.
For everything else ... it mostly depends on if you need the wider ecosystem and full-Moose-OO that Catalyst offers, which I consider pretty much necessary for large scale projects ... but if don't already understand why you want that, I'd say either is a pretty good choice.
[+] [-] n0body|11 years ago|reply
As for quick prototyping, they're both good for that once you know how to use them, and they both have excellent docs, although catalyst has been around for longer and has more deployments and realworld examples, which is always good.
Overall though, they're both constantly being improved, and competition is healthy, and it all depends in what you want, websockets, extra rapid prototyping and no deps, or reliability, support, large feature set, excellent scalability and a proven track record both in production and during development ;)
[+] [-] jdrago999|11 years ago|reply
Mojolicious also runs within Perl's version of Rack, called PSGI.
Great stuff!
[+] [-] agranig|11 years ago|reply
[+] [-] noeleon|11 years ago|reply
That said I favor Mojo over Catalyst for almost every project these days, it's very easy to work with and quick to prototype an application using the 'lite' mode.
[+] [-] mpyne|11 years ago|reply
I haven't used either well enough to compare, but I will say that Mojo seemed very easy to get started with, and I say that as someone who pretty much hates modern web development.
[+] [-] rihegher|11 years ago|reply
You may not notice that it's using an event loop at first because by default the framework emulate IO blocking behaviour.
[+] [-] kasperset|11 years ago|reply
[+] [-] sigzero|11 years ago|reply