4 ms·

The author's point is that a framework does not do anything that a library could not do better. A library respects the principles of abstraction that the progr

by kganser 11y ago

The author's point is that a framework does not do anything that a library could not do better. A library respects the principles of abstraction that the programming language provides, which is not true of a framework. Both can be consistent, well documented, well understood, etc., but one is definitely better when it comes to leveraging programming language abstractions. Ultimately, this means libraries are easier to learn than frameworks.

ubernostrum 11y ago
The flip side is that sooner or later the team ends up re-inventing all the things they felt they didn't need from a framework. The instant they start developing and enforcing conventions around architecture design, coding style, etc. (all of which are things they'll have to do as the team and codebase scale up in size) they're right back into all the things people point to as reasons to avoid frameworks.
- deleted 11y ago
  [deleted]
- ChrisDutrow 11y ago
  At that point, they have a framework that fits their use case and don't have to deal with a bunch of the negatives such as the framework getting abandoned, obfuscation, and the framework fighting their use case... Not that your point isn't good... I'm just saying its a grey issue.
  - FooBarWidget 11y ago
    > and don't have to deal with a bunch of the negatives such as the framework getting abandoned, obfuscation, and the framework fighting their use case That's what you think. What actually happens in many cases is that the developers get too busy with other work that is important to the business (e.g. working on the business value directly). At that point the internally-written framework has known bugs and issues, or maybe lack of documentation, but nobody has time budget to seriously solve them and so they keep using the internally-written framework with all its quirks. Once in a while a person who worked on the framework leaves, taking knowledge with him. The remaining people sometimes think "uh... this part so strange, why was it like this again?" but the guy who wrote it already left. And then once in a while someone new joins, thinks "this framework is shit" and ends up reinventing his own internal framework, with its own quirks, while not completely understanding the problems that the original framework was meant to solve. After a while the internal framework gets abandoned in favor of a standardized framework. I've seen this happening too many times during my days as a consultant. An internal framework is fine if your business case changes slowly, and your team changes slowly, and the framework has been very well-maintained. Miss any of those things and the framework eventually becomes a liability. So if you're a one-man company and you intend on staying that way, and your business case doesn't evolve quickly, fine. In all other cases though...
    - ChrisDutrow 11y ago
      Hmmm, I'm not sure we're talking about the same thing. Are you talking about someone doing something like writing their own ad-hoc ORM? I would agree that it's almost always best to use a library where possible, preferably one that's widely used and very mature.
aikah 11y ago
> which is not true of a framework What framework are you talking about ? Symfony or Silex do exactly that : "respects the principles of abstraction that the programming language provides". Spring does that too. Any framework powered by dependency injection does that. Only frameworks that try to be to smart for their own good like Rails violate basic separation of concerns. Furthermore, just have a look at most Go or Node web apps out there : globals everywhere, tightly coupled code, no separation of concerns, no dependency injection,direct db calls in controllers... All because "you don't need a framework with Go" or "Dependency injection makes no sense in Javascript", good to luck to the people maintaining these messes 5 years down the road. Not using a framework doesn't make a automatically a codebase better. A framework however can mandate some discipline,especially when based on IoC : on one side : the framework's code , on the other side : the user code and the only glue is the manifest declaring dependencies between the two.
- kganser 11y ago
  You're right that IoC/Dependency injection pretty much define a framework -- that and ascii folder diagrams. IoC and other patterns are pretty common and well regarded, but they are not features of the language. If you had a library using functional programming instead of an IoC framework you'd be closer to the "principles of abstraction that the programming language provides."
- mchahn 11y ago
  > globals everywhere, tightly coupled code, no separation of concerns Speak for yourself. I am not guilty of any of these in my large node applications. And I use no frameworks, just npm libraries.
  - deleted 11y ago
    [deleted]
