
Frameworks are for hacks, libraries for seeds - begriffs
http://sencjw.com/posts/2015-01-08-the-quick-hack.html
======
gitaarik
When you're using libraries, you're actually making your own custom framework.

Because a framework is basically a set of libraries that work together to help
you get to a certain goal.

If there's already a framework that helps you get to a certain goal, it can
save you a lot of work to use that existing framework instead of making your
own. It can also save you a lot of security issues.

But if your requirements don't really connect to the things existing
frameworks provide, you'll have to build your own custom framework by
collecting all the libraries you need and making them work together the way
you want. Maybe you can make a framework out of it so the next person that has
the same requirements as you doesn't have to go through this process again.

~~~
iopq
You call a library, but a framework calls you.

A framework IS the entry point to your application. If you use libraries you
write your own entry point.

~~~
andybak
And there's exceptions to each case.

I can see the distinction that people are trying to make here but it's far
from a binary one.

~~~
adamnemecek
Can you name some of these exceptions?

~~~
maemre
In Flask, you call the framework, then it calls you back etc. It is a minimal
framework that you can use as a library along other "plugins" (which are
libraries in fact) you like.

------
knivets
Frameworks are also good in a long run. When a new member on the team starts
to work on a project, it is much easier to pick up on some popular framework
like Rails than your own one. First, because you can easily find a guy who
worked with Rails framework and knows it inside out, unlike yours custom-
written one. Second, the whole infrastructure, like regular updates,
documentation and community is also a major factor.

~~~
grandalf
> because you can easily find a guy who worked with Rails framework and knows
> it inside out

That's only relevent when you are hiring someone to deal with the monstrosity
of a rails app that you ended up with because the abstractions didn't quite
work for the problem you were trying to solve.

I've found it very easy to use some Rails best practices in a Sinatra app and
not have to deal with all the routing/controller cruft in Rails, while still
getting sensible filesystem conventions.

------
amelius
The problem with libraries is that they might not match. For example, what if
one library you use uses another String class from another library you use.
You'd have to write a lot of glue-code to let these libraries talk to
eachother. It gets especially tricky if one library uses a garbage collector,
and another library uses a different one. You could get cycles between objects
managed by different libraries, which would never get collected (ouch!)

But in any case, I prefer that over working with a framework. Frameworks
pretend to have everything figured out, but in reality they have not, and they
are a pain to work with if you deviate the slightest from the "master plan".

Also, libraries are more easily replaced than frameworks, which is a huge
advantage. And they invite you to think modularly, rather than monolithically,
which helps to keep complexity down.

~~~
Chris_Newton
_The problem with libraries is that they might not match. For example, what if
one library you use uses another String class from another library you use.
You 'd have to write a lot of glue-code to let these libraries talk to
eachother._

This is a real problem, certainly. In very bad cases (anyone remember
programming COM from C++?) the burden of making a simple function call from
one part of your code to another can be soul-destroying.

This is why I think the modern kitchen-sink standard libraries might be
missing a trick. Instead of trying to provide everything out of the box, often
to an acceptable but not best-in-class standard, what if our programming
languages concentrated on just establishing conventions and providing
universal tools with relatively small standard libraries, and then emphasized
tools to connect different libraries from other sources together? That is,
could they make it easier not just to import modules from different libraries
but also to convert data types and match calling conventions and
initialize/close down run-time systems?

Plenty of ideas have already started down this path, from implicit type
conversions or coercion to full-blown lens libraries, simple calling
convention annotations to full-blown FFIs and wrappers, and so on. However, to
my knowledge, no mainstream language today has an explicit design goal to make
integration of multiple modules that have related functionality but different
conventions as easy as possible. I wonder how far we could run with that
strategy.

~~~
mattgreenrocks
This is the idea of my current language I'm brainstorming: modules as the
central unit of design. I want to figure out how to encourage developers to
write software as a collection of loosely coupled modules, rather than
monolithic blobs. I hope that a module-centric design would let us make
assertions about types, purity, and other FP-esque things.

Right now it's just in the "I'd like this and this" stage, but I hope to work
on it more this year.

~~~
Chris_Newton
Sounds interesting, and I wish you luck. I think if we had more and better
options for gluing together good quality modules, some of the related
arguments that push towards frameworks over libraries today would also be
diminished. Then we could make decisions based on the fundamental frameworks
vs. libraries question of you-call-us or we-call-you, without any bias from
what should ideally be independent questions of consistency and
interoperability.

------
TickleSteve
Libraries by definition have a narrower scope and hence are more easily
adapted to new situations.

Frameworks by their nature affect the whole codebase.

This is the low-coupling/high-cohesion benefit of libraries as seen in many
places in software engineering.

