Mojolicious – Perl real-time web framework

by megahz • 12 years ago

268 87 12 years ago

perlgeek2• 12 years ago

I've done a few small projects with Mojolicious, and it's been real fun to work with.

The only thing that's missing is a book that explains the concepts in more depth than the documentation. (I believe some folks in the community are working on that).

walterbell2• 12 years ago

It would be helpful to compare it with projects in other languages, e.g. pro/con with Node.js or Erlang.

rihegher• 12 years ago

I don't know much about erlang but I used to write node.js app and I still maintain some today.

I really like the new concept brought by Node.js. However I realised that most of the time I don't need/want to write asynchronous code which I found harder to test and grow than synchronous code.

Now Mojolicious is a non-blocking IO framework that simulate blocking IO by default. This means that with Mojo you can write code either with blocking or non-blocking IO. To do that you'll have to learn using the mojo::IOLoop which is less natural than node.js to do non blocking but does the job and got easier to use with the 5.0 release.

With node.js you don't have that choice, you're stuck writing application entirely asynchronous.

lazyloop• 12 years ago

My favourite IRC client is built with Mojolicious! http://convos.by/

pimlottc• 12 years ago

What exactly is a "real-time" web framework? Is that anything like being "web scale"?

kraih• 12 years ago

Not at all, it's a "real thing", the Wikipedia article might be of help. http://en.wikipedia.org/wiki/Real-time_web

lumpypua• 12 years ago

A framework that can natively communicate with a browser via mechanisms like Comet or WebSockets. An example is when a new message is posted to an inbox on the server, and your browser immediately updates the message count without polling.

Non-realtime frameworks often have to resort to communicating with websockets over something like zeromq.

agilityfeat• 12 years ago

Anything that allows two browsers to communicate directly with each other without the user intervening can be called a real-time web framework. Examples include WebSockets, the WebRTC DataChannel, publish/subscribe networks, paid services like PubNub or Kaazing, etc.

doesnt_know• 12 years ago

The "installation" instructions wgets a script (over http) which in turn curls a raw github link of cpanminus which is "a script to get, unpack, build and install modules from CPAN" which then downloads and installs the perl module.

How many developers or "power users" would have just ran that command without even thinking about it?

I guess signing packages with trusted keys and serving them over https is far too lame for devs these days.

(Not that I'm calling out this particular project, it's seems to be crazy popular to offer "curl some.script | bash" as installation instructions lately for some reason.)

mike-cardwell• 12 years ago

Hopefully, most people would check their package managers first. Debian and Centos both have packages for it at least.

collyw5• 12 years ago

Distro packages are often a bit behind the official releases. I prefer to develop in the most recent version of a framework / library, as it generally makes things a bit more future proof.

singingfish• 12 years ago

nope, cpan is a fast changing target. You can make it easy on yourself by building your own perl (with perlbrew, super easy) and managing your cpan modules with cpanminus. The system perl is for the system, your perl is for you.

txutxu• 12 years ago

This is a fully open source project. And that, includes all the packaging and deployment tools involved and available (tons of options).

Big corps (and users which avoid smartphones, certain social networks, marketing campaigns, etc, like me), should develop their internal git mirrors, cpan mirror, build systems, etc. As usual.

Many developers reproduce the same issue with node, python, ruby etc. That does not remove LOVE from this beautiful framework.

I can state that the mojolicio.us "web development can be fun again" is true for me.

Just go for it, check yourself the docs and the source, hack, and judge by yourself.

We are talking about that, not about the lack of common sense of many developers, when the topic is about systems, security and operational tasks.

Perl apps can be deployed securely after auditing them. What knowledge do you lack about this defocus topic ?

odc2• 12 years ago

These instructions are for people unfamiliar with perl and CPAN.

Developers are supposed to do "cpanm Mojolicious", like for any other perl module.

dsr_• 12 years ago

So the people least equipped to evaluate the security implications of the friendly instructions are the ones who are most encouraged to do something awful?

"Thou shalt not curse the deaf, nor put a stumbling-block before the blind"

sarciszewski3• 12 years ago

Oh god, wait until you see this thread? https://github.com/kraih/mojo/issues/656

