

Another libraries vs frameworks - geekzgalore
http://dhruvbird.blogspot.com/2010/12/library-vs-framework.html

======
pavpanchekha
So frameworks provide functionality above your code, and libraries provide
functionality below your code; it's better to be limited below than above;
thus we should use libraries more than frameworks.

It's an argument I've come around to recently, but what I'd really like to see
is some investigations of what styles of though can lead to functionality that
is "scaffolding" for other code. That doesn't just provide a floor or a
ceiling, but that provides a ladder that you can hang more code from. A simple
example is Lisp conditions: they provide a hook in the code you can attach
things to, instead of just providing a baseline to code off of. Event-based
systems are another good example (whether this is a Javascript-like model, or
a Emacs-like hook model). After all, the event model of HTML gives you
enormous flexibility on handling events.

So here's a language-design question: what's a language we can talk about
hooks in? How can you make a hook-based model maintainable? Is there any way
to make hooks implicit (like advice --- though advice seems to still require
too much internal knowledge to be maintainable if used everywhere).

Maybe an Erlang-like model where you have servers pass messages, but you add
the opportunity to intercept messages? If the messages are fixed-format,
they'd hopefully be well-defined enough for the whole system to be
maintainable. And if you need security, you can use all of the now-well-known
methods for authenticating and encrypting messages. (And hopefully the vm
you're running on can make it cheaper than actually encrypting.)

But that seems like the sort of insufficient creativity endemic of Hacker News
posts at 5AM. How do we do better? Or

~~~
dhruvbird
I guess frameworks have their use cases. For example, now that you mentioned
it, the EventEmitter on node.js is a framework-kind of model where your code
is invoked when a certain condition is met. They seem to have done it
beautifully. In fact the whole runtime (environment) is event driven, so I
like to think of my application as a user of the node.js framework. However,
many a times when coding higher level requirements or ever-changing business
requirements, frameworks tend to lose their way and programmers land up
writing around the restrictions.

I guess it makes sense to have a framework when you know the requirements in &
out and you know that they are not going to change (like low-level I/O or
socket or FS stuff which has remained the same for years now), and a library
otherwise.

~~~
pavpanchekha
I'd be more interested yet if it were possible to fire your own IO events and
such --- so that you could replace the top levels of the framework, and use
the remainder as a library. So that instead of spreading your code like jelly
on a pre-built slice of bread, you instead layer your code and
library/framework code as you see fit, into a delicious cake.

------
Pewpewarrows
And like anyone who's ever tried to build a large front-end application with
_just_ a library (jQuery) will tell you: it quickly gets way out of hand and
completely unmanageable before the product even releases.

One the same note, if all you need is a quick animation when a button is
clicked, and some extremely trivial dynamic elements on the page, a large
framework like Sproutcore is going to just get in your way, and you'll spend
more time trying to learn how the hell to use the damn thing and twist it into
doing a task that's outside of its primary purpose.

In short: use the right tool for the job. The anti-framework posts to come out
of the woodwork this morning on HN are pretty disheartening. I sincerely doubt
anyone that's completely against using a framework has ever written a large
application that they need to support, that didn't end up as a giant mess of
spaghetti code stringing libraries together haphazardly.

------
nadam
Lots of people say that they prefer libraries over frameworks. I agree in that
if possible I try to avoid the overuse of frameworks. But this cannot be
decided on an abstract level, it depends on what functionality I want to use
the framework/library for. How clear it is what the framework have to do, how
mature is its philosophy about what it have to do? For example almost
everybody use the following huge and sometimes quite restrictive frameworks:

\- operating systems

\- Windowing/component frameworks for GUI (like Java Swing)

\- and of course in case of web development the browser itself.

------
scelerat
For sufficiently large projects, the choice is not "library vs framework" but
"use someone else's framework vs write my own."

If you have the time and the expertise for the latter, great! Otherwise, do
some research and understand the benefits and compromises.

------
shimsham
This is like comparing Airfix and Mecano.

