Ask HN: Web Frameworks for Perl | Hacker News Reader

Ask HN: Web Frameworks for Perl

29 pointsaneesh29 comments

Have any of you Perl programmers out there used Catalyst as a framework? What do you like and dislike about it? Any other frameworks you would recommend?

Most of the Perl programming I've done has just been gluing together modules like CGI and DBI on my own. I've thought about using a formal framework, and Catalyst seems to be the Perl framework of choice.

View on HN

I've really enjoyed Catalyst when working with it in the past. I used it extensively at my previous job, and for a few personal projects.

I really like the extensibility of Catalyst. It's a very Perlish framework. It's not opinionated. There are many ways to do things, and if something doesn't work how you want it to, you can easily write a module to do it yourself. It's designed to be an extensible framework, instead of all-in-one, as many others are. For example, it was trivial to get all the appropriate ORM magic working with my existing databases with DBIx::Class. Catalyst really does keep models, views, and controllers separate. In many other frameworks I've looked at, there are things as absurd as requirements on how your DB tables are named.

Another amazing web framework for Perl that doesn't get much media attention is Jifty. Jifty is absurdly powerful and has scary dark magic, but it's negligibly documented. Jifty is really my choice for all-in-one perl web framework. It does everything for you, and then some. One feature that impressed me is that you can describe your dynamic actions in perl code, and Jifty will automatically fall back to loading a new page with the modification if your browser doesn't support javascript, but will do inplace dynamic updates if you do. Graceful degradation built in. I can competently use all of my Jifty apps from elinks or my old treo. It's still rather opinionated, though.

Catalyst is certainly numero uno in the Perl web framework world. Here's a list from the Perl5 wiki... http://www.perlfoundation.org/perl5/index.cgi?web_frameworks

Don't think u can go wrong with any of the established ones on that list. However two new kids on the block thats worth casting your eyes over are Squatting (http://search.cpan.org/dist/Squatting/) and Mojolicious (http://mojolicious.org/).

I'm currently enjoying using/playing with Squatting. Its a Microframework (inspired by Camping by _why) and you may find it a good first step from CGI apps.

/I3az/