mst2• 12 years ago

When your immediate response to a post pointing out your non-constructive attitude is to say "Oh excuse me your highness." followed by "Blow me", I'd say the project leader's initial estimation of how constructive you were intending to be was pretty accurate.

sigzero3• 12 years ago

Would have been so hard to just ask "Hey, why do you do the shell/pipe install?" and then engage in MEANINGFUL conversation about the pro/cons? Guess not.

f055• 12 years ago

I've been using Mojolicious for about 5 years now - from somewhere around v1.0 - and it's been awesome. The more I learned the easier and quicker things got. Now I use if for all my backend needs, from SaaS, APIs to real-time websockets - and there's still a ton of things Mojo can do but I never tried them. Not to mention Perl itself. And CPAN.

Let's face it - Perl is magic ;)

Daviey• 12 years ago

As web frameworks go, I prefer the experience of Django.... but a recent project I did with Mojolicious was a really fast experience to 'get something' together, whilst also staying out of the way.

odc2• 12 years ago

I love the combo Mojolicious + Mango (the MongoDB driver). They allow to build a completely non-blocking applications very easily.

blue1• 12 years ago

The problem with framework reviews is that they are mostly written by people that have used just that one (not surprising since it takes some time to become proficient in such things), and always the conclusion is, oh it is awesome.

I would be much more interested in a comparison with the alternatives, for example Mojolicious vs Catalyst, but apparently very few people are able to do that.

rikacomet• 12 years ago

I can true that. I usually see a lot of Perl Devs, think that Perl as a language is not worth learning from scratch, and the framework is all there is to it.

As soon as you mention the outdated (indated by FCGI-mod_perl) CGI module .. you are thought to be living in the 90s. For production, I can agree partially with them, but for educational purposes, it twitches my nerve :/

Though, I like mojo over others due to its lean code.

perlgeek2• 12 years ago

I've used both Catalyst and Mojolicious. Mojolicious is much easier to get started with, because you don't have to touch several namespaces just to get a single page to render.

Also doing non-blocking stuff with Catalyst seems to be a real pain (though I haven't tried it yet).

BugBrother4• 12 years ago

I liked the Catalyst tutorials and general documentation. But Catalyst is not Dancer, which is like chewing air to learn. :-)

When I read up a little on Mojolicious to have an opinion a couple of years ago, it seemed more complex than Catalyst?

I'll put my JavaScript hobby aside and look at it again. Any good links? [Except the one posted by walterbell at http://blogs.perl.org/users/joel_berger/mojolicious/ Grumble, that was already on my reading list.]

instakill• 12 years ago

Existing libraries around modern web frameworks sure do have a unicorn obsession.

__Joker• 12 years ago

If say I want to build a web application and new to Ruby, Python and Perl. But I want to use one of the RoR, Flask (or Django), Mojolicious. Which one should I go for. I.e. either one it had some advantage than other ? Rather, I know Python so I should go for Flask, argument.

ddorian43• 12 years ago

I think your argument is enough.

tmaly• 12 years ago

In the Perl realm I chose Mojolicious because it has very little dependencies. It does not come with an ORM or a built in user login. If you wanted that, Catalyst is a better way to go. The Mojo Lite aspect of Mojolicious makes it really easy to get a prototype up and running.

ChikkaChiChi• 12 years ago

I feel that it's more important to learn the fundamentals of the base language than it is to focus on any one particular framework. Virtually any web application of any measurable complexity is going to lead you into writing code outside the DSL that a framework might encumber you with.

fibo2• 12 years ago

Mojolicious is best Perl web micro framework, remember that the Author also started catalyst. Dancer is similar but I don't like dsl. Mojo is very fast, powerful and expressive with a lor of features, mature and more perlish. Try Mojolicious::Lite, there is no other web Framework that can write an app in a single,file.

william20111• 12 years ago

flask can?

matthewmacleod• 12 years ago

Flask, Sinatra, Rails, Express… actually, there are a lot of them.

grimgrin2• 12 years ago

Even Django!

https://github.com/readevalprint/mini-django/blob/master/min...

codygman• 12 years ago

Scotty/blaze for Haskell as well.

nicomen• 12 years ago

