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.
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 ;)
Mojolicious also runs within Perl's version of Rack, called PSGI.
Great stuff!
The whole point of Mojolicious is to be an integrated set of tools that work well together, whereas Catalyst is focused much more on being a part of the wider CPAN ecosystem, and generating its own ecosystem of extensions in turn.
I'm not sure how to take this—I usually pitch Sinatra to people by saying it pitched out all the crap in Rails. Which one is it?
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 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.
You may not notice that it's using an event loop at first because by default the framework emulate IO blocking behaviour.
I've had a similar idea for something in Haskell and it's cool to see someone doing this.
I have yet to see frameworks offer routing coming in from the websocket connection itself because it also requires non-standard javascript to send the route requests through a parent websocket connection.
Which is why I was thinking that it's the way this framework was designed.
Thanks for this mojo!
