

Libraries vs Frameworks - markokocic
http://blog.orderharmony.com/2011/07/libraries-vs-frameworks.html

======
F_J_H
A mistake I’ve seen in the past is that these types of decisions (i.e. which
framework or library, should I even use a framework, etc.) are made for
technical reasons rather than business reasons. What are your goals? Are you
building an app for yourself as a hobbyist? Are you building an app to sell?
Are you building a business around your app?

You need a house. You can:

\- design your own

\- build from someone else's plans and make mods as you see fit ( recognizing
that too many mods may compromise the overall plan.)

\- buy a prefab “kit” home that you assemble

\- buy a mobile home trailer

What should you do? It depends:

\- Do you need something right away?

\- Do you want to win architectural awards and hopefully be profiled in a
“beautiful home” magazine?

\- Do you want your home to be mobile?

All in all, I’ve found that each decision has its trade offs. Pick your
poison. You will always find reasons why you should have maybe gone another
route. “Too bad we didn’t use framework X. It makes problem Y so much easier
to deal with.” Oh? And what about problem A, B, and C?

My B2B Company started with MS Access. It got us our MVP very quickly, and our
first clients. A good technical decision? No. A good business decision? Well,
it worked out pretty well for me.. If I were starting again, (in the B2B space
in which I am most familiar), I would probably go with Oracle’s Application
Express, with which I could very rapidly build a functioning prototype and
even run the business on for the first (perhaps long) while.

One of my favorite pieces of wisdom from Steve Blank is “Most often, business
don’t fail due to a lack of technology but due to a lack of customers”.