A single file? Bah that's too complex!

  $ perl -Mojo -lE 'a("/foo", { text => "lol" })->start' get /foo
  lol

For more fun: http://mojolicio.us/perldoc/ojo

chawk• 12 years ago

People still use Perl?

wschroed2• 12 years ago

Yes. And I am looking for Perl programmers right now:

  http://www.reddit.com/r/stljobs/comments/2a9940/seeking_software_developer_for_the_genome/

It gets the job done, is an easy language for people to get into, has enough flexibility to adapt to a huge number of programming patterns, and has a large and active community. We write real applications with it that help scientists find cures for diseases.

collyw5• 12 years ago

Would there be any possibility of remote work from Europe? My current job is building / maintaining the LIMS system for a sequencing centre in Spain. I did that in Django, but I did years of Perl before hand.

masukomi• 12 years ago

Yes, and many more of us wish our employers would let us use it at work too.

n0body• 12 years ago

everyday, although I use Catalyst, not mojo, but it's still nice to see a Perl project on hacker news.

drone• 12 years ago

Yes, and in fact, we have an open position for someone who knows Mojolicious: https://angel.co/macrofab-inc/jobs/33566-ui-developer

moltar2• 12 years ago

Every day for 15 years now.

elb0w• 12 years ago

This is such a great project. I remember when it started back when I used to work in perl. The main devs on it are awesome. If I ever build anything in perl again that needs an webserver it would be this.

ThePhysicist2• 12 years ago

It's great to see such an awesome Perl project on HN, especially these days when most folks here write Python, Ruby and JS and love to make fun of those "nerdy old Perl hackers".

I mostly use Python these days myself but I'll never forget the sense of power that Perl gave me when I learned it back in the late 90s (prior to Perl I had programmed in Turbo Pascal and Basic). To most programming enthusiasts back then it was what Python is today: A great, easy-to-learn, fun language that let's you solve almost any problem with just a few lines of code, mostly thanks to a huge ecosystem of powerful libraries (CPAN). Granted, the object-orientation felt more like a hack than a normal language feature (because it was one), but all in all it's still a really great language and just as powerful as Python, JS or Ruby.

muraiki3• 12 years ago

If you haven't played with Perl lately, it's worth looking into Moose, an object system for Perl. It not only offers a much nicer syntax for making objects, but provides features like read-only accessors, roles, introspection, and even types! http://search.cpan.org/dist/Moose/lib/Moose/Manual.pod

I work with Perl professionally now after having spent most of my self-taught programming education using Python, and I've been pleasantly surprised with the language. I'm both coding new projects and working with a more than decade old code base, and I've found that Perl code is as good as the programmer.

Yes, like any decades old language it has its warts, but Perl 5 itself is still being developed and improved upon. For those who know another scripting language, the free book Modern Perl is a great place to start learning: http://modernperlbooks.com/books/modern_perl_2014/

lelf• 12 years ago

an object system for Perl. It not only offers a much nicer syntax for making objects, but provides features like read-only accessors, roles, introspection, and even types!

and even metaobject protocol

otterley2• 12 years ago

Moose is very clever, but all that cleverness has a cost.

One of the things I like about Perl is that it offers tremendous performance, in addition to having an actually-useful debugger.

Subroutine calls in Perl aren't free; in fact they have a significant performance penalty if overused. And that's exactly what Moose uses, in droves.

Making Perl act like Ruby will also make it as slow as Ruby, and as difficult to debug.

wdr1• 12 years ago

I've heard a lot of good things about Moose, the Modern Perl effort & so on. Enough that I periodically think about jumping back in the Perl waters. However, I always wonder if it's worth it, because Perl 6 is always "not far from release", so I figure I'll wait to check things out again.

Until the Perl community resolves the issues with Perl 6, the waters are too murky for a lot of otherwise would-be JAPHs.

sdegutis• 12 years ago

Slightly off-topic, but I can't help but commenting on your statement:

To most programming enthusiasts back then it was what Python is today: A great, easy-to-learn, fun language that let's you solve almost any problem with just a few lines of code

I've been a part of an awful lot of different programming communities over the years. And somehow each one has a different set of languages they know and favor and have learned in the past.