I haven't seen Mason (http://www.masonhq.com/) mentioned yet. I was hoping someone else would mention it because I don't feel I can properly represent it. I only played around with it; nothing substantial. But I liked it (for what that's worth).

You'll see some names here of sites that use it that you'll recognize: http://www.masonhq.com/?MasonPoweredSites (Amazon.com being one of the most notable).

And of course you can use Mason with Catalyst: http://search.cpan.org/perldoc?Catalyst::View::Mason

In this scope it's just another view like http://search.cpan.org/perldoc?Catalyst::View::TT , http://search.cpan.org/perldoc?Catalyst::View::XSLT or others http://search.cpan.org/search?query=Catalyst::View::

Mason is a really excellent templating system. I can't recommend it highly enough for that purpose.

(It is also handy for abstracting away mod_perl2, CGI, and FastCGI with a uniform interface.)

I used this, although it was many moons ago when I was a junior developer. It was easy to grok from a development perspective, but I've not had to manage an installation.

Recent post on this I bookrmarked: http://perlbuzz.com/2008/11/the-evolution-of-perl-frameworks...

Personally, I also glue together CGI, DBI, etc., and I have no desire to use a framework. Why do you? Is something in particular cumbersome?

I'm developing a data analysis & visualization tool. I'm starting to really wish there was a nice way to separate out the math/statistical logic that I'm using on the backend from the logic I use to display the results in a pretty way.

Catalyst is an ideal candidate for you for this. The Controller and View code is very much separated from the Model code that you want, and agnostic to the framework code. I'm writing some text mining stuff at the moment, and Catalyst is what I'm using to keep web application logic and problem-domain logic well separated from each other. This (hopefully) makes everything much more maintainable.

Why don't you either a) put all the math stuff in its own set of modules and/or b) have your backend do all the analysis and store it in a middle layer (e.g. DB) for the front end visualization?

Ruh, are you asking what the advantage of something like Rails offers?

Ruh?

Well, with perl to a certain extent the frameworks are really a bunch of separate libraries packaged up together. You CAN use CGI and pick your libraries for form validation, AJAX tricks, templating, authentication and session management, and such. But why bother? It all comes canned with a framework.

I've used Catalyst in the past, now at work I am stuck with CGI::Application and it seems rather OK, but still a little step back. At least in Catalyst it is natural to have multiple classes (each for one controller) - while the app being developed here ended up as one huge application class.

But really the more imporatant part of the decision is what templating and ORM to use. I have a blog post on that: http://perlalchemy.blogspot.com/2008/10/progress.html .

From my (admitedly limited) web frameworks experience (django, grails and catayst), catalyst indeed shines by the extreme level of freedom in the choice it leaves up to you. If you're willing to invest the time necessary, it is indeed a great way to get separation of concerns without commiting to a specific way of programming your webapps. If you're used to glueing together modules in your apps, you should fit right in.

Sites using Catalyst: http://www.catalystsites.org/sites/all and http://dev.catalyst.perl.org/wiki/SitesRunningCatalyst

All of our recent projects use Catalyst (commercial and personal). The best thing is that it prevents us to repeat each and every simple functionality that we previously had to write with CGI or CGI::Simple. We can totally concentrate on the actual work we want to do without spending much time on groundwork.

From time to time we factor out common code into modules on top of Catalyst. Everything else is just application code.

Catalyst is super nice for fast development and/or prototyping of web applications and has all the flexibility you need.

It's probably not even considered a framework, but I had done a lot of web programming a while ago and I loved the Template Toolkit http://template-toolkit.org/

I don't use Perl but one of my favorite sites (jisho.org) use Catalyst.

Yeah, I don't use much Perl, but the only not-legacy framework I ever hear about for Perl is Catalyst (http://www.catalystframework.org/)

Slashcode uses http://www.slashcode.com/docs/INSTALL.html#requirements

Catalyst and CGI::Application (or Titanium) are pretty much where it's at with perl web development. CGI.pm is a relic at this point. There are better, smaller, faster core CGI modules if that's all you want. Likewise, consider using a more modern wrapper like SQL::Abstract rather than straight-up DBI.

Catalyst has a somewhat steep learning curve and perhaps invites you to waste time evaluating alternative modules for functionality. It's not "opinionated" and you can choose very different subsystems to get the same job done. The upside is that Catalyst is probably the most powerful web framework out there. DBIx::Class is the most feature-full ORM out there, for one point (trounces ActiveRecord).

Titanium is much, much simpler and has the advantages that entails. You'll be up and running with Titanium in a day. It's a better option for the rare/occasional web app developer (like me).

Agreed, Titanium seems really useful. It bundles a lot of the modules that I usually use with CGI::Application and is logically put together.

I have about 12 years of Perl CGI stuff for different projects (most of which is still running) but I started to feel geek envy a few years ago when the world decided that you were not cool without AJAX. I looked into Java EE and realized I just was not an "enterprise" person and then at the different PHP frameworks before doing by first Rails app using Hobo. I have to say that was remarkably fun and easy to put together but I'm still not completely happy about having to run a cluster of mongrels and having to coordinate them with Apache. (That might not be the cool way to deploy Rails apps now, mea culpa.)

CGI::Appplication and Titanium (including modules like HTML::Template and HTML::FillInForm) are simple to use, work with all of the authentication stuff that I interface with, and scale perfectly for the number of users that I typically have.

concur: catalyst gets the job done.

I'm using a homebrew haskell framework now, happs with StringTemplate for the view.

if you're looking to do any perl development, use: strawberry perl and perl moose.

http://strawberryperl.com/ http://search.cpan.org/~drolsky/Moose-0.61/lib/Moose.pm

forget catalyst at least for a little while. perl moose makes oop perl a little bit easier, however it should go without saying; understand perl oop first.

http://www.p3rl.org/OOP

if you're using perl cgi and dbi, these are two the best modules written i think. lots to learn in there, keep looking.

The topic is about web frameworks, not how to build your own or what techniques are hip and trendy.

> forget catalyst at least for a little while

Uh, why?

> using perl cgi and dbi, these are two the best modules written i think

No. CGI.pm is universally regarded as bloated.

Oh why, b/c obviously as someone mentioned before it has a steep learning curve. Who cares about the "bloat" or whatever you think is wrong with it. my $p = CGI->new is elegantly simple whatever method you're calling. it's opinion dur!

CGI::Simple

Reply on news.ycombinator.com