“The speed of a non-working program is irrelevant.” - S. Heller (in "Efficient
C/C++ Programming")

See also: [http://onstartups.com/tabid/3339/bid/3055/Startups-and-
The-P...](http://onstartups.com/tabid/3339/bid/3055/Startups-and-The-Problem-
Of-Premature-Scalaculation.aspx)

~~~
invalidOrTaken
A "technically informed business decision" is probably the goal.

------
scorpion032
The selling point of these referred frameworks is the time to market. Do it in
a way we know it has worked for so many people so far, and the framework code
glues pieces together to make it good for you. Make it good for you until a
particular reasonable scale.

No framework can claim to be the best fit in all the several dimensions on
which they can be measured, one of which is, "time to market", today of all
time.

At scale everything breaks down and need a custom implementation. If anything
the framework needs to be good at, it is, how well it allows itself to be
replaced and with how little effort.

Twitter is gradually moving all it's components into the "best production
platform" JVM today. I don't think any body can provide convincing argument
that building it on JVM right from the beginning would have been a better
solution.

Outgrow a framework and roll your own at the points that are critical for your
application. Do the common things like, sending emails etc, in a standard way
and let it be handled the reasonably right way.

~~~
colin_jack
> If anything the framework needs to be good at, it is, how well it allows
> itself to be replaced and with how little effort.

Agree completely, its an obvious point but I do also think good frameworks
allow plugging out smaller chunks elegantly

------
St-Clock
This article does not seem well thought out. It takes a condescending look on
frameworks (and object-oriented programming) and contains many inaccuracies.
For example, most ORM frameworks/libraries allow the developers to map an
existing database schema with existing classes. They do not "force" you to
follow only one type of mapping.

Now, what's the difference between a library and a framework? Hint: it's
probably a continuum between no inversion of control and total inversion of
control (not "reversion of control" btw). Many libraries provide some
inversion of control mechanisms and "force" you to work their way
(tyranny!!!). Is JQuery a library with all its callbacks and the use of $?
Should you use JQuery then or "stay in control"?

As for: "So, our advice to you is to stay in control of the development path
of your software and prefer libraries over frameworks for real-world
projects."

Where is the nuance, the "it depends" in this conclusion? It depends on where
you are in the product lifecycle, where your competitors are, how many
developers you have, what your core features are vs. what features the
frameworks can provide, etc.

For example, imagine that you invented a new programming language. Say
clojure. Now you want to provide syntax highlighting, syntax checking, tab-
completion, features that an IDE provide. Will you (1) write a completely new
IDE or (2) write a plug-in/extension/script for vim/emacs/eclipse/netbeans?
Are they, "real world projects"?

~~~
cdcarter
"reversion of control" was a joke on the authors part. Revert the control back
to you, out of the framework.

~~~
St-Clock
Ooohhh. Thank you, it makes sense! (I still stand by my criticism of their
article though).

------
mattgreen
How do you reconcile the need to move fast initially to release a product or
service in order to build the market for it from a business perspective?

Does having to 'build your own framework' (my paraphrasing of your point)
typically mean your software delivery is slower?

Is this detrimental to the business objective you're trying to achieve?

Does a 2-fold approach work - using a more substantial framework to begin with
(for speed) followed by re-factoring into your own more specialised "framework
of libraries" later?

Definitely some food for thought in your point - I presume it's based on
actual experience of programming under both regimes?

~~~
l0st3d
> Does having to 'build your own framework' (my paraphrasing of your point)
> typically mean your software delivery is slower?

Possibly, initially. However, probably not significantly, since you should
only build the framework that you need.

> Is this detrimental to the business objective you're trying to achieve?

No, since the business objective is to make money. The software is the means
to do that, and the choices you make today limit the markets that you can
expand into. If you decide that you're making a mobile app for android, then
you are going to have to do a bunch of work (possibly including re-
implementing the app) to get into the iphone or desktop market.

> Does a 2-fold approach work - using a more substantial framework to begin
> with (for speed) followed by re-factoring into your own more specialised
> "framework of libraries" later?

I think that taking the framework away is very difficult. Even when you've
replaced all the code, and no longer depend on it, you still have the basic
shape that lingers. I think that we generally call that a "re-write".

> Definitely some food for thought in your point - I presume it's based on
> actual experience of programming under both regimes?

yes

~~~
encoderer
_"Possibly, initially. However, probably not significantly, since you should
only build the framework that you need."_

OK, I have to throw a flag on this point.

Modern frameworks give you a lot of essential functionality OOTB. I've worked
on enough home-brewed frameworks -- and indeed have been foolish enough once
or twice to build my own. I've also used several great frameworks across a
number of common languages.

If you can make an honest case that it's "probably not significantly" slower
to roll your own framework as you develop an app than it would be to develop
that same app on top of a great modern framework, then I'd love to hear it.

------
nsomaru
I guess the best of both worlds for a beginner like myself is to find a
framework (Django) that treats its parts as libraries (i.e. you can swap out
any one part for another).

Granted, it's not completely seamless, but the option exists. Many Django
programmers, for example, do not use the standard templating language
available with Django.

~~~
lucian1900
Sadly, Django is both highly interconnected and has less than clean design. So
while you can swap one bit for another, you'll still depend on all of django,
and the stranger will be obvious.

~~~
zeemonkee
A lot of useful stuff in Django also lives in 3rd party apps that depend on
Django-specific things e.g. authentication or templates.

------
geebee
This artile mentions that java is prone to the framework approach, but I found
the library approach eas prevalent until around 2005. Remember the old oreilly
"java cookbook"? Java developers often used the servlet spec, then went to
recipes and libraries as needed. Now, the notion of a java cookbook seems to
be extinct -it's largely been replaced by spring.

I actually think java's woes are largely due to the ramp up difficulties with
elaborate frameworks rather than the language itself. It wasn't nearly so
difficult to get started with web programming with java prior to 2005 (and I'm
starting to detect a movement away from all encompassing frameworks even in
java). Java will always be verbose and a bit lowish level compared to python
or ruby, but I think it could be vastly simpler and easier to use.

I'm encouraged by this article, and I hope it gains more traction in other
languages.

------
Swannie
Isn't this the reason for the design of Spring (Java framework/library)?

You can work in the whole framework (slightly unusual), or just use components
as a library.

------
wildmXranat
There's a secondary and underlying factor important to consider: vm / language
baggage. It's easy to use the cool, hip and shiny new languages, but I don't
see it mentioned as an important precursor to disqualifying libraries or
frameworks. I don't even think it can be dismissed as an orthogonal issue as
it directly precedes the other.

As a non-experienced jvm developer,I wonder what is appeal to be locked in to
a vm that eats RAM for breakfast? I tried the cool and hip frameworks in
clojure and java. Just saying.

~~~
brazzy
Eating RAM for breakfast is a symptom of two factors:

1\. Garbage collection. It works better the more RAM it has to play with. And
in return it provides pretty substantial benefits (eliminates many memory-
related errors and nonproductive housekeeping tasks).

2\. RAM being available in humongous amounts for very little money. Eating RAM
for breakfast simply isn't a buisness-significant downside of a language/vm
these days.

BTW, the Oracle JVM (and probably others as well) garbage collector can be
tuned quite a bit to make it less memory-hungry at the expense of performance.
Factor 2 makes this a rarely-necessary and thus little known option.

------
espeed
It's inversion of control
(<http://en.wikipedia.org/wiki/Inversion_of_control>), not "reversion of
control"

~~~
l0st3d
I think that was meant to be a joke.

~~~
Sandman
It was - [http://blog.orderharmony.com/2011/07/libraries-vs-
frameworks...](http://blog.orderharmony.com/2011/07/libraries-vs-
frameworks.html?showComment=1310641325410#c4245801418480022704)

------
dhruvbird
neat! I came to a similar conclusion a while ago, but you've presented it
better: [http://dhruvbird.blogspot.com/2010/12/library-vs-
framework.h...](http://dhruvbird.blogspot.com/2010/12/library-vs-
framework.html)

------
zby
Frameworks are framing, libraries are liberating :)

------
swah
tl,dr: author is very happy to use clojure's ring.

------
reustle
"and it's the best production platform available today."

Am I wrong to be bothered when people state things this way?