A codebase with low coupling is inherently more flexible and maintainable.
Libraries and well defined, sensible interfaces are critical to good
engineering.

------
Singletoned
Great article. It puts into words something that I've been feeling for many
years, but have been struggling to express.

It's not that frameworks are bad; they quite clearly have their place. It's
that they are short term hacks, and as such there is a time and a place for
using them, but they aren't a long term solution to a problem.

~~~
quaunaut
I couldn't disagree more. The more long term a project gets, the more you
should have other people on hand. Using frameworks significantly shortens the
ramp-up period for potential partners/employees, turning months or years into
weeks.

------
bwindels
I agree with the sentiment of the of the article. Dependencies should be
isolated and not spread out all across your application. Even though both
don't have tight definition, I think it's fair to say that a framework is
usually larger in scope and API surface area than a library and usually impose
a certain way of coding (and toolchain) on you. Isolating your dependencies
(gui, persistence, ...) is a lot easier when you use a small library than
using a framework that pretends to have all the answers.

It is true that you have to lay out more infrastructure yourself working this
way but I feel that this is a really good thing because it makes you really
think about the problem you are trying to solve, and don't just think in terms
of the patterns your framework offers (e.g. MVC: "I have some logic, so I'll
put it into a controller!"). This usually leads to code that is a lot easier
to understand and is easier to test. Also, every application is different and
with the framework way of doing will always end up having to shoe-horn things.

------
andrewstuart2
If indeed that's the case, then welcome to the era of the quick hack.

From the nanosecond the user hits the power button on their little box, and
the BIOS loads 0x7c00 and executes it (loosely defined, frameworks call your
code), we're in framework world.

You want your browser loaded? Better hope that the user clicks it, and the OS
calls your code, because otherwise you're malware (and you were still loaded
by the OS). Want users to visit your site? Unless you're a virus, you're gonna
have to wait for their browser to navigate there. Another framework.

The idea that frameworks are not for writing software to me is just
ridiculous. _It 's the only way useful modern software can be written._ Unless
of course you yourself have created the hardware, OS, and layer upon layer of
userland software that you're going to rely upon, you really need to
acknowledge that your code is 99% dependent upon frameworks.

~~~
forgottenpass
_loosely defined, frameworks call your code_

You're interpreting the poster by pulling the definition past the breaking
point of any utility to this conversation.

Either air your grievances with the word "framework", or try and read what the
author meant.

~~~
andrewstuart2
Alright, to be more strict, let me quote the definition per Wikipedia:

> In computer programming, a software framework is an abstraction in which
> software providing generic functionality can be selectively changed by
> additional user-written code, thus providing application-specific software.
> [1]

I fail to see how I'm stretching this definition at all, especially if you
read further into the wikipedia article. I believe it's critical that I
acknowledge when I'm wrong, lest I stay stagnant in my understanding, but I
don't think I'm wrong here, unless somebody wants to point out a specific
area.

Userland software customizes and reuses default behavior of the OS for
application-specific purposes. Web pages customize and reuse default behavior
defined by the HTML, CSS, and JavaScript specifications. Same goes for
Operating Systems on top of the BIOS and on top of the hardware itself.

Frameworks are useful, basically unavoidable, and critical to take the time to
understand if we're going to be effective at any level, be it consuming them
or providing them.

