Library patterns: Why frameworks are evil
1–10 of 20 posts
Re: Library patterns: Why frameworks are evil
#2 Use events & async functions instead of frameworks
Snark aside, we've seen (more than once) in the Javascript space that "libraries not frameworks" can breed something even worse; ad-hoc copy-pasted cargo-cult setup files, pseudo-frameworks that use StackOverflow as source control.
Re: Library patterns: Why frameworks are evil
#3I unfortunately depend more on frameworks than libraries for coding apps, mainly because I think frameworks are easier for me to use to manage software architecture and patterns, its harder for me to manage a software project with just libraries because I often spend hours just trying to figure out how certain components should interact. I understand the concern but I think for starting a project, relying upon a framework is much easier as it abstracts away a lot of the thinking in the beginning for managing the architecture.
Probably libraries play in more with a more mature app because its much easier to optimize and maintain once you have a set pattern to rely on.
Re: Library patterns: Why frameworks are evil
#4Having worked with plenty of frameworks and libraries over the years, I also find myself solidly in favor of libraries. In a sense, IMHO, you are a slave to the framework but a master of the library. (On a side note, pretty much the same dichotomy applies to cats vs. dogs).
That being said, I have several friends with the same level of programming experience who stringly disagree. So voicing my opinion on frameworks is always excellent fuel for discussion.
Re: Library patterns: Why frameworks are evil
#5I tried to build my app server as a library and a framework, but to hot-deploy code you need a framework.
Also if you want to offer leverage in distribution and scalability you need a framework.
Re: Library patterns: Why frameworks are evil
#6Use events & async functions instead of frameworks Funny, the runtime required to support that async abstraction sure sounds like a thing that's responsible for running the system while you plug pieces of code into it at defined extension points. But that's unpossible, since we just learned that doing that is EVIL. Snark aside, we've seen (more than once) in the Javascript space that "libraries not frameworks" can br…
I would argue that Async in F# is just a library. Async tasks are essentially just functions that are composed using the more general "workflow" syntax. The final composite Async must be explicitly run with a choice of scheduler.
I suspect Libraries-not-frameworks is only advice for those using sufficiently expressive languages. So probably not appropriate advice for JavaScript.
Re: Library patterns: Why frameworks are evil
#7 This follows from my experience with building F# libraries, but the ideas are quite general and can be useful in any programming language.
His analogy about frameworks being package holidays while composing libraries is like independent travel only tells half the story. How do you organise the interaction of libraries? You can do it yourself but you will have to follow some sort of pattern to organise the code in order to make it easy to work with. What happens when another coder joins your project? Are you going to tell them the pattern you have already been using? What if they dont follow it as expected or disagree with it? Frameworks standardise this. Yes you might not always like certain aspects of the framework you're using but its the price you pay for not having a project full of developers who each have their own way of doing things and are constantly argueing over how to organise the codebase.
Also this hyperbolic use of the word "evil" is immature and dorky. Sorry.
Re: Library patterns: Why frameworks are evil
#8This follows from my experience with building F# libraries, but the ideas are quite general and can be useful in any programming language. This is just not true. The whole article really doesn't apply to any mainstream programming languages like ruby, python, java, javascript etc. The author seems to be coming from an academic view point and the points he makes really don't translate to the software engineering world…
Allowing your codebase to develop organically is a lot better than trying to fit the square peg of your domain into the round hole of the chosen framework. And it will always be a bad fit, popular frameworks are rarely built to cater to a specific domain.
I've worked with Django applications for years now, and this article definitely resonates with me. I think Python and other object-oriented languages have a bad time with composition, which is why overbearing frameworks rule the land.
Re: Library patterns: Why frameworks are evil
#9This follows from my experience with building F# libraries, but the ideas are quite general and can be useful in any programming language. This is just not true. The whole article really doesn't apply to any mainstream programming languages like ruby, python, java, javascript etc. The author seems to be coming from an academic view point and the points he makes really don't translate to the software engineering world…
> points he makes really don't translate to the software engineering world
His advice is in the context of functional programming languages. F#, Scala and even Haskell and OCaml are now very much part of the software engineering world (albeit a small part).
> How do you organise the interaction of libraries? You can do it yourself but you will have to follow some sort of pattern to organise the code
Because libraries compose, there's nothing to prevent a library on top of all these others libraries to accomplish this. If you have to repeat yourself with "patterns", your language of choice is failing you.
Re: Library patterns: Why frameworks are evil
#10This follows from my experience with building F# libraries, but the ideas are quite general and can be useful in any programming language. This is just not true. The whole article really doesn't apply to any mainstream programming languages like ruby, python, java, javascript etc. The author seems to be coming from an academic view point and the points he makes really don't translate to the software engineering world…
Allowing your codebase to develop organically is a lot better than trying to fit the square peg of your domain into the round hole of the chosen framework. And it will always be a bad fit, popular frameworks are rarely built to cater to a specific domain. I've worked with Django applications for years now, and this article definitely resonates with me. I think Python and other object-oriented languages have a bad tim…
Allowing your codebase to develop organically is a lot better than trying to fit the square peg of your domain into the round hole of the chosen framework.
Also there are plenty of PHP codebases that were developed "organically" (i.e. without a framework) that are absolute eye sores to look at because without a structure in place its too easy for developers to write bad code.