

Libraries versus Frameworks - irrelative
http://sitecanary.com/blog/2

======
jmtulloss
I'm not sure there's a lot of weight in the author's argument. The crux of his
argument is that you'll eventually need to learn how the framework does what
it does. Of course you'll eventually need to do that, but if you didn't have
the framework, you'd have to learn all that just to get your app off the
ground. It's a premature optimization to not use a framework. The key is to
use a well designed framework that makes sense and doesn't get in your way
once you have to start digging through its internals.

I do agree on one point though, for small apps that you want to get going
quickly, webpy is awesome.

~~~
fauigerzigerk
No, I don't have to learn how highly abstracted ORM code works to get my app
off the ground without an ORM. ORMs are much more complex than straight to the
metal SQL or writing to a text file.

Don't underestimate the amount of code needed to generalise over all cases a
framework needs to support. Not using a framework does not mean to write that
same kind of code myself because I only need to generalise over my own cases
not everyone elses.

~~~
jmtulloss
That's the difference between using a simple, straightforward framework and
"magic" framework. A well designed framework should expect that its users are
going to need to dig through the internals and should design accordingly. It
also should not force you to use any particular abstraction if you don't want
to. Don't need an ORM? Don't use it.

~~~
fauigerzigerk
Sorry, but you are just repeating framework marketing fluff. Have you read
what I said about generalisation at all?

Frameworks _must_ generalise further than I do in any particular project
because they cover a much wider range of cases. It's not just "magic"
frameworks or badly designed frameworks, it's simply the logic of what
frameworks are.

Therefore this claim you make is just not true: "but if you didn't have the
framework, you'd have to learn all that just to get your app off the ground"

------
marcofloriano
I think, that´s the difference between professional programmers and hackers.
Hackers cant stand to write code without understanding what is happening
behind the scenes. Therefore they need to go deep into their codes and
understand each aspects. In the other hand, when your code for a big company
and follow a lot of rules and demands, you are more inclined to use solutions
like frameworks, because you are not having real fun, your are just ...
working. Make sense for you ?

~~~
dryicerx
This is what I would guess at first sight too, but reality disagrees: it seems
lot of people around HN are very religious of their frameworks...

I think the term "hacker" has two definitions around here and in the web-
development world.

* Those who are interested in the internals of the system at the lowest level (non framework hackers) * Those interested in developing and hacking the framework it self as a platform and knowing all the details and hacks on it (framework hackers).

Regarding the non-hacker just-programming-for-work people, I totally agree
with you.

~~~
Scriptor
Even in the web-development world, that might be too general of a description.

I think either type of hacker would be happy with using a framework if it
wasn't closely related to what they need to do. For example, my latest app has
a ton of Javascript code, but still needed some functionality on the server. I
used Django to get that part done with quickly. For the actual Javascript, I
used jQuery as a library, not an application framework.

As a side note, I feel Django does a pretty good job in being transparent.
Once I've got it set up, it's transparent where in the view what loads and
calls what, even if it is the loading/calling of templates and models. On the
other hand, I never did get very far into Rails.

------
dryicerx
My personal views:

Libraries are like strangers. The application and the library have a very
strict interface. They stand arms length away. If something is malfunctioning
in a library, you don't touch it, you either make the fix in application-space
or use another library. There is a very distant separation between the two.

Frameworks are like spouses.. you marry in to them. They hold you hand, set
rules, tell you how things will be done. This can be a good thing. You can
accomplish things very fast. But if something is wrong between either one of
you, you will have to get involved neck deep trying to figure out what's
wrong, and fixes need to be applies to both. Just like a marriage, it's easy
to get in to, and things progress very fast and happily, but if stuff starts
going sour getting out of one is no fun.

------
cousin_it
Obligatory link to the best ever libraries-vs-frameworks post in the history
of internets: <http://term.ie/devdev/why_frameworks_suck> .

Choice quote: _I’d really like to give you this fork Jimmy, but you’re gonna
need a knife and plate to use it._

~~~
Hexstream
Bah. Why _monolithic_ frameworks suck. If the framework is implemented as a
bunch of nicely integrated yet modular libraries that you can use standalone,
you can use the fork without the knife and plate.

~~~
natrius
Part of the benefit of monolithic frameworks is the third party tools built on
top of it. If you choose libraries independently, you've avoided reinventing a
few wheels, but there is more functionality you could avoid reimplementing
than just the basic database interaction, template system and request
handling.

~~~
Hexstream
There's a bit of a paradox here: a monolithic framework gives you less choice
because you can't use only a part of it without great pain, however you have
ostensibly more choice of functionality from third-parties since there's a
standard way to use it that's hard to diverge from.

But if you're any NIH on the side, the framework-as-bunch-of-easily-
integrated-libraries approach really makes more sense. It also lets you try a
framework incrementally, therefore decreasing risk instead of committing to a
behemoth framework prematurely.

------
draegtun
Always liked using this phrase to clarify things....

    
    
      a framework calls your program whereas your program calls a library

------
forinti
This one's easy: frameworks adhere to the Greyhound principle (leave the
driving to us) and the Hollywood principle (don't call us, we'll call you).

------
10ren
Libraries are below you. Frameworks are above you.

Unusual examples: A java applet is a framework. A SAX parser is a framework.
Event-driven GUIs are frameworks.

Any exceptions?

------
zby
Frameworks are just libraries with with complex interfaces. Simple interfaces
are better sure - but not always possible.

------
jamongkad
Which has got me thinking...if Django is a full stack framework. Then what is
Pylons?

------
edw519
My favorite thing about frameworks? Whenever I go to a shop that uses them, I
could always write something without the framework that _looks_ like I used
the framework but does things they never thought possible.

