So I was reading zby's latest blog post on frameworks and libraries. On some level I agree with him that often times frameworks are basically just codified "convention", but I really don't see this as a bad thing, and here is why.
As I see it, the purpose of a library is to provide generic re-usable code that can be used in many different contexts. The purpose of a framework is to provide a set of guidelines/conventions/best-practices which a developer can then build upon, therefore avoiding the need to set those guidelines/dictate those conventions/determine those best practices themselves.
Some frameworks are more opinionated and complex (RoR, Catalyst, etc) and push/force you into their way of thinking, the benefit being that they also provide you with lots of building blocks that often times are zero-conf. While others (Dancer, Web::Simple, Mojolicious::Lite, etc) are more focused and purposefully simple, they leave many problems unsolved therefore allowing more freedom for the developer. Each of these approaches has merit and neither is truly superior in all contexts, which brings me to Plack and why I think this explosion of "frameworks" is a really good thing.
The ubiquity of Plack means that all these frameworks can be (fairly) easily used within the same application (or set of applications). It should (eventually) be very easy to have your Catalyst application running next to your Dancer application, running next to your WebNano application, all sharing the same session data, user information, etc. through Plack::Middleware components and mounted under a single Plack::App::URLMap and controlled easily using plackup.
Couldn't agree more on that. Libraries are tools and engines, Frameworks are vehicles.
ReplyDeleteI would not say that the 'explosion of frameworks' is a bad thing - I think it is necessary. It is the only way to test where are the boundaries between the components and what should be packed together and what can be split apart.
ReplyDeleteThe interesting question here is what is a framework - certainly the definition is fuzzy - and things can be more or less 'frameworky'. Dancer and Web::Simple are mostly just dispatchers - are they frameworks or maybe they are already libraries? I agree on your definition of libraries: "generic re-usable code that can be used in many different contexts" - but I propose another definition of framework: "a framework is a library that has a big interface". The conventions you mentions are usually not defined otherwise then by the interface and it is that interface that is forcing programmers to adhere to 'a convention'.
The purpose of a framework is to provide a set of guidelines/conventions/best-practices which a developer can then build upon, therefore avoiding the need to set those guidelines/dictate those conventions/determine those best practices themselves.
ReplyDelete-- Very Well Spoken (err, Typed)
@zby: I think it is a mistake to look at frameworks as a "library that has a big interface". A library is something you embed inside your application, a framework is the inverse, it is something that you embed your application within.
ReplyDeleteI pulled out this book on framework building recently (it is an okay book, a little dry and heavy on team politics, but it does have a lot of valuable information). On the back cover, it defines frameworks as "cooperating classes that make up a reusable design that addresses a specific application domain". I think most web frameworks fit into this definition, the more opinionated frameworks simply define more of the "design".
As for the question of Dancer and Web::Simple perhaps really being dispatcher libraries, I disagree because they provide more then just dispatching. They provide a complete foundation upon which to structure the web elements of your application, beyond that they basically just don't have no opinion.
What you say here is pretty close to the popular 'you call a library, but a framework calls you', which is concrete, precise and succinct - but rather too broad. There are libs that use the template pattern that are too small to be called framework. Or maybe not? What do you think about that definition? It is more precise than 'you embed your application within a framework'. By the way - is it always application that you embed into the framework?
ReplyDeleteSorry - only questions this time.
@zby: I never said it was always clean and simple. To answer your questions.
ReplyDelete- re: something that implements a "design pattern"
I think this blurs the line between framework and library. It is not big enough to be a useful framework, but it is not structured the same as your normal library. Its a Frambrary or a Libwork, you choose.
- re: do you always embed an appliction in a framework
Yeah, most likely, what else would you embed in it?
>all
ReplyDeleteHow do you think about new micro framework "Piglet"
http://github.com/miyagawa/Piglet