

Why Libraries are better than Frameworks - signa11
http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks/#

======
jeremysmyth
_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.

~~~
vilya
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.

~~~
gutnor
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.

------
jasonwocky
"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.

~~~
arthurjj
"The grass is always greener" is a cliche for a reason.

------
flying_squirrel
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.

------
swalsh
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.

------
amelius
Some advantages of libraries:

\- they stimulate more clearly defined APIs

\- 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)

------
jakejake
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.

------
projectramo
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?

This debate needs more context.

------
xorcist
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.

~~~
jeremysmyth
..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.

------
pmelendez
>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

------
skatenerd
I really enjoyed this post. It's more on _how to design libraries_ , rather
than on why libraries are better

[http://tomasp.net/blog/2015/library-
layers/index.html](http://tomasp.net/blog/2015/library-layers/index.html)

~~~
spikej
and the more recent one: [http://tomasp.net/blog/2015/library-
frameworks/index.html](http://tomasp.net/blog/2015/library-
frameworks/index.html)

------
simonw
In one sentence: you can mix-and-match libraries, but you can only use one
framework.

~~~
emsy
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.

