> So really this isn't a question of the software, but of the developer's capability to perceive (or not) that software.
It is quite telling of HN's audience if they honestly think that "every sufficiently complex framework-free application contains a [buggy] half-framework." The precise definition of a framework may be a bit hard to pin down, but most any experienced practitioner knows it when they see it. Things I look for:
* coupling of a blessed architecture, libraries, and patterns. Some choice of libraries may be allowed, but they must conform to a framework-prescribed interface.
* difficulty of isolating behavior for fast unit testing when using framework as prescribed (not always, but this is right more often than I want still)
* inversion of control as a core building block instead of straightforward composition. (This point gets fuzzier in callback-centric langs.)
* main() (or its moral equivalent) ends up being a framework bootstrap call, or is hidden entirely.
* related to last points: emphasis on hiding as many execution details as possible to present a simplified view of what the framework author believes is important.
* reliance on extension points to customize behavior (via subclassing/hooks) rather than simply exposing primitive operations that users can call alongside custom code.
* documentation beyond API docs and tutorials, usually necessitated by the number of novel concepts introduced by the framework
* heavier-than-normal emphasis on marketing, often leading with social proof from a megacorp, sometimes with big promises on how this framework is not like the others
The main takeaway should be this: a framework is not something that wants to blend into the background of your application. It is extremely visible and it is something that you program to, and often must take what it wants into account when designing. Without a framework, you can literally do whatever you want, including making a huge mess, or something small, functional and minimal.
I believe that should disqualify most of the rather absurd claims that all libraries/patterns/libc are "frameworks."
It is quite telling of HN's audience if they honestly think that "every sufficiently complex framework-free application contains a [buggy] half-framework." The precise definition of a framework may be a bit hard to pin down, but most any experienced practitioner knows it when they see it. Things I look for:
* coupling of a blessed architecture, libraries, and patterns. Some choice of libraries may be allowed, but they must conform to a framework-prescribed interface.
* difficulty of isolating behavior for fast unit testing when using framework as prescribed (not always, but this is right more often than I want still)
* inversion of control as a core building block instead of straightforward composition. (This point gets fuzzier in callback-centric langs.)
* main() (or its moral equivalent) ends up being a framework bootstrap call, or is hidden entirely.
* related to last points: emphasis on hiding as many execution details as possible to present a simplified view of what the framework author believes is important.
* reliance on extension points to customize behavior (via subclassing/hooks) rather than simply exposing primitive operations that users can call alongside custom code.
* documentation beyond API docs and tutorials, usually necessitated by the number of novel concepts introduced by the framework
* heavier-than-normal emphasis on marketing, often leading with social proof from a megacorp, sometimes with big promises on how this framework is not like the others
The main takeaway should be this: a framework is not something that wants to blend into the background of your application. It is extremely visible and it is something that you program to, and often must take what it wants into account when designing. Without a framework, you can literally do whatever you want, including making a huge mess, or something small, functional and minimal.
I believe that should disqualify most of the rather absurd claims that all libraries/patterns/libc are "frameworks."