[1]
[http://en.wikipedia.org/wiki/Software_framework](http://en.wikipedia.org/wiki/Software_framework)

------
onion2k
It depends on the language. For example, in PHP there's the 'framework interop
group'[1] who are working on a set of standards that enable developers to
easily take code from one framework and use it in another (so long as it's
written to the standard). Framework modules _become_ libraries. So you choose
the framework that suits your project best, develop your code in that style,
but you're able to pull in modules from other frameworks as and when you need
them.

It seems to be a really good idea. It solves the exact problem that the author
has.

[1] [http://www.php-fig.org](http://www.php-fig.org)

------
abuilder
I’ve heard this argument over the years many times. It’s actually a hard
discussion to have the more general the terms that are used. What exactly is a
“Framework”? When does a library cross the boundary and become a Framework?
What is the original author’s definition of “develop software”? That
perspective matters here, because if what he’s saying is create a novel
solution to a problem that hasn’t been solved before, that is a lot different
from creating a webservice that inserts or retrieves some data from a
database. Frameworks are essentially just a tool to get the job done. Some are
better than others, and they come in all sizes. You really have to get
specific to have a discussion like this that makes sense. If I tasked a Java
developer with building a webservice that took some information and put in a
database, I could reasonably expect them to use some implementation of jax-ws
or jax-rs. If used properly those frame works are very powerful and
convenient. Most implementations are well documented, and the communities
around them are vast and experienced. Assuming the programmer was relatively
experienced and had somehow never heard of either of those frameworks, I might
expect some kind of servlet solution (arguably still a framework). Now if what
the author is saying is that building a webservice isn’t development, that’s a
different discussion. Many paths are heavily traveled. Using a Framework if
you have to follow one of them is taking advantage of the knowledge gained by
a large number of people that have already made the trip.

------
bovermyer
There is some truth to what the author is saying. Frameworks do tend to be
opinionated, and they will tell you to write your code in a particular fashion
to play nicely with the rest of the kids in the framework's playground.

However, I think there's more here that the author skirts around. He laments
the fact that "in-fashion" changes to a framework force you to refactor your
code. I'm not so sure that this is purely a negative thing. Let's take the
upcoming Laravel 5 as an example; on the face of it, Laravel 5 is a drastic
departure from Laravel 4.2. The directory structure is completely different,
and the way you interact with The System is changing in a subtle but
significant way (middleware). Is this cause for consternation? Perhaps. It
requires developer time to upgrade, which is not free. But the gain is
twofold: you benefit from using newer and, ostensibly better, structure around
your app; and you grow as a developer, because you learn a new way to do
something familiar.

I'm not saying here that the author's assertion that this is unnecessary is
incorrect; just that there are benefits to being forced into change.

Also, regarding libraries: just because two libraries deal with the same topic
or technology does NOT guarantee that they'll make the same assumptions about
abstraction. Even on the device driver level, you can't take that for granted.

------
DanielBMarkham
The first few truly complicated frameworks I learned were very useful. IIRC,
they were Borland's OWL, MFC, Win32/kernal stuff, and .NET internals.

They were useful because learning them and walking through code while
debugging showed me all sorts of best practices (and worst practices). When I
wanted to use the GDI I grabbed a handle, basically a hash in a lookup table
somewhere. This made sense. When I was programming custom VBX controls, I used
the USER part of the WM_ space and sent messages back and forth. Loved the
message loop paradigm.

But then something funny happened. Frameworks no longer helped me complete a
complex project, _they actually got in the way of doing it_ , by adding a lot
of intellectual overhead for very little return. I started seeing new
programmers pick up some training, start using a framework, and then get
completely lost when their work took them anywhere off the "happy path".
People would spend a hell of a lot of time learning framework X, only to
eventually realize that the next job required framework Y.

As I got older, my recall isn't what it used to be, which actually turns out
to be a good thing -- it forces me to focus on important things instead of
minutiae. I got much more radical about web apps. I'm happy with static web
pages that are interactive for most everything. I don't code things that do
deep-dives into the guts of the stack. I'm looking to provide the most value
in the least amount of time (and cognitive overhead). I moved to pure FP.

So now my order is: 1) Code it myself, 2) Use a precanned library, 3) Use a
framework

The frameworks I use are very small: JQuery, .NET, maybe one of two others. I
like it that way.

------
starikovs
It depends what you're developing. If you develop a product (startup) that
will change the world, you spend a lot of time, you put your heart into this
product, you should understand every line of code, so you develop a product
not framework. If you create site by site every week or day for your clients,
you need a framework.

~~~
erglkjahlkh
Or, what you are building requires somewhat complex components, but you'd
rather focus on something else? Many frameworks have their own component
libraries.

I'm not talking simple tooltips, I'm talking about real components. Sencha's
tree.Panel comes first to my mind:
[http://docs.sencha.com/extjs/5.0/5.0.1-apidocs/#!/api/Ext.tr...](http://docs.sencha.com/extjs/5.0/5.0.1-apidocs/#!/api/Ext.tree.Panel)

It has extremely powerful feature set (based on the other features of the
framework) out of the box and you can very fast switch your focus on other
things besides re-implementing the wheel.

I simply haven't found some of these things as simple libraries. They nearly
always come within complete frameworks, because they have had to implement a
lot of stuff that really just requires other features from frameworks. And,
no, I'd rather not spend a year implementing that feature set.

------
debacle
I wouldn't really trust a Haskell programmer to be able to identify a hack.

There are a lot of platitudes here whirling around a central point: Frameworks
are more restrictive than libraries.

But, omgwtf, that's exactly the point of frameworks - they enforce convention
in exchange for faster development. Also, newsflash, any large software
project is going to have its own conventions. Okay, so, if you're still
following me, get ready to take a leap. _What if we have conventions that can
apply to more than one project to reduce the ramp-up time for programmers to
contribute?_

The neophytes on HN eat this kind of stuff up, without ever considering that
the thing the author is whining about is exactly the intent.

~~~
mordocai
In my personal experience, with any non-trivial application with continued
(read as multiple years) of development frameworks tend to get in the way (I
want to do this, but the framework wants me to do that even though this is
better for my use case).

Building your own "framework" from a good collection of libraries tends to not
have this problem. Also, if it does have that problem (this library is getting
in my way) you can usually more easily exchange the library for a different
one.

Note that developers tend to disagree on the definition of framework. When I
say framework i'm saying something like Rails or Django that is a big
monolithic thing that your application is built upon.

------
louischatriot
That's one of the reasons I like the Node ecosytem: the culture is really
about finding the right library and designing clean interfaces so that you can
switch when you need to. Having worked with Grails in the past was such a pain
in comparison ...

------
neudabei
I think this is also about choosing your battles wisely. When you build
something new you will find it is hard. You will have a lot of flexibility
choosing how to go about it. It's not necessary to reinvent the wheel on every
front. That's why I love frameworks (Bootstrap, Ruby on Rails, templates, even
spreadsheets for business plans etc.).

