
Why I Hate Frameworks - gavingmiller
http://discuss.joelonsoftware.com/default.asp?joel.3.219431
======
sambeau
This comment totally missed the point:

    
    
      A good framework is nothing more than your toolbox 
      filled with a good selection of tools.  Some tools are 
      very general purpose (standard claw hammer) while others
      are very specialized (roofing hammer).  Having them all
      available and knowing when to use them is half the battle.
    

No, sir. That is a good _library._

~~~
rickmb
No, sir. That is a framework you may not be familiar with.

There are frameworks specifically designed to be modular, and of which 90% can
be used as a library, without being forced to apply it's MVC or scaffolding
bits.

The line between framework an library is a blurry one in a world where
"framework" does not equal "Rails".

~~~
techiferous
Framework: it calls you.

Library: you call it.

~~~
biot
BenjiSmith puts it similarly in a comment halfway down:

    
    
      A library is something *contained* within my code.
    
      A framework is a *container* for my application.

~~~
Retric
That distinction only has meaning when passing functions around is hard.
Nobody call simple chart generating library's frameworks even if they have
large numbers of call backs to your code. At the same time it's easy to find
actual web frameworks that are instantiated by your code which may spawn
unrelated processes at the same time.

------
dools
The most important statement in this article is near the beginning, and it's
still relevant today:

 _"I've done small woodworking projects before, and I think I have a pretty
good idea of what I need: some wood and a few basic tools: a tape measure, a
saw, a level, and a hammer."_

The reason I hate frameworks (even things like Django which is very easy to
get started with) is that, at some point, I'm asked to re-learn a different
way of solving a problem that I've already solved in the past.

I've been doing lots of thinking about this having written the Great American
PHP Framework myself, and worked with other people's frameworks, and also
worked a lot in the CMS space and the biggest conclusion that I've come to is
that the best tools are those that enable you to do things faster or more
conveniently but don't actually provide any abstraction.

For example, when deploying a website there are any number of tools to
"abstract away" the HTML layer - templating engines, markups, markdowns etc.
etc. but the best way to build HTML is using HTML and testing in a web
browser, always.

When you need to write some code in whatever web framework you're using to
handle a POST request, you want to be as close as possible to the HTTP layer
without a bunch of arcane systems in between you and what you and the
underlying technology.

Sure it's handy to have tools which automate some repetitive aspects, but if
you understand the underlying principles and you know the syntax of the
language you're working with, you should at all times be able to just "get it
done" however you know how without reading endless documentation and
shoehorning your knowledge through a bunch of layers of abstraction.

The same goes for ORM - I want convenience of access to my data, and some
automation to handle some of the more boring aspects of writing SQL, but I
need to be able to mix and match (yes I know most ORMs allow you to use raw
SQL, but it's always one or the other - the ORM or the SQL - I've never used a
tool that has a simple method for me to extend the ORM bits halfway through
the query building process with some custom SQL).

This is my zeitgeist now and it pervades all the projects I'm working on.

[1] <http://www.decalcms.com/>

~~~
dasil003
> _The reason I hate frameworks (even things like Django which is very easy to
> get started with) is that, at some point, I'm asked to re-learn a different
> way of solving a problem that I've already solved in the past._

Yes but it cuts both ways. The reason people hate maintaining _your_ code is
because they have to learn the way you did things which is buggier and half-
baked compared to the way that any number of battle-tested open source
frameworks did it. Not because your way isn't good, but because it just
doesn't have the mileage yet.

> _the biggest conclusion that I've come to is that the best tools are those
> that enable you to do things faster or more conveniently but don't actually
> provide any abstraction._

An interesting conclusion, but not nuanced enough. There's no escaping the
need for abstractions, obviously there are some that you're taking for granted
here such as high level programming languages and operating systems. Fair
enough to set those aside.

But then once you get into serious application-level territory you still have
to decide where to abstract. Some abstractions are more leaky than others,
some are more restricting than others. The art of it is figuring out which
make sense in what scenarios. A really good framework hits the right
abstractions for a wide range of applications, but even within your custom
application you have decisions to make.

For instance, you're one-helper = one-html tag rule of thumb might be a good
idea if you have 5 forms on your website. On the other hand if you have 500
CRUD forms all with a bunch of repeated composited HTML structures then it's
probably not such a good idea.

I think what's underlying your conclusion is that you've seen too many
frameworks that are way too complicated for the problem at hand. That's
clearly what the OA saw, and that was really the selling point that launched
Rails rise to prominence in the J2EE era. Modern web frameworks have really
learned this lesson. Granted, Rails has gotten more enterprisey over the
years—but not gratuitously—Rails core has demonstrated remarkable restraint
over the years, and kept the focus on solving the 80% problems elegantly.

