Use 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 breed something even worse; ad-hoc copy-pasted cargo-cult setup files, pseudo-frameworks that use StackOverflow as source control.
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.
I see no proof that JS frameworks lend themselves to less StackOverflow questions.
Let's take React vs. Angular 2+ for example. Despite React.js having three times the popularity and being 4 years old at this point, it has 50,762 questions on SO [1] vs Angular 2+, which despite being less than one year old...has
63,932 questions on SO.
I 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.
I think frameworks are great for quick proofs of concept. There is less thinking up front I suppose. But given a long enough timeline on a complex enough project and a framework begins to show its limitations. And then you end up fighting the framework. You're also at the mercy of the framework's maintainers to adapt and evolve your app's architecture.
We are still learning and experimenting with the best ways to build apps. Libraries allow you to adapt as new patterns and paradigms emerge, much easier than frameworks.
Having 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.
This 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.
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.
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.
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.
Its a fair argument to make but honestly I've never worked on a web app where I didn't think that using an MVC framework like Django or Rails made sense.. Do you have any examples of web apps that would be better off without a framework than with?
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.
Light and simple REST servers can be implemented quicker with Flask - less boilerplate and less setup.
Large complex codebases often have design considerations that don't fit neatly into Django's one-model-per-view, all-models-are-backed-by-a-relational-database opinions - think apps that require immutable datastores or frequent calls to an ML pipeline. Those are often better implemented as a composition of various libraries.
The thing about organic codebases is that, you can impose a better architecture if you so wish. Frameworks often make the architectural decision for you, in which case you're out of luck if that architecture doesn't suit your application.
> 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.
> The whole article really doesn't apply to any mainstream programming languages like ruby, python, java, javascript etc.
Why? I use JavaScript solely, and I agree with the author 100%. The frameworks solve a lot of problems, but by bundling those solutions together they introduce a new problem.
> How do you organise the interaction of libraries?
This is what coding is. Asking this question over and over. You can't escape it. You can make a promise to yourself: "I'll just do it the Rails way" but that doesn't get you off the hook. Now you need to learn what the Rails way is. And that itself is never done. You will need to ask over and over "What is the Rails way?"
> 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.
Again, that's is what coding is. Patterns. Which pattern do we need now? How about now? How about now? The Rails pattern only takes you so far. And for many problems it will steer you wrong. You can't avoid learning patterns and when to use them, it's part of your job.
> What happens when another coder joins your project?
Part of why this is scary, is because if you use a framework that coder REALLY needs to understand the framework. The framework itself is a big domain of code that you generally don't want to have to debug, and you don't want to have to wonder how it works. You kind of need to know how it works before you start.
But idiomatic code is different. If I write a system in pure, idiomatic Java, with no framework, a new programmer doesn't have to understand any kind of underlying system. They don't need to understand a framework, because there is no framework. All of the code is right there in the repo. They can just go read it. They can place a debugger and walk step by step through the whole interaction, without ever leading their codebase.
> Are you going to tell them the pattern you have already been using?
Yes, usually if they're new we pair program until they get a sense of the layout. But again, they don't need to learn the pattern in the same way that you need to learn the Rails routing pattern, or the Rails ActiveRecord pattern. You don't need to learn the pattern of a bespoke codebase, because you can just go read the code. There's not some separate system which is doing it's own thing in parallel to your application, there's just your application.
> What if they dont follow it as expected or disagree with it?
Great! That's their job too. They should disagree with the architecture, find better ways of doing things, and talk about that with their coworkers.
> 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.
Sometimes that standardization is a worthwhile tradeoff for sure. If you need to get up and running quickly, and you want to start with a big team who already has some alignment, you definitely need some standards.
You also probably want a framework if you're building lots of apps that will mostly not be maintained. So, like special event apps for NFL playoffs, or marketing campaigns or something.
But if you're starting with a couple of developers and growing organically, and if you're trying to build a product that you will be actively adapting to your business needs for many years, a framework might get in your way in the long run.
Can't agree more. Both frameworks and libraries have their place. But arguing framework are evil is immature. If you are not using one, you probably are building one without you being aware of it. Use whatever works.
Probably depends on the language. Frameworks are great on the front end though, because Angular/Vue are basically just easy ways to interact with the GUI. It's much less convenient without a framework.
It does sort of resemble 'koehler' from the color schemes that shipped with my copy of Vim. Certain details are different, but it may be a good one from which to start.
19 comments
[ 3.5 ms ] story [ 60.7 ms ] threadSnark 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.
I suspect Libraries-not-frameworks is only advice for those using sufficiently expressive languages. So probably not appropriate advice for JavaScript.
Let's take React vs. Angular 2+ for example. Despite React.js having three times the popularity and being 4 years old at this point, it has 50,762 questions on SO [1] vs Angular 2+, which despite being less than one year old...has 63,932 questions on SO.
[1] https://stackoverflow.com/questions/tagged/reactjs [2] https://stackoverflow.com/questions/tagged/angular
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.
We are still learning and experimenting with the best ways to build apps. Libraries allow you to adapt as new patterns and paradigms emerge, much easier than frameworks.
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.
Also if you want to offer leverage in distribution and scalability you need a framework.
https://github.com/tinspin/rupy
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.
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.
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.
Light and simple REST servers can be implemented quicker with Flask - less boilerplate and less setup.
Large complex codebases often have design considerations that don't fit neatly into Django's one-model-per-view, all-models-are-backed-by-a-relational-database opinions - think apps that require immutable datastores or frequent calls to an ML pipeline. Those are often better implemented as a composition of various libraries.
The thing about organic codebases is that, you can impose a better architecture if you so wish. Frameworks often make the architectural decision for you, in which case you're out of luck if that architecture doesn't suit your application.
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.
Thats not what he says. He says that these ideas "can be useful in any programming language". Which is the point that I disagree with.
> there's nothing to prevent a library on top of all these others libraries to accomplish this
So a library to organise the code which interacts with other libraries? Sounds an awful lot like a framework to me?
> So a library to organise the code which interacts with other libraries? Sounds an awful lot like a framework to me?
The domain/purpose does not alter the framework/library distinction according to his definition.
Why? I use JavaScript solely, and I agree with the author 100%. The frameworks solve a lot of problems, but by bundling those solutions together they introduce a new problem.
> How do you organise the interaction of libraries?
This is what coding is. Asking this question over and over. You can't escape it. You can make a promise to yourself: "I'll just do it the Rails way" but that doesn't get you off the hook. Now you need to learn what the Rails way is. And that itself is never done. You will need to ask over and over "What is the Rails way?"
> 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.
Again, that's is what coding is. Patterns. Which pattern do we need now? How about now? How about now? The Rails pattern only takes you so far. And for many problems it will steer you wrong. You can't avoid learning patterns and when to use them, it's part of your job.
> What happens when another coder joins your project?
Part of why this is scary, is because if you use a framework that coder REALLY needs to understand the framework. The framework itself is a big domain of code that you generally don't want to have to debug, and you don't want to have to wonder how it works. You kind of need to know how it works before you start.
But idiomatic code is different. If I write a system in pure, idiomatic Java, with no framework, a new programmer doesn't have to understand any kind of underlying system. They don't need to understand a framework, because there is no framework. All of the code is right there in the repo. They can just go read it. They can place a debugger and walk step by step through the whole interaction, without ever leading their codebase.
> Are you going to tell them the pattern you have already been using?
Yes, usually if they're new we pair program until they get a sense of the layout. But again, they don't need to learn the pattern in the same way that you need to learn the Rails routing pattern, or the Rails ActiveRecord pattern. You don't need to learn the pattern of a bespoke codebase, because you can just go read the code. There's not some separate system which is doing it's own thing in parallel to your application, there's just your application.
> What if they dont follow it as expected or disagree with it?
Great! That's their job too. They should disagree with the architecture, find better ways of doing things, and talk about that with their coworkers.
> 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.
Sometimes that standardization is a worthwhile tradeoff for sure. If you need to get up and running quickly, and you want to start with a big team who already has some alignment, you definitely need some standards.
You also probably want a framework if you're building lots of apps that will mostly not be maintained. So, like special event apps for NFL playoffs, or marketing campaigns or something.
But if you're starting with a couple of developers and growing organically, and if you're trying to build a product that you will be actively adapting to your business needs for many years, a framework might get in your way in the long run.
It does sort of resemble 'koehler' from the color schemes that shipped with my copy of Vim. Certain details are different, but it may be a good one from which to start.