What's more, they seem to think this same experience more universal than not. I've heard whole groups of people who claim in three part harmony that they love [X], and don't know anyone who's ever used [Y].

Every time I see a comment or blog post or tweet that mentions "that [Z] language and/or tool that we all know and love", I can't help but wonder which gated community they're a part of. It's just automatic now. Kind of like how every time I hear Canon in D, I remember the Pachelbel rant on youtube.

sigil• 12 years ago

Granted, the object-orientation [in Perl] felt more like a hack than a normal language feature (because it was one)...

Perl's OOP is definitely a hack! But it's a clever and elegant hack, and younger languages can learn a lot from studying how an awk++ managed to evolve support for all these new programming paradigms, without being totally co-opted by the ones which turned out to be fads. (When these languages are Perl's age, will they have evolved as successfully?)

Take OOP support in Perl. Prior to that, Perl had references, which could point to other basic value types, and it had packages, which were namespaces in the symbol table. Only two small changes were necessary for OOP.

First, a new built-in function `bless` was added which marked a reference as associated with a certain package. Second, a new binary operator for dispatch was added, the familiar `->` from other languages. The dispatch operator looked up a package from the reference on the left hand side, looked up a symbol within that package given by the right hand side, and pushed the reference onto the front of the argument list in the subsequent function call. In the called function, the initial reference argument became the equivalent of `this`, by convention.

Modulo some discussion of @ISA, that's it. You now understand Perl's implementation of OOP.

The elegance of this approach finally hit home for me when building transparent RPC for Perl and other languages. On the client side, when you dispatch a function call on a "stub" object, you'd like to dispatch a real function call on a remote object. In Python, you have to worry about whether you're calling a "bound function" on the remote object, versus calling a static method of the remote object, versus calling a "free function" defined at module scope (how do you address these?), and so on. In Perl, these are all effectively the same thing because the dispatch operator is so simple, and there's no extra OOP structure baked into the language itself like there is with Python.

Disclaimer: I mostly write Python 2.x now, but things like the complicated object runtime and the general uselessness of lambdas strike me as places where the language has stumbled.

collyw5• 12 years ago

Perl OOP is a hack, but coming from university where they taught Java, suddenly it made the whole thing obvious and transparent (to me at least).

Inheritance was no longer a black box, but just a way of working out where to look for the method and execute it.

ThePhysicist2• 12 years ago

Great answer, thanks for explaining this! I'm curious about how much this approach differs from the one pursued by Javascript, which seems pretty similar to me.

59nadir• 12 years ago

... the general uselessness of lambdas ...

This sounds interesting. Why do you feel this way?

joeclark77• 12 years ago

I used to love Perl... it's been about 15 years, though. What a great excuse to learn it again!

vijayboyapati• 12 years ago

I've been developing with Perl for almost 20 years and am a great fan of it. I think it's not difficult to write easy to read and understand Perl code (although it's also not difficult to write awful Perl code). I'm very interested to learn more about Mojolicious. I've been using and really enjoying Perl Dancer, which from the example on the landing page of Mojolicious looks very similar. Could someone familiar with the two give me a summery of the differences and pros and cons between them?

sarciszewski3• 12 years ago

"curl get.mojolicio.us | sh"

Delicious! Let's pipe data retrieved over raw HTTP and pipe it directly to sh. It's like one of those Head-On commercials (remember those?) only with digital cyanide.

hadoukenio• 12 years ago

As opposed to blindly downloading a repo and running "make install"? What's the difference? If you really cared enough you would instead pipe it to a file to inspect first. But I don't think you inspect most packages you download from GitHub etc.

So again, what's the difference as opposed to convenience with the pipe?

andraganescu• 12 years ago

Well, which is it more probable to to go unnoticed: a hack of the install script you fetch via http or an entire github commit infesting the software while it still lets it work as designed so no contributor notices?

It is not a problem with mojolicious at all. Its a nice helper that should be carefully used.

qmaxquique• 12 years ago

You can test and develop Mojolicious in a terminal.com container. Check my snapshot at https://terminal.com/tiny/8TRpbtVffh

Mojolicious – Perl real-time web framework

Related Stories