crdoconnor 11y ago
That's not really true. Frameworks enforce patterns on developers (e.g. MVC), and they create a consistent ecosystem within which you can create easily interoperable plugins. The author's point seems to be informed by being burned by many bad frameworks (which is, to be fair, 90% of frameworks - if you pick based upon fashion driven development this is the hole you'll end up in). A good framework is rare but immensely valuable. A bad framework is worse than no framework at all.

by kganser 11y ago

ubernostrum 11y ago

The flip side is that sooner or later the team ends up re-inventing all the things they felt they didn't need from a framework. The instant they start developing and enforcing conventions around architecture design, coding style, etc. (all of which are things they'll have to do as the team and codebase scale up in size) they're right back into all the things people point to as reasons to avoid frameworks.

deleted 11y ago
[deleted]
ChrisDutrow 11y ago
At that point, they have a framework that fits their use case and don't have to deal with a bunch of the negatives such as the framework getting abandoned, obfuscation, and the framework fighting their use case... Not that your point isn't good... I'm just saying its a grey issue.
- FooBarWidget 11y ago
  > and don't have to deal with a bunch of the negatives such as the framework getting abandoned, obfuscation, and the framework fighting their use case That's what you think. What actually happens in many cases is that the developers get too busy with other work that is important to the business (e.g. working on the business value directly). At that point the internally-written framework has known bugs and issues, or maybe lack of documentation, but nobody has time budget to seriously solve them and so they keep using the internally-written framework with all its quirks. Once in a while a person who worked on the framework leaves, taking knowledge with him. The remaining people sometimes think "uh... this part so strange, why was it like this again?" but the guy who wrote it already left. And then once in a while someone new joins, thinks "this framework is shit" and ends up reinventing his own internal framework, with its own quirks, while not completely understanding the problems that the original framework was meant to solve. After a while the internal framework gets abandoned in favor of a standardized framework. I've seen this happening too many times during my days as a consultant. An internal framework is fine if your business case changes slowly, and your team changes slowly, and the framework has been very well-maintained. Miss any of those things and the framework eventually becomes a liability. So if you're a one-man company and you intend on staying that way, and your business case doesn't evolve quickly, fine. In all other cases though...
  - ChrisDutrow 11y ago
    Hmmm, I'm not sure we're talking about the same thing. Are you talking about someone doing something like writing their own ad-hoc ORM? I would agree that it's almost always best to use a library where possible, preferably one that's widely used and very mature.

aikah 11y ago

> which is not true of a framework What framework are you talking about ? Symfony or Silex do exactly that : "respects the principles of abstraction that the programming language provides". Spring does that too. Any framework powered by dependency injection does that. Only frameworks that try to be to smart for their own good like Rails violate basic separation of concerns. Furthermore, just have a look at most Go or Node web apps out there : globals everywhere, tightly coupled code, no separation of concerns, no dependency injection,direct db calls in controllers... All because "you don't need a framework with Go" or "Dependency injection makes no sense in Javascript", good to luck to the people maintaining these messes 5 years down the road. Not using a framework doesn't make a automatically a codebase better. A framework however can mandate some discipline,especially when based on IoC : on one side : the framework's code , on the other side : the user code and the only glue is the manifest declaring dependencies between the two.

kganser 11y ago
You're right that IoC/Dependency injection pretty much define a framework -- that and ascii folder diagrams. IoC and other patterns are pretty common and well regarded, but they are not features of the language. If you had a library using functional programming instead of an IoC framework you'd be closer to the "principles of abstraction that the programming language provides."
mchahn 11y ago
> globals everywhere, tightly coupled code, no separation of concerns Speak for yourself. I am not guilty of any of these in my large node applications. And I use no frameworks, just npm libraries.
- deleted 11y ago
  [deleted]

crdoconnor 11y ago

That's not really true. Frameworks enforce patterns on developers (e.g. MVC), and they create a consistent ecosystem within which you can create easily interoperable plugins. The author's point seems to be informed by being burned by many bad frameworks (which is, to be fair, 90% of frameworks - if you pick based upon fashion driven development this is the hole you'll end up in). A good framework is rare but immensely valuable. A bad framework is worse than no framework at all.