Perl is more viable for web development than ever!
Today on StackOverflow, an old thread popped up that prompted me to answer. That answer became a slightly longer compendium of recent developments in Perl and Perl-for-web.
I will copy the text here, but I am asking you to vote it up so that it will show for future viewers. So that I will not be getting undue points, I have made it community wiki (also means you can amend if you want).
Vote here: http://stackoverflow.com/a/8828209/468327
== Post Content ==
This is an old question, but I thought I should update the readers. I am happy to report that in my opinion Perl is more viable for web development than ever! Along with old friends Catalyst and (recently revamped) Mason, there are some great new entries Mojolicious (or visit mojolicio.us) and Dancer. I’m sure there are others too.
Perhaps the biggest improvement is PSGI/Plack (or visit http://plackperl.org/).
PSGI is an interface between Perl web applications and web servers, and Plack is a Perl module and toolkit that contains PSGI middleware, helpers and adapters to web servers.
With these improvements have come more cloud hosting platforms: for a couple examples read more here.
Perl itself is experiencing a renaissance of sorts. Between Moose object framework (and lighter clones like Mouse) and the ideals of the Modern Perl movement (readability while using modern best practices), Perl seems to be growing and its users are excited and motivated.
Personally I have been enjoying Mojolicious. I like its built-in servers and templating engine. I also like that you can make a Mojolicious::Lite application in a single file! That said I really haven’t played with Dancer or other frameworks, so if you are coming back to Perl or new to Perl, I would encourage you to take a look at those too.
In closing Perl-for-web has come a long way since CGI.pm. If you’ve been away for a while, its worth another look.
As I delve into the deeper Perl magic I like to share what I can.
Sadly with Mojo you’re encouraging the use of something that represents the anti-CPAN. :(
vs. Catalyst, the “all of CPAN”? ;-)
I thought that slap-fight was over.
Whatever their initial reasons for doing so, the Mojo team has built useful subsystems for Mojo, with modern features, and they are available on CPAN if you want to use them. Just because they chose not to use existing modules doesn’t mean that they are anti-CPAN.
After a brief discussion about this brian d foy, I now agree with him. In reinventing these wheels they have made modern alternatives to the old standards. This is not a problem.
After a little searching here is the comment thread between me and brian:
[Question about reading input from STDIN after a prompt]
Petrov: Probably it will be better to use Term::Prompt or IO::Prompt. Don’t reinvent the wheel :)
bdfoy: No, reinvent the wheel when you are learning. Really. You’ll never learn to program if you don’t do it yourself a couple of times. :)
jb: I agree, at least for the small things like prompts. Of course you don’t want someone reimplementing an XML parser of LWP or DBI etc.
bdfoy: Yes, I want someone reinventing LWP. I’ve been using Mojolicious for everything I used to use LWP for, and it’s much easier to work with and extend. If Sebastian never reinvented it, I wouldn’t have gotten something better. I wish someone would reinvent the XML parser.
Dancer can also be a single file. In fact, the default in exporting Dancer is to provide an internal webserver for single file applications. This is compatible with the original purpose of Dancer, which is porting Ruby’s Sinatra (which does the same thing).
If you’ll check structured Dancer code, you’ll see it’s export as “use Dancer ‘:syntax’” which means “hey, I just want the syntax, not the internal webserver”.
Good job. :)
Thanks SawyerX, I’ve added your comments to the SO post (feel free to amend, while keeping it concise). I tried my best to post without being partisan; I really just haven’t had time to try out all the frameworks.
Maybe someone should tell these guys: http://www.makeuseof.com/tag/programming-language-learn-web-programming/ or even these guys to stop using CGI.pm in their examples http://www.ibm.com/developerworks/aix/library/au-perlweb_revision/index.html
What would be great (although I don’t think I would be the best person to do this ) is a “Why you should consider Perl for your next (web) project” - Here in Chile there is a program called Startup Chile, attracting tech start-ups to Chile. One of the things I noticed is that on their jobs page, they have had the same job postings for PHP and Ruby programmers for months now.
I’m interested in this. Could you point these out or maybe even make a blog post about them, detailing how they improved on the old standards?
Off the top of my head, Mojolicious has a UserAgent and DOM parser (and assoiated testing packages) which allow HTML5, CSS3 (with selectors), websockets, built-in JSON etc. Read more at Mojolicious::Guides::Cookbook#USER_AGENT.
Again, I’m not saying that LWP is inferior, I am just saying that Mojolicious provides an alternative. Though they chose not to reuse available CPAN modules, Mojolcious IS available on CPAN. Therefore it is not anti-CPAN.
Now I ask you, why is your tone so against the Mojolicious guys and/or their work? We all love CPAN here.
After having a very productive conversation with Mithaldu on IRC, his problem boils down to interoperability of modules used in Mojolicious. His specific example was wanting to be able to use JSON::XS rather than Mojo::JSON. I can see his point, however I understand Kraih’s concept too. Perhaps the lesson to learn here is “try to allow for flexibility in your module’s dependencies if possible”, and I will make no further comment on the issue or Mojolicious’ design goals (since I am not the one to do it).
I very much agree that the new simple frameworks such as Dancer and DBIx::Class are really giving Perl a renaissance.
I am very impressed with Dancer.