But if something like Rails really is too much then you have micro-frameworks
like Sinatra that really just give you the barebones structure to wire some
code to a web server. Heck, due to the modularization of Rails and the
extraction of libraries where applicable (eg. Rack), you can now avoid a
formal framework entirely and still utilize a massive amount of code that was
originally written in frameworks, now in stand-alone library form.

When programmers trot out the old adage "use the right tool for the job", one
of the main points is to avoid the human tendency to over-generalize. To be
the best programmer you can be, you should be constantly re-evaluating your
opinions about the "right" and "wrong" way to do things. Rather than forming
concrete opinions, it will serve you better to understand the pros and cons of
any approach so that you can effectively apply your knowledge new situations.

~~~
colin_jack
I'm fairly new to Rails but had a question triggered by all this
library/framework discussion, when you do want to move beyond the 80% does it
let you do that elegantly?

~~~
ollysb
Rails is comfortable beyond the 80% because it's abstractions are deliberately
'leaky'. In practical terms this means it's very easy to work with raw
SQL/HTML where required.

------
salsakran
I think it's hard to appreciate the post if you haven't worked in J2EE land
back in that era (2005). Just reading that gave me bad flashbacks.
"Frameworks", especially on the webstack side of things have gotten a lot
saner over the years.

I imagine if he had seen something like Play!, he'd have a very different
opinion.

~~~
abrimo
Yea, I was researching frameworks for our software (<https://mijura.com>) and
I had all but given up on Java until I found play framework. It's like Ruby on
Rails meets Java, very well designed and the views are in Groovy.

It's also under active development and the community is quite strong.

------
erikig
That's why I like raw PHP, Python or Perl. In the era of Hammers, Hammer
factories and Hammer factory factories, its always convenient to have a nice
useful rock.

------
Volpe
"I'm currently in the planning stages of building a hosted Java web
application..."

Seriously, people are starting NEW projects with Java as the language of
choice? Despite the plethora of 'better' languages you can run on a JVM.

~~~
ecopoesis
Why the hate on Java? Sure it's not sexy, but:

1) Almost everyone knows it so hiring is easy. 2) There's a very large
community that supports its tools, infrastructure and libraries. 3) It's
faster then almost anything else out there. 4) It has migration routes (via
Scala or Clojure) to sexier languages.

As far as I can tell, the only drawbacks to Java are that it's not cool,
that's it's verbose and that's it's ugly. Any half decent editor or IDE takes
care of the verboseness issues, leaving just cool and ugly, which really
aren't good criteria for picking a language. Java was once cool too, and
someday Ruby or whatever the current hotness is will also become uncool.

~~~
eropple
I find Java more difficult to work with than I do Scala, Python, C#, etc.
mostly because of the lack of expressiveness. Even just the lack of first-
class functions (or delegates) results in very ugly patterns designed to get
around the fact that Java is--well--not expressive enough.

ThingBuilderFactoryActionMethodObject is a certainly an exaggeration, but not
_that_ much.

------
auganov
For me the biggest benefit of a framework is that other people use them. Makes
it easier for other people to work on your project with you, reduces the time
necessary to adapt. If the turnover of people is huge this benefit can really
come in handy. Strange nobody notes that.

People that get hurt most are those that believe a framework is a short-cut to
learning how to do certain things. You absolutely need to know what's
happening under the hood.

The benefits to a developer that is working by himself might be very small if
there are any. I guess it depends on how high-level we need to go.

------
hakunin
I'm going to have a bit of fun here. I have known two types of developers. The
ones practicing creation magic and the others, specializing in alteration.

When creation mages see a problem, they create a solution. The power of their
mind allows them to come up with the exact thing that needs to be created for
the given problem. Their creation skills are honed so well that they get
incredibly fast. They don't need to look around much since there's no point in
paying attention to what they have created before. Their old creations already
solved their problems, they work, they don't have to be disturbed again. Of
course creation mages are not stupid, they simply tend to focus on a direct
path towards a solution. If some mana could be easily saved by using something
already created, they certainly wouldn't pass it up. They would reuse what
they've already built. There are just way too many things around them, and
it's hard to determine if something fits. After all, they have to keep going
without delays. A good creation mage has learned to keep things sufficiently
neat. They frequently remember things that they could reuse here and there.
However, when one observes any such mage at work, one often sees a lot of
mess. Some of the mess has occasional patterns, some things are
interconnected, but for the most part it's a very complicated and disconnected
system of various moving parts working autonomously to solve their individual
problems.

