I'm strongly in favour of this, because we need something to offer beginners as a guideline, simply because we are blessed with a wide range of alternatives.
I'd love to see this. The are a lot of web frameworks for Perl and this would give them some exposure and help people make the difficult decision of which one to use.
There was another new framework I read about recently that looked interesting. Heavily based on Plack, it had a short name but unfortunately I forgot to bookmark it.
This is concerning - I question whether it would cause more dissension and spread misinformation rather than help.
Nothing against Neil, but his previous reviews have been focused on comparisons instead of highlighting what each framework has focused on, and why they chose the paths they did.
For example, a great amount of time would have to be spent working with the real-time features of Mojolicious to give an accurate review, whereas some of the other frameworks haven't chosen that direction at all - a completely different application would have to be written for each framework to properly highlight what it can do.
Alex: I guess you were thinking about Kelp (bare-bones Plack-based nanoframework).
I´d prefer the revised list of contenders (Dancer v2 instead of Dancer; including OX; cf. http://neilb.org/2013/05/01/starting-web-review.html ).
Also, instead of the example app described above, how about using the same app as used in this series of articles: http://net.tutsplus.com/tutorials/html-css-techniques/build-a-twitter-clone-from-scratch-the-design/
It would give people familiar with any of those technologies a better access to the Perl implementations. And you might be able to make some extra money by submitting a guest article to tutsplus (which should generate even more interest from people outside the Perl community).
However, given the complexity of the frameworks, I wonder how meaningful the results would really be.
On the other hand - if one community of one framework criticizes your implementation as inadequate that might simply mean they didn´t do a good enough job of documenting the best way to utilize their framework. Which in itself may be a valuable outcome of this grant.
Yeah that really hits a sweet spot, I like this idea to have a reference implementation of this in all frameworks. Probably even "different approaches" to see also the flexibility options of the framework.
Good point Torsten, about illustrating different approaches, where a framework supports / enables / facilitates more than one.
Hopefully the review wouldn't cause dissension: I work quite hard to try and ensure that my reviews are respectful. And if I've misrepresented something I'll always correct it.
Unavoidably my reviews always have some aspect of "what are these modules like for doing X, Y, or Z", as typically they've grown out of me trying to satisfy a need of my own. This review is no different: I want to start a new project and develop with a framework, but couldn't find any comparison of all the relevant perl frameworks. For my personal use I'd probably just check out the main contenders, but submitted this proposal as I think it would be good if all frameworks are included to some level.
Realistically a review such as I'm proposing is likely to give more of "what it's like as an early developer" with each framework. Where I get comments from other users, I include those, and as noted in my submission, I really hope to get such input on all, or at least the major, frameworks.
I continue to maintain the reviews, adding new modules, and what growing experience with (some of them) that I may have. I expect the same to be true with this review, should I do it.
As noted by hjansen above, I'm keeping a list of the current contenders on my blog.
I'd love to see this proposal funded. Neil always writes such thorough and objective reviews. Reviewing the plethora of web frameworks is a big task that is very worthy of a grant.
The side-by-side implementations of the same app with different frameworks will be extremely helpful to those who are shopping for web frameworks, and will really showcase all the awesome tools that Perl has for web developers.
tempire: It is probably impossible to do full justice to *all* the features of *all* the frameworks. But I'm sure Neil would be happy to work with the framework authors to avoid misrepresentation and ensure that factual information is true. At the same time, I think Neil is entitled to include his opinions and observations as well.
While I like reading reviews, I'm not sure I'd pay for somebody to do this. I recently made my own comparison apps of Mojo, Dancer, Kelp, and two of my own internal project frameworks running on Apache CGI, Apache ModPerl, dev daemons (bundled with the frameworks), PSGI default,Starman and Starlet. In addition to my own interests, there are other items out there
I was doing this out of curiosity (and to selfishly make sure that my own frameworks were at or faster than the current market trends - yes they will be available on CPAN as yet another framework).
Which brings up the same question that others have - framework selection - how do we get all of the other frameworks in there too.
I think a better project would be a open authenticated (via CPAN credentials) web database of problem specfications (which can have new entries added), and then their solutions- which is almost what you have said, except that any framework author can add/update their working solutions. I think it would be fine if you seeded it with the items you specified, but I am certain that the framework authors will have optimizations and comments to add (so let them).
Essentially this gamifies the problem (make framework authors improve their frameworks) rather than documents the state of things at only one point in the year 2013.