
Why I hate frameworks (2005) - richerlariviere
http://discuss.joelonsoftware.com/default.asp?joel.3.219431
======
zeveb
This article really clarified it for me when I first read it (along with
another I can't find, about libraries & frameworks; all the ones I've googled
are too recent to be right), and helped me realise that what I want to do is
write code that calls, not code that is called. I want to own main().

As an aside, I really miss Joel on Software and the similar high-quality blogs
which existed in the mid-2000s. It seems like Twitter, Facebook and Medium
have sucked all the air, the life, the joy and the quality out of online
presence and discussion. I know that there are still a few holdouts trying to
keep things going, but … it seems to be a losing battle.

~~~
TeMPOraL
> _and helped me realise that what I want to do is write code that calls, not
> code that is called. I want to own main()._

It took me a while to clarify this in my head, but I feel exactly what you
wrote here - I want to own main(). A framework is something that calls your
code. A library is something you call. I avoid frameworks whenever possible.

~~~
m_mueller
What about frameworks that let you keep main, but require to take over your
build system? I admit I'm guilty of one of those as well [1], but only because
I don't see a more simple solution in terms of usage.

[1] [https://github.com/muellermichel/Hybrid-
Fortran](https://github.com/muellermichel/Hybrid-Fortran)

~~~
TeMPOraL
To me this looks closer to library than framework, by the virtue of augmenting
your code instead of hijacking the control flow completely.

------
MrLeftHand
This stood the test of time. After ten years we still struggle with the same
issue.

Of course now we have containers to store these factory factory factories.
Which makes it easier to store and handle and now you can deploy the factory
factory factory containers next to the resources held in containers as well so
you don't have to pay for the shipping cost of the said resources. Of course
the finished hammer, wood and everything else still has to be shipped to you.

And if that wasn't enough, we created a self-contained mini factory for your
home, which takes the packaged hammer, nail and wood components and assembles
them real time. Just for your convenience.

Of course this mini factory has to be assembled as well by your factory
factory factory containers before it will be shipped to you.

See how easy it is?

------
noelwelsh
This is really a critique of J2EE. This was the dominant approach when Rails
came out and helped make Rails so successful.

Making specific critiques of specific eco-systems is valid. E.g. Java back
then was awful. JS right now is complex (though I think there is some great
stuff in there). Making sweeping critiques of all frameworks is pretty stupid.
Unless, of course, you build everything on an OS you wrote yourself in
assembler. Frameworks are just a form of abstraction. Abstraction can be done
well or poorly, but to make a blanket claim that abstraction is bad is to
ignore the huge efficiency gains we've make from abstractions like operating
systems, web browsers, HTTP servers, and so on, which are all frameworks of a
kind.

~~~
geebee
Interesting you should mention this. I've really enjoyed and really hated
programming over the course of the last 15+ years. A low point for me was
Java, Spring, Struts, Struts 2, Wicket, Tiles, Hibernate, JPA, iBatis, Ant,
Maven...

Interestingly, Rails (along with a few other really good technologies, such as
django) came along and, with a loud crashing sound, swept everything off the
table. It's been a lesson for me. First, have the conviction to keep doing
things the "old" way if the new way seems to be a churning mess. Second,
realize that things may not settle down, they may be completely swept aside
instead.

This is how I feel about javascript for the moment. I actually don't think the
churn will resolve. It's more of a feeling, so I can't blame anyone for
dismissing the rest of what I have to say... but I just sense that, like the
J2EE world, that something is going to sweep this all aside.

To go even further out on a limb, I believe that (buzzword alert) languages
transpiled to isomorphic javascript will play a huge role in this.

I truly don't believe that because Javascript runs so well in the browser, and
if you have to use javascript you may as well write the backend in javascript,
means that languages like ruby and python are destined for legacy or niche
status. It is immensely reasonable to prefer to code web apps in ruby or
python. I think that the dominance of JS will be a temporary situation, and
that various technologies that allow people to code for the web in a
consistent, relatively simple, straightforward way, in languages that are not
JS, is likely to emerge over the next 5 years.

I'm only keeping a toe dipped in the JS waters right now, because I really do
need it for some things. But I've decided to drop out of the JS churn (I do
recognize that for the next few years, there will be amazing opportunities for
people who are willing and able to keep up with it). Just like I wish I'd had
the conviction to stay out of the nuttiness of J2EE a decade ago, I'm trying
hard to position myself so that I don't have to get swept up into the JS
vortex.

