Introductory waffle
So, I've been floating this idea for ages of basically having a thing called the mstpan which is basically my opinionated version of Task::Kensho so I have a short thing to refer people to when I get asked questions about suggestions. Then I noticed people are doing these advent calendar things, and thought I'd try and combine the two.
Nota Bene: I have 24 of these planned. I hope to manage one a day. I'm going to finish all of them even if I don't do so quite on time.
Nota Bene: This is opinionated. Your mileage may vary. No warranty, express or implied.
So, without further ado:
mstpan 1 - Web Frameworks
CGI
Are you fscking kidding me? The protocol is still perfectly reasonable. Don't talk to me about the perl module. Not unless you're buying me enough beer to forget about it again afterwards.
Catalyst
The old man on the mountain. Wise, wrinkled and uphill to get to.
If you're planning on building a large scale line of business app that's going to exist for multiple years, seriously consider Catalyst.
The ecosystem is bigger than pretty much everything else, though that's at least in part because it's been around longer than everything else.
This also means the ecosystem has more outdated horrible crap than everything else.
Stability is a watch word, backwards compatibility incredibly important to Catalyst. Which also means it's carrying around more legacy cruft than frameworks that don't make that commitment. Tradeoffs.
Moose from the ground up. Expect your server to take several seconds minimum to start. On the other hand, you can compose together functionality with superclasses and roles in ridiculously powerful ways that nothing else will support.
Dispatch is built into the controllers, by default. Makes for very confused newbies but also allows you to re-use chunks of URL space in neat ways.
If Catalyst looks like overkill to you ... don't use it. Wait a couple of years, and look at it again; that should give you enough extra experience to realise why all the features exist, and to love or hate how they're designed on their own merits.
Dancer
Started off as a shameless clone of ruby's Sinatra. Then suddenly it escaped and had users. This is usually the first hint you did something right.
Focuses on simplicity and accessibility uber alles, so an ideal choice if you're focused on whipuptitude over manipulexity. Heavily DSL based so that you can almost entirely ignore that it's OO under the hood, which makes bringing programmers used to transaction script style web development up to speed much easier.
Dancer2 is a solid attempt at redoing the internals, in order to fix all the things that only became obviously a bad idea after the original had escaped and suddenly had too many users to break.
The ecosystem is pretty big, although many plugins are trivial wrappers around existing CPAN modules and it's often worth considering just using the module directly - it's all still just perl, you're totally allowed.
Dancer uses hand-rolled OO, Dancer2 uses Moo - so you're in nicely lightweight territory and can still potentially end up with a pure perl (i.e. no XS module) deployment if you're careful.
If Dancer looks like a toy to you ... I don't care. It's not necessarily my personal choice to use, but I've had good results getting people stuck on CGI/CGI::Application level things because everything else seemed far too complicated to level up their ability in the process of learning Dancer. Don't knock it.
Mojolicious
Designed by the same evil genius who originally invented Catalyst, Mojolicious is an uber shiny, all in one system that offers you access to the bleeding edge like nothing else in the space.
Their focus is absolutely on providing a unified set of components that all play nice together, to provide a system that's consistent and elegant within itself albeit at the cost of not always doing things the way the rest of CPAN does. Mojolicious moves fast, which does mean occasionally breaking stuff, but their backwards compatibility and deprecation policy is thoroughly documented and entirely necessary to achieve their goals.
The ecosystem is reasonable large but widely variable; many of the plugin authors seem to confuse Mojolicious having provided a unified, integrated set of wheels with a license to reinvent rather than re-use ... but that's ok, you can always just use the existing CPAN module for something instead if you like it better.
Mojo provides its own minimalist OO, its own async system so it can have integrated native websocket support, and all sorts of other neat bits that mean it'll be quite a while before you have to reach outside core for most things.
If Mojolicious looks like gratuitous reinvention of wheels to you ... then maybe it isn't your thing, but I'd strongly invite you to try and understand why each wheel was reinvented because even if it doesn't change your opinion you'll almost certainly come away with several good idea that you'll want to steal.
Web::Simple
I wrote this, some years back, in order to give me something that was minimalist in the way that scheme is minimalist, and that integrated with the Plack/PSGI ecosystem while fatpacking nicely. If you like being handed a bag of orthogonal components from which to build your own structure, you may like it. If you want a predefined structure to work within, you're going to hate it.
There isn't really an ecosystem as such, because Web::Simple natively supports embedding any other Plack/PSGI app as something to dispatch to, along with allowing Plack middlewares to be applied to part of the dispatch system - e.g. the common way to do RESTish stuff is to embed Web::Machine instances in a Web::Simple dispatch system.
If "I want insanely flexible URL dispatch in something light weight enough to run reasonably as a CGI script" appeals to you, it's worth a look. If you like bolting things together yourself and figuring out an appropriate structure for your specific application appeals to you, it's worth a look.
If Web::Simple looks like it barely even counts as a framework ... file it under un-framework and move on. I wrote it to fill a niche that nothing else seemed to, and I won't be upset if it stays in that niche forever.
Plack
Plack is not a framework. Plack is a toolkit for building frameworks. Plack is a toolkit for deploying frameworks. Plack is not a framework. Plack was never designed to be a framework. You can try and use Plack as a framework but I would recommend in the strongest terms that you don't because that's not what it's for and not where it shines.
Plack is, however, absolutely awesome at what it is for. I'll discuss some of that in mstpan 2.
Codex
No, that's not a module name. I just couldn't think of a better final sub heading.
Here endeth the first one. I'm sure there'll be people annoyed I left out whatever their favourite thing is. Either I didn't know about it, I don't like it enough to even hate it, or it seems to me like one of the above already handles the cases it was designed for better. Or I'm going senile. Or all of the above.
Next time: Web Deployment.
-- mst, out.