Alteration mages work a bit differently. They are often slower than creation
mages, especially in the beginning. That's because they spend quite a bit of
time studying their surroundings. They take longer to solve a problem. The
thing about alteration mages is, they can't handle mess. (They are accustomed
to altering, not creating.) There is a certain compulsive quality to their
mind, they simply can't relax in the presence of something unnecessary, when
something could be altered instead. You'd often see such mage cleaning their
workspace leaving it neat and stripped to bare minimum. They don't have many
things in their possession, but spend a lot of time learning about potential
things out there that they _could_ have if they wanted. Alteration requires
deep understanding of systems, something that can never be quite mastered due
to such huge variety of abstract models. That's why alteration mages grab onto
every opportunity to learn about a new sample system, a way things could be
arranged, patterns, frameworks. When a problem arises, they don't simply
create a solution, they build a system which naturally causes that solution to
occur, along with keeping all the existing problems solved. In other words, if
plants don't grow, alteration mages would try to augment their biosphere in a
way that achieves harmony, while creationists would simply generate some
water.

Both alteration and creation mages gain experience, level up, and become more
valueable. However, they learn slightly different skills. Creation mages learn
to have high morale, learn to be calm, and treat solutions as black boxes.
They learn to trust their own judgement. Alteration mages on the other hand
learn a pretty crappy lesson. They learn that most of their decisions turn out
to be incorrect. They build out a system and suddenly get attacked with a
problem which the system can't accommodate. It happens once in a while, and
they struggle to have everything redesigned from scratch. They end up burnt
out, because they can't give up their quest for minimalism and elegance. Yet,
it's not all that bad.

You see, alteration mages have a very important advantage. They always tend to
record their practices and principles. Old and experienced mages would pass on
their knowledge to the newbies. The newbies would build upon it to improve
elegance of their systems. In essence, an alteration mage is never a lone
warrior, they are always standing on the shoulders of the giants that came
before them, which is what makes them strong. One of the first things a newbie
alteration mage learns is that what they think is right will soon turn out to
be wrong. They are too inexperienced to take the multitude of fairly common
scenarios into account. At the same time, they quickly learn to be patient.
When an elder passes down certain knowledge or framework upon a newbie, it
will not be immediately obvious why things have to be the way they are. After
some time they finally see that the knowledge of elders has already accounted
for so much and in such an elegant manner that they don't need to worry about
these problems any longer. They've already been solved by elder alteration
mages in the cleanest ways possible, polished by generations of mages that
came after them. Some newbies would rebel, against the elders, but only a few
lucky ones actually manage to contribute anything useful, albeit this drive of
ambition, trial, and error is often what causes major advancements for the
whole guild, akin to the evolution process. Eventually, alteration mages
manage to outperform their creation colleagues while leaving clean and elegant
systems behind. They would sometimes cringe looking at poor creation mages
gluing together half-baked solutions to things that are so deeply understood
within alteration circles. Their pools of mana are not nearly as deep as of
these performant creation wizards, but mana pools are just a small part of
their power. Majority of it comes from the knowledge of frameworks. Certainly,
if a problem is completely out of ordinary, they may resort to some creation
magic, but for the most part you can count on them walking that extra mile
towards finding a well-integrated solution.

~~~
loup-vaillant
Brilliant. I always liked to see programming as a kind of Hermetic magic (you
write incantations, and they do something for you). But I never went as far as
to think about _schools_ of magic.

I have one issue with your classification however: I can't see where I fit:
first, I have little mana. Second, I find alteration magic _extremely_
difficult. I simply cannot comprehend more than the smaller artefacts,
especially when they have flaws, or when scrolls about them are scarce.

The USSM[1] web site compiler probably represents me best. I wanted to solve
the following constraints: control over CSS and HTML, clean URLs, comments are
optional. I looked around, heard about Jekill, read some scrolls, and then
immediately thought "scrap that, I can do simpler". The current result is less
than a 10 feet scroll (~350 lines), and I plan to shrink it further.

Overall, I am obsessed with systematically crafting the smallest artefact that
could possibly work. I love the UNIX philosophy: it let me activate extremely
powerful artefacts with very little mana of my own. More often than not, I
only have to craft a small ring to bind them all to great effect. My ideal
would be something like the STEPS project. And I don't know where it could
possibly fit: it looks like powerful creation magic, only with next to no
mana.

[1]: <http://www.loup-vaillant.fr/projects/ussm/>

------
schiptsov
Framework is a thing that should emerge as a result of your own project long
after its launch (after major evolutionary changes/rewrites based on actual
usage feedback). It is your team's encoded skills and experience.

People who are trying to choice a framework by browsing trough feature lists
(not even the code) before they have a working prototype (which means
understanding of actual algorithms and data structures) are doomed. ^_^

People who're trying to sell you a piles of code "you really-really need" such
as J2EE are just cheaters.

btw, no one prevents you from copying the code from any codebase you like, but
only if you can read and understand it. My favorite example is libnginx.so -
just better APR. ^_^

~~~
praptak
_"Framework is a thing that should emerge as a result of your own project long
after its launch (after major evolutionary changes/rewrites based on actual
usage feedback). It is your team's encoded skills and experience."_

This, expressed by Martin Fowler:
<http://martinfowler.com/bliki/FoundationFramework.html> and
<http://martinfowler.com/bliki/HarvestedFramework.html>

------
chucknthem
Did anybody else read the factory factory story analogy and thought of the
genie/meta genie analogy in Godel Escher Back?

------
timinman
This is why I prefer Sinatra over Rails.

------
ChrisArchitect
the whole 2005ness of this post, which I just discovered after reading the
whole thread here, renders it mostly useless to me. I get what J's saying
about the evolution/de-evoluion of frameworks - but wow, in the time since,
things have played out differently.

~~~
rbanffy
It's 2011 and I don't see much sanity in the Java projects being churned out
by some of my colleagues.

What frightens me the most is that they honestly think they are doing it
right. They really believe Maven is sane and that Hibernate generates good
SQL.

Some of them even say "of course we are using Java - what else would we use?"

------
trustfundbaby
timeless. I still remember reading that when it was first written years ago
and being in awe.

------
m3thos
classical argument of frameworks vs libraries.

------
perfunctory
This is one of my most favourite passages on the web.

------
jowiar
What was the state of "frameworks" in 2005, particularly in Java-land. Struts?
Spring? Anything that didn't make you want to gouge your eyes out?

Even outside of Java-land, Rails had yet to hit 1.0, and Django was just
starting. The evolution of the framework has come a long way in 6 years, and
frameworks have become less "one size fits all" and more task-appropriate.

I think a more appropriate title for this post is: "Why I Hate circa-2005 Java
Frameworks"

~~~
harisenbon
Knowing this was from 2005 would have been helpful. Having the date be written
at the very bottom of the article didn't make things any better.

While many of his points are valid, his comparison of carpentry to using a
framework takes a very select view of what goes into building something. Of
course you need a hammer to build a house, just like you need an if-else
statement to build a webpage.

If you're building a 10 page webapp (spicerack ) you probably don't need a
framework. If you're building a full-fledged web-system (house) you don't
_need_ a framework, but you'll be much more productive for having one.

~~~
yxhuvud
Need a framework? Perhaps not, but I'd still use Sinatra for problems of that
size since it helps keeping simple things simple.

------
MostAwesomeDude
The problem here is that frameworks all operate on different levels, with
differing amounts of abstraction, and at some point, you _do_ want that
generic, powerful functionality.

To perhaps extend the metaphor, if I want to build a spice rack, I don't want
to go out into the forest, determine which kind of tree will produce the
correct kind of wood, cut it down, trim and plane my planks, and all the other
steps which are entailed by wood acquisition. I just want to go to my local
hardware/home improvement store and request precut wood.

This poster has gone ahead and made assumptions about the nature of resource
acquisition which massively simplified his workload and which people normally
take for granted in modern life, and as a result, his spice rack will get
assembled much quicker. I'm choosing the networking stack as a reasonable
example of a framework niche which generally fulfills people's needs without
getting in the way and causing the problems he's talking about. Node, Event
Machine, Twisted, MINA, etc.

~~~
anrope
Good point about there being different levels of frameworks/tools.

What's important is using the right tools for the job. Sometimes you might
need the high level, very abstract framework, but it's not cool if that ends
up being the only tool available.

------
babel17
I think this falls into the category "As simple as possible, but not simpler".
Doing abstraction right is a very hard thing indeed and requires the right
training and education. None of the creators of the current frameworks have
had those, and therefore their creations may be brilliant, but flawed. When an
abstraction is done right, you won't feel any pressing need to go beyond it.
When it is not done right, you are happy that at least it is "leaky", but
calling this leakiness a feature just misses the point in the first place.

~~~
tintin
Totally agree. Some time ago I saw a html template engine with something like
this:

    
    
      $framework->outputTextInput("name", "value", "class");
    

And after running +50 lines of code this would be the output:

    
    
      <input type="text" name="name" value="value" class="class"/>
    

It had nothing to do with keeping the state of the app or something, just
outputting HTML...

------
JackDanger
There's some good stuff here but it's mixed in with some truly sick casual
sexism. Unfuckingacceptable.

~~~
knieveltech
What, you prefer formal sexism? (burn karma, burn)

