4 ms·

Mojolicious 5.0 released: Perl real-time web framework

71 points by kraih 12y ago

ixmatus 12y ago
So, it's a web framework that receives route requests and sends responses over a WebSocket / Comet connection? I've had a similar idea for something in Haskell and it's cool to see someone doing this.
- Mithaldu 12y ago
  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.
- kasperset 12y ago
  Checkout http://www.chicagoboss.org/about.htm http://www.chicagoboss.org/about.htm Written in Erlang
  - ixmatus 12y ago
    Yeah I'm aware of Chicago Boss and have used it, but like most "frameworks" websockets are bolted on and you have to write special handlers for them. 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.
    - 616c 12y ago
      Yeah, this is a common problem. From a previous post from someone else on HN, I began reading about N20, which is focused on Websockets as its first class transport. I am reading the docs because this is one of its many interesting features. https://github.com/5HT/n2o https://github.com/5HT/n2o
jusob 12y ago
Any body has used both Mojolicious and Catalyst? I wonder how Mojolicious might be better than Catalyst.
- mst 12y ago
  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.
- kasperset 12y ago
  Mojolicious is written by same person who started Catalyst so expect improvements.
- noeleon 12y ago
  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.
- agranig 12y ago
  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.
- jdrago999 12y ago
  To use Ruby-isms, Mojolicious is like all the simplicity of Sinatra and all the does-everything-you-could-ever-want of Rails. Mojolicious also runs within Perl's version of Rack, called PSGI. Great stuff!
hernan604 12y ago
"Sebastian Riedel"++ Thanks for this mojo!
- tmaly 12y ago
  I second that, thanks Sebastian
sigzero 12y ago
Those are some nice added features. Awesome and kudos to everyone for making it happen.
kvorg 12y ago
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!)

71 points by kraih 12y ago

So, it's a web framework that receives route requests and sends responses over a WebSocket / Comet connection? I've had a similar idea for something in Haskell and it's cool to see someone doing this.

Mithaldu 12y ago
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.
kasperset 12y ago
Checkout http://www.chicagoboss.org/about.htm http://www.chicagoboss.org/about.htm Written in Erlang
- ixmatus 12y ago
  Yeah I'm aware of Chicago Boss and have used it, but like most "frameworks" websockets are bolted on and you have to write special handlers for them. 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.
  - 616c 12y ago
    Yeah, this is a common problem. From a previous post from someone else on HN, I began reading about N20, which is focused on Websockets as its first class transport. I am reading the docs because this is one of its many interesting features. https://github.com/5HT/n2o https://github.com/5HT/n2o

jusob 12y ago

Any body has used both Mojolicious and Catalyst? I wonder how Mojolicious might be better than Catalyst.

mst 12y ago
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.
kasperset 12y ago
Mojolicious is written by same person who started Catalyst so expect improvements.
noeleon 12y ago
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.
agranig 12y ago
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.
jdrago999 12y ago
To use Ruby-isms, Mojolicious is like all the simplicity of Sinatra and all the does-everything-you-could-ever-want of Rails. Mojolicious also runs within Perl's version of Rack, called PSGI. Great stuff!

hernan604 12y ago

"Sebastian Riedel"++ Thanks for this mojo!

tmaly 12y ago
I second that, thanks Sebastian

sigzero 12y ago

Those are some nice added features. Awesome and kudos to everyone for making it happen.

kvorg 12y ago

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!)