Frameworks quickly allow you to go from 0-80% without having to start from
scratch. You just take something that already exists and then fill in the gaps
with your values, colors, content etc.

I agree with gitaarik that in the grand scheme of things libraries are also
like a framework.

------
mattgreenrocks
You never _needed_ a framework until recently when you had to deal with the
conceptually disjoint modern web and the pile of languages it takes to do
anything reasonably complex. We never had to use frameworks when writing
against Win32, Swing, iOS, Android, etc. Certainly, there were frameworks --
such as MFC. But they quickly fell out of favor because the structure they
imposed wasn't helpful at all. (Way back when, we figured out that the
framework superclass is an anti-pattern.)

Win32, Swing, iOS, et al aren't really frameworks in the same sense that
something like Rails is. Win32 doesn't care if you name your code something
that clashes with The Revelation Given To Great Prophet DHH; all it cares
about is that your WNDPROC behaves like it should. The OO variants of this
only care that you derive your UI classes from the framework's classes so you
can be notified of relevant events. Nor did these old 'frameworks' (as often
incorrectly stated) prescribe the underlying architecture. They didn't force
you into MVC for every single project, they didn't force you to use a database
for persistence.

Monolithic frameworks are a modern fetish; borne out of a Stockholm Syndrome
for the Business: "how will we hire easily replaceable workers?" / "how will
we spin someone up in the minimum amount of time?". The answer: programming by
MadLibs.

Developers advocate for them because they provide immediate gratification for
doing very little work. They confer a mediocre architecture on all projects,
which is perceived as preferable to the hard work of designing and
architecting a system from scratch. They are a form of blame-shifting by
developers: they can offload some of the risk and the Hard Parts of
development to a Smart Person/The Community and run to them for help when it
breaks. This is not a bad thing, but it does stunt the design impulse, and
limits their growth as developers.

In the case of Rails, choosing Rails is no guarantee of project quality, or
even conventions. Are you using Postgres, Mongo, or a combination of data
stores? If it's the latter, then AR's transactional niceties are out the
window! Are you using regular Rails views, presenters, or decorators? When you
structure your controllers, are you using The Rails Way (fat models), or
services, or more Bernhardt-esque design (app lives in lib/)? All of these
things require spin-up time to learn the where and the why.

I do think frameworks are a symptom of propping up conceptually weak
abstractions (e.g. the web) and languages. It should be concerning to you that
all the metaprogramming in the world + a fully dynamic runtime cannot produce
a framework that makes it easy to produce minimally coupled run-of-the-mill
business software that doesn't require horrendous hacks like Rails' Spring.

Buy a copy of Growing Object Oriented Software, Guided By Tests. The author
builds something sans framework, letting the construction of the software
guide him to the best design. The resulting software is lean, supple, and easy
to extend.

~~~
peterwwillis
Frameworks are not modern inventions.

If you work in a company with 10 different teams that all do different things
and all need to develop different applications _that work together_ , you need
a framework.

If you want to leverage an existing fully-functioning suite of interoperable
function abstractions to extend a small amount of custom behavior in a minimal
amount of time, you need a framework.

This whole article is ridiculous because it's essentially comparing using an
existing product to developing a new product, and calling the former a hack,
and the latter some sort of higher art form.

Also, of course Win32, iOS and Android aren't a framework - they're platforms.
You still have to build a framework for the platform. And Swing isn't a
framework either, it's a toolkit; you use it to write software for a
framework.

------
hasenj
That's very well put! I think it's the same for me; I just haven't been able
to verbalize it so fluently.

------
zby
I have another quip about that "Frameworks are framing, libraries are
liberating" :)

------
xutopia
Roundabout way of justifying the reinvention of the wheel.

