It seems that the season is open and everyone is writing his new web framework again (all authors of the dozens of other recently created Perl web framework - please accept my apologies - I could not possibly link to all of your babies). If you ask me why is that? My answer is: it is easy now. We have libraries that do nearly everything that the traditional web frameworks provide. You don't need to write much - you just saw together the available patches and voila: your own web framework. You can be proud.
For some time I was thinking: OK, so now we have that cambrian explosion of new frameworks, that's OK, it will all settle down, people will select the best of them and the rest will die off. All we need to do is waiting. We could also speed it up a bit and make it a bit more smooth and rational by learning how to evaluate the frameworks. To do that we need to talk about them, study their functions and compare designs, project goals, project management styles and all of that. This will not be easy, but once we get past the awsome depth of common analyses of the 'this sucks' style and start to think about 'this is good for that and that other thing is better if you need something else', the rest will be incremental.
And I still believe that we need to talk more about design solutions and expand our vocabulary and use less of 'this is stupid' authoritative evaluations. This is something beneficial in any circumstances. But now I also think that since we have the libraries that do the all the work that previously was done by frameworks - then why should we build any more frameworks? Frameworks are coupling, they tie together the libraries that do the actual work and send that loose, uncohesive package to the programmer, who he has no choice, but has to use all of it and in the way prescribed by the framework. But every educated programmer knows that coupling is bad and cohesion is good. So why don't we just use the available nicely decoupled and internally cohesive libraries instead? Yeah, the libraries don't yet do all the 100% of stuff traditionally provided by frameworks, they can do 80% or even 90% of it but not yet the whole 100%, it is still ahead of us to extract the other 10% of functionality from the existing frameworks and turn it into a nicely decoupled and internally cohesive libraries.
Historically the trend is clear - the first frameworks did everything, the MVC frameworks included all Model, View and Controller components, then came Catalyst which is mostly just the Controller part. But that was not the end of decoupling - the Controller part still can be broken down further. And it was, with libraries like HTML::Engine budding off it, splitting and heading for an independent CPAN life. Now it is time to have a look at Catalyst and other frameworks and think what are the exclusive features that it provides that are not yet available as independent CPAN libraries. We have Plack, that provides all the abstraction needed for easy deployment and testing, we have packages like Bread::Board that provide a generic way of initialising application components, and I am sure there are also other interesting libraries at CPAN that provide other parts of the framework functionality. So what is left?
Maybe I am missing something, but the only important functionality of Catalyst that I cannot find any generic libs for is dispatching - selecting the subroutine (or method) that will handle a given HTTP request. I don't see any reasons why this should be hard to do. In fact I have already started working on that. OK - to be frank, what I started to work on was another web framework. I decided that I would like to have a mini framework and started coding it. Only now, after having the first CRUD example written in it, I can see that all I wrote is just a dispatch system, the other parts are freely available at CPAN. I can use Plack for the web engine abstraction and Plack::Test for testing, I can use Bread::Board for application components creation and Moose as the object framework - no need to reinvent the wheel.
Monday, February 01, 2010
Subscribe to:
Post Comments (Atom)
9 comments:
Path::Router
Path::Dispatcher
HTTPx::Dispatcher
there are probably more.
First of all, thanks for calling me "everyone", that's a sweet way to quote someone's work.
To speak about Dancer, it is a port of Ruby's Sinatra, so I guess if you're right, Sinatra does not deserve its place in the Ruby ecosystem neither...
You may want to take a closer look at the so-called "frameworks" and try to understand why there are so many people behind them nowdays.
"Everyone" salutes you.
@asukrieh - I did not think someone could be offended by that word, but OK - I changed the text of the link to Dancer to 'web framework'. No problem.
As to your advice to take a closer look - how can you know that I did not? Or is it just rhetorical device?
@Hans Dieter Pearcey: Thanks! Hmm, I guess that proves I did not look really deeply :)
Because you sound like advocating to avoid using Dancer (and such alike frameworks).
By reading your post, I understand that those frameworks are useless, because you can do what they do by hand, with CPAN modules.
Hence my advice to look at Dancer and see what issue the framework addresses: small webapps, easily written with clear syntax. This is a field that *has* an audience.
If I understood you wrong, my apologies.
But my point is that if those framework exist today, that's because there are people out there who cares about what they do.
It's not just about putting some glue between different CPAN modules, it's a bit more than that.
My point really is that *all things equal* it is better to have a library than a framework, because framework means coupling, but of course there aren't *all things equal* - there are things that currently frameworks do better, I don't deny this. But we've seen things that used to be done in frameworks, but now have migrated into independent libraries - so maybe there are more of them there? And what would really be left if we split all of these into separate libraries? I cannot pretend to know the answer here.
I think there is a place for both approaches. Sinatra's existence in the ruby world doesn't mean the death of Rack-based applications, and there are other URIs dispatchers available as libraries ; with no string attached.
The same thing seems to be happening in the "server-javascript" world. Just have a look at node-js' wiki, there's a healthy list of micro-frameworks there too. :)
Transpose that to the perl world: with the "recent" momentum built around Plack, I don't think having small(-ish?) web frameworks would prevent one to write his own tools, or reform the existing ones. Just be patient: Catalyst has come a long road, but it took some time to grow up too.
I started responding here, but it got too long so I actually posted my response as a blog post here
I'm excited by this post. I'm hopeful that some day there'll be an honest comparison of all the choices in perl. I keep looking at all the things I like and messing around for a while and then just using CGI::App because I can't seem to pull the trigger and pick something.
Mojolicious seems like the way to go to me, but I really have no way to compare them.
Post a Comment