Using sufficiently powerful programming languages, we can create better libraries that use lazy evaluation and higher-order functions.
Well, yes. But the whole point of using a framework is that it's already created. The next time I go to a client who wants a scalable international web application that needs... well, the same stuff that's in pretty much every other scalable international web application. Why shouldn't I run it up on a framework that provides all that and save myself (and the client) six months of building, glue code, integration, and all the other testing?
One of the arguments against frameworks is that they're hard to learn: On the upside, while frameworks often need the be “learned”, this is less so the case with libraries. People read whole books on how to use a particular framework, but they usually just start programming against a library.
Right. So I go and learn a framework, once. In a few weeks of not being visibly productive, I front-load the next 2-5 years of my life and my actual day-to-day job of creating the unique stuff -- the business logic, data tier, front end -- becomes much more productive.
Using a framework is great as long as you only want to do the things it's designers planned for. As soon as you want to do something else, unless you're very lucky, it sucks. If you're using a library you generally have more options when you get into this situation.
As with anything, choose whatever's most appropriate for the job. But, as a single data point, every framework-based project I've worked on - literally every single one - has ended up in that situation.
I have worked on all kind of project - lots of libraries, internal "framework" on top of lots of libraries, and plain framework.
The comment "As soon as you want to do something else, unless you're very lucky, it sucks." applies to pretty much all the situations.
To give my single data point I'm currently working on an application that is more libraries than framework, and the way we used libraries is clashing with what the application has been repurposed to do. In our case, the library can do it, we could have coded in a way that would have solved our current goal, however 5 years ago it did not make sense to do so, so here we are.
More basically, the reasons you cannot chose the right framework that will meet your future need are going to lead into making the not-future-proof design decisions. That even happen when you do not use any library or framework.
The difference with a framework is that it starts with its own history while you start fresh with a bunch of libraries. Initially you have a lot less chance to run into complex refactoring when you roll your own ( conversely, as parent said, you do not get any of the benefit that using a framework brings you: like enabling some powerful feature by configuration or with very minimal effort) The more code you commit however the less it starts to matter.
> The next time I go to a client who wants a scalable international web application that needs... well, the same stuff that's in pretty much every other scalable international web application. Why shouldn't I run it up on a framework that provides all that and save myself (and the client) six months of building, glue code, integration, and all the other testing?
Sounds like you're a consultant / freelancer (like me). For folks in our position, frameworks are win-win. We can become specialists in them, get things implemented quickly and more cheaply than an alternative, and satisfy our clients.
Of course, also having been on the other side, I know that the pain of frameworks comes later, in long-term maintenance. This is because the frameworks more or less "define reality" for the applications that are hosted within them. And when an applications business needs start to reach beyond what the framework is capable of making easy, then the development tradeoffs start to get nasty.
"No matter which you choose, whether to use a framework or not to use a framework, you are destined to end up regretting your decision." - A smart ex-colleague of mine.
1. Frameworks _are_ libraries with inversion of control.
2. It is harder to write a library than to write a program, because you have to design an API for the calling code. This is a higher order task than just writing a program, because the library has to generalize to all applicable use cases. It is easy to get it wrong (Java Calendar API for example).
3. It is even harder to write a framework, because not only will the framework provide an API to the calling code, it will also take control of the program flow to some degree. If not done correctly, then there will be cases where the calling code could be unable to satisfy some reasonable requirement because they are unable to influence the control flow in that area of the framework. This is an even higher order task than writing a library.
It's akin to the difference between solving a specific problem in math (solve this particular quadratic equation), or solving the whole class of problems at once (derive quadratic formula) or showing that two apparently unrelated problems are actually isomorphic (Galois theory - linking theory of equations to permutations).
The alternative, writing lower level code that you understand, is also bad once scaled out team wide.
It's one thing to write you own bespoke code for everything in your basement, but when scaled out across a team of developers, if there is not a lot of attention paid to consistency of the various parts of the application, then you can get into nightmare codebases that become big balls of mud.
I don't even think this is like a thing to debate about. They're not the same thing.
I've been a developer for near 10 years. In that time I've worked on a heck of a lot of different applications. The funny thing, is in that time I've written the same code time and time again. A bit different each time, but none the less similar function.
That code though, it's not something that can be replaced by a library. That's because it IS the code calling the library. If a library is a water heater, the framework is the duct work.
So frameworks to me give me a way to write a lot less of that code, and to write a lot more of the code that makes my application useful.
I've been brewing my own framework, for doing a very particular type of application that I tend to somehow write quite often. I wouldn't tell people to use it for everything. But for the things I use it for, it is perfect. The speed that I can iterate at has given me a name at my various employers.
- allow each component to be easily replaced by another component
Some disadvantages of libraries:
- every library typically needs some "glue logic" to fit in the total program, causing performance overhead and/or code ugliness
- every library maintains state in a different way, making it difficult to atomically control or save the state of the complete application (a similar problem exists with microservices)
- (related) also garbage collection over objects in different libraries may become a nightmare if every library implements its own garbage collector (try mixing V8 and a Java VM, for example)
I think this discussion could benefit from some examples. I can readily think of Rails and Django as frameworks, but what are the library counter-examples? And what are the actual pros and cons of those particular examples.
I find it hard to think of these in the abstract.
Additionally, I suppose that the workflow around the library or framework should be taken into account.
For instance, if there is a large team, a framework might be better because you already know the conventions? But what if the team changes a lot? What if you have great on-boarding tools?
Some programmers want to draw a line in the sand and say that on this side is "my" code and the other side is acceptable third-party code - without really considering each project itself.
Frameworks are really just a collection of libraries that are already connected together and organized in a specific way. If it doesn't add value to the project then don't use it. If it does, then use one.
You could make the same argument about any level of abstraction, from the OS, to the language, to a web server, to a client-side framework, etc.
I would like answer the same question much more simple: Because libraries can retain backwards compatibility much easier.
It's not always true, but enough so to be something you can reason about. Because of how the call flows (a framework calls you, you call a library), any non-trivial change in the structure of a framework requires a corresponding change in the application. A library has more degrees of freedom to change while retaining compatiblity.
..but you can't just use one library to replace the functionality of a framework.
While a library has "more degrees of freedom", this means your application (using many libraries) has many moving parts that don't really care about each other, so your application -- already octopussy because of having to glue libraries together in the first place -- now gets even curlier as you tweak it to fit library changes.
Framework developers, one hopes, at least try to keep their changes-over-time a bit consistent within the framework. Library devs have no such obligation.
>There are, of course, a lot of definitions of frameworks and libraries. I don’t want to get into those, rather I’d like to illustrate my view on the differences by means of this picture
Kudos to this... it is the clearest visual expanation I have seen regarding the differences between a framework and a library
That's not correct. For instance, when I was programming Java Server stuff, we've used the Acegi Framework for security and the JSF Framework for MVC. You could've even used JSF together with another MVC Framework if you really wanted. But you couldn't wrap either of the two and thus making them swappable behind the wrapper.
Well, yes. But the whole point of using a framework is that it's already created. The next time I go to a client who wants a scalable international web application that needs... well, the same stuff that's in pretty much every other scalable international web application. Why shouldn't I run it up on a framework that provides all that and save myself (and the client) six months of building, glue code, integration, and all the other testing?
One of the arguments against frameworks is that they're hard to learn: On the upside, while frameworks often need the be “learned”, this is less so the case with libraries. People read whole books on how to use a particular framework, but they usually just start programming against a library.
Right. So I go and learn a framework, once. In a few weeks of not being visibly productive, I front-load the next 2-5 years of my life and my actual day-to-day job of creating the unique stuff -- the business logic, data tier, front end -- becomes much more productive.