~~~
marcosdumay
> This is how I feel about javascript for the moment. I actually don't think
> the churn will resolve.

I still hope we'll see large adoption of WebAssembly (or WebAsm, or something
like that) and get actually good frameworks for creating pages, that actually
integrates the frontend with backend (instead of just using the same
language), interpreting our templates into something dynamic.

I hope in a few years we can start retiring JS like we are doing wit PHP now.

~~~
rch
WebAssembly does seem to have a promising future, with the caveat that it
needs to get traction beyond the web to really take off (which is the goal -
[https://github.com/WebAssembly/design/issues/249#issuecommen...](https://github.com/WebAssembly/design/issues/249#issuecomment-119020064)).

~~~
marcosdumay
It's an interesting goal, but I'll disagree on that "needs" part. It can be
widely successful just by being some VM you cross-compile to when you want
your code to run on a browser.

------
collyw
Is this only a problem with Java frameworks? (The hammer-factory-building-
factory talk leads me to believe that).

I stared learning Django a few years ago and have never looked back, it has
increased my productivity loads. Admittedly its reasonably opinionated about
the style of app you are building (but it covers the majority of apps and you
don't need to use every part of the framework).

~~~
zeveb
> Is this only a problem with Java frameworks?

No, but Java is notable for this problem. I think the root issue is that it is
of course possible to write flexible software in Java, but in order to do so
you must write all the dynamic bits in this static language, which ends up
meaning that everything you write has to conform to an external
statically–implemented-dynamism framework, and if you're going to have a
framework then you might as well add to it, and … you end up with a standard
Java app.

I haven't programmed in some of the cooler/reputed-to-be-better static
languages like Haskell or the ML family (not beyond a few simple exercises,
anyway), so I can't say to what extent they would suffer from this same
problem if they enjoyed the same popularity.

I think that from the perspective of two decades on, Java turned out to have
been a failure, not with respect to popularity but to quality. It turns out
that it enabled mediocre software architects to spend great quantities of
corporate money coming up with mediocre designs to be implemented by mediocre
programmers, resulting in mediocre software and mediocre return on investment.
That doesn't mean that it's impossible to write high-quality Java, just that
that's not the norm: the entire Java ecosystem militates against quality,
because quality is risk, and Java is not about risk: Java and Java-using
organisations prefer predictable mediocrity to excellence. That's not even
necessarily bad — sometimes predictable mediocrity is preferable to risk — but
it's certainly not inspiring.

I too used to really like Django; I spent about six years using it for one
project and another. Were I going to do Python web development again, I'd
probably use Flask or Bottle, but Django definitely taught me a lot.

But I'd prefer not to do Python web development in the future.

~~~
algesten
I think part problem is also that many programmers tend to gravitate towards
abstraction and reusable code before there is a clear need for it.

Just today I read about this project
[https://github.com/primus/primus](https://github.com/primus/primus) and it's
a point in case. A "universal wrapper for real-time frameworks" with the main
benefit being "Effortless switching between real-time frameworks by changing
one single line of code."

Because clearly, I often need to switch between WebSockets and
BrowserChannel... or wait, do I?

~~~
seibelj
The documentation is more lines than the actual code is. Essentially it
provides a uniform interface to multiple socket libraries. Why you would need
this... I have no idea

------
escherize
We build complicated software with simple tools where I work using Clojure.
There's even a talk about Java:Powertools::Clojure:Handtools! [1]

[1] -
[https://www.youtube.com/watch?v=ShEez0JkOFw](https://www.youtube.com/watch?v=ShEez0JkOFw)

------
OddMerlin
The whole killing girlfriend thing is not so cool. I would remove those
pieces, they don't add much to the story.

~~~
joshuahaglund
Those parts detract from an otherwise clever story. Among the many reasons
women might be uncomfortable in software -- dudes who joke about killing them.

~~~
WaxProlix
Even the unspoken assumption that the reader is male (okay, or lesbian) and
will furthermore chucklingly identify with having a bitch ex to kill with a
hammer is gross.

------
ufmace
Interesting that this post seems to be dated right around when Rails was just
getting popular and starting the "next-generation" web frameworks trend.

------
jondubois
Pretty funny but I think that the article is overcomplicating it. In reality,
each framework is more like a toolbox; and each toolbox is suited for a
specific range of jobs.

Building an app without a framework can sometimes feel like buying a nailgun
and nails separately - It may be difficult to find the right kinds of nails
which are compatible with that specific nailgun (if they exist at all)!

If you use a framework, you'll get the nailgun with compatible nails and a
bunch of other related tools... You might not use all the tools from the
toolbox, but at least all the tools work well with each other.

Of course, if you have to perform a double heart bypass surgery on someone and
you come equipped with a carpenter's toolbox; the outcome will be
disappointing... Regardless of how good a surgeon you are.

~~~
cestith
I think the article overcomplicating things a bit was a meta joke on the topic
itself.

------
thewhitetulip
This article has been a pivotal point in my life. It was years ago when I read
this that I started looking out "how to develop a webapp without a framework",
my journey took me to Django, RoR, node and finally to Go.

I did learn on my own by reading a few books and countless videos about how to
write a webapp without a framework. The result was that I wrote an
introductory book for my own reference, the link is here.

[https://github.com/thewhitetulip/web-dev-golang-anti-
textboo...](https://github.com/thewhitetulip/web-dev-golang-anti-textbook/)

I do not know the author, but I would like to thank him/her, it is because of
their article that I went on to learn Go.

Thank You!!

------
joesmo
Too bad building software isn't at all like building a spice rack unless
you're taking about continually rebuilding a spice rack and replacing its
components constantly till it turns into a house (as 99% of software is wont
to do).

~~~
quantumhobbit
Maybe it should be more like building a spice rack instead of a house. The
whole UNIX philosophy of simple programs that do one thing well was successful
for a reason.

~~~
TheOtherHobbes
Or it would have been if the programs really were simple, and not a wild mix
of itty bitty trivial doodads and monsters with a huge collection of switches
for special cases and extra features, many of which were added and used by
exactly one person, collected into non-standardised toolkits which differ
significantly across every single variant, and often between versions of the
same variant.

And if they really did one thing well. Which - not infrequently - they don't.
(See also: critical bugs in ssh, etc.)

And if they didn't have unintuitive names that are impossible to guess.

UNIX isn't just not a spice rack, it's an entire industrial area of tool
sheds, grouped with absolutely no foresight or consistency, and impossible to
get around without expert assistance.

It kind of works if nine square miles of warehouses connected by bicycle paths
with free paper maps of small disconnected areas is your idea of a fun thing.
But it's a bit of a stretch to call it an unqualified success.

------
macawfish
I first learned to code by following those lovely, magical Ruby on Rails
videos back in the day.

A few years later I discovered Sinatra and felt liberated.

------
yandrypozo
After 11 years, I can say Why I hate frameworks and Why I love Go
(www.golang.org) \o/

------
VOYD
sofaking right on, especially these days.

------
eyelidlessness
Is anyone else bothered by the repeated, completely out of context reference
to murdering women with a hammer?

~~~
to3m
I just assumed the author had split up with his girlfriend, she turned out to
be insane (poisoned his cat, set fire to his car, accused him of all manner of
unspeakable things, etc.), and he was still a bit sore about it.

~~~
eastbayjake
Joel Spolsky is openly gay so I think it's just a dated joke

~~~
to3m
Sure, but the post is by some random guy on his forum.

