Mojolicious 2.0: Modern Perl For the Web 132
Kvorg writes "After a year of rapid development, newly released version 2.0 of Mojolicious, the new generation real-time Perl web framework written by Sebastian Riedel and many others, offers a versatile and elegant web framework that is as good at web scraping and simple scripts as it is at building complex, interactive real-time applications with HTML5 and websockets. It supports easy 0-dependency installs, excellent developer mode, multiple deployment scenarios, many CPAN modules and plugins."
Oh boy (Score:3, Insightful)
Another perl web framework. I can't wait. I'm champing at the bit. /yawn
I use perl all the time, and have yet to run into a framework that actually saves time overall. They're generally designed by Unix guys who really don't want to think about web design any more than they have to - and it shows.
Useful for just certain applications (Score:4, Insightful)
I suppose the idea is neat, but I personally don't have any particular applications where I need Perl to actually be the whole webserver for me. The things that do come to mind would involve a small system where there is no webserver installed, but going on port 80 would mean running the script with higher privileges and the whole mess of Perl and everything need to be jailed. Or maybe to try one of those utilities I heard about to pass privileged ports to an app, but I haven't had experience with those.
To be honest, frameworks left kind of a bad taste in my mouth when a language such as Ruby that had been around for years suddenly exploded when Ruby on Rails showed up. Everybody and their brother thought it was the new hip thing to use, until a lot of the bigger websites which had deployed it started to actually dump it due to limitations. Nobody wanted to take the time to write good code to start with, and it bit them in the butt.
Using frameworks (whether it's .NET or on the web or otherwise) usually starts out as a means to set up a new project quickly, but the problem is that they end up being an excuse to make sloppy bloated coat for the final product. Perl was always fast and efficient; people should learn to develop in it that way.
Re:Yet Another (Score:4, Insightful)
Because clearly what we need is _yet another_ way to develop web applications.
Frankly, yes. As long as we're advancing and improving, yeah, it always makes sense to keep trying new approaches. I'm using Mojolicious for two apps currently in development. One of them was already in progress using other modules, bit with the Mojolicious::Lite module, I was able to cut my code base nearly in half.
I'll tell you what - why don't.you try it first, then complain about it if you still don't like it.
Re:"Web development can be fun again" (Score:4, Insightful)
I don't really get the desire to use Perl. I haven't touched Perl for a long time and can't think of any jobs where it would be the best tool. It's ugly.
It's still _the_ tool for quick one-off type stuff. I know of no other tool that lets you just mash data together and produce something useful as easily and quickly as perl. That said, I'd never use it for a serious application or anything that had to be maintained for more than a few weeks. Those days are gone.. maintainability and reliability are king.
Re:Wasn't that supposed to be Ruby? (Score:4, Insightful)
You can write 'Modern Perl' in the sense used here without switching to an entirely different language:
http://www.onyxneon.com/books/modern_perl/index.html [onyxneon.com]
Assumptions (Score:5, Insightful)
If you understand your comment and know how to write perl, you don't really need to understand how a cryptic line does something - it's faster to rewrite it from scratch to do what you want.
That assumes that the comment correctly describes what the code intends to do. This is a very big assumption to make and I've worked on numerous projects where the comments were significantly different from what the code did. Looking through the change logs, this situation always arises because someone updated the code but didn't bother to update the comments.
This brings me to my point: The code doesn't lie.
If you can't understand a piece of code, you're going to be working off assumptions. Refactoring code based on assumptions is dangerous unless you have very rigorous unit tests. I've found that the level of code obfuscation is negatively correlated with the quality (or even presence!) of unit tests. YMMV.