
Why I hate frameworks (2005) - lkozma
http://benjismith.net/index.php/2005/09/30/hate-frameworks/
======
_delirium
He hits mainly on the layers of complexity and abstraction, but the biggest
problem I have using frameworks is the inversion of encapsulation and control.
When I want a hammer to stick in my app, what I don't want is a big Hammering
Framework that wants _my_ app to go inside of _it_. It's particularly
problematic if you want both hammers and saws, and both the Hammering
Framework and the Sawing Framework want to be the top level.

~~~
lkozma
Exactly, that's why I always prefer libraries over frameworks.

~~~
binspace
I prefer creating customized frameworks from libraries. I tend to know more
about my particular problem than any generic framework writer.

Also, I can focus only on the solutions and features I need. I often don't
have to build for the super general case, which often results in a simpler
framework that helps rather than hinders.

~~~
troels
Important point there.

Frameworks are not to be avoided, but generic frameworks are very dangerous,
so usually a custom framework, built with generic libraries, is the better
choice.

~~~
lkozma
But then you are just one abstraction step away from creating the generic
framework framework that can spawn custom frameworks as needed.

~~~
binspace
Yes you are, and you can choose to go down that path or not.

------
lkozma
The reason why I submitted this (beyond the fact that I totally subscribe to
his views) is to ask if anyone knows something about this guy. I used to
follow his stuff, especially the 30 ideas in 30 days, then he stopped posting
2 years ago.

~~~
smanek
I worked with him at an AI-focused defense contractor in Cambridge till about
a year ago (when I left). He's a pretty cool guy - what did you want to know?

~~~
lkozma
I was just curious if his Desktop analytics idea worked out, although I
suspect he abandoned it.

~~~
smanek
He was still working on it (during his free time) as of an year ago.

------
zacharypinter
The layers of abstraction for Java projects are getting almost comical.

I'm sure there's good reasons behind it, but setting up logging for a Java
backend a while back was pretty crazy. Ended up choosing logback as the logger
implementation, sl4j as the logger abstraction layer, and then added log4j and
commons-logging replacement jars that emulated those API's and redirected them
to sl4j, which redirected them to logback.

~~~
kunley
Yes and that's why many Java applications esp. in the corporate world _are
slow_ , contrary to the common belief.

When I say many/most software written in Java is slow, people tend to laugh
and direct me to the shootout benchmarks. This is actually sign of ignorance
of what's really going on in the wild, which you can learn at operations btw.
You don't put your stack of dependency injection, loggers and ORMs into a
microbenchmark like shootout, while you do it for the typical Java web
application. The insane amount of calls on stack - tens of thousands and
above, and the insane amount of small classes which all have to be managed by
classloader, takes your app out of cpu cache, takes your files out of os file
cache, pumps the enormous memory usage, stresses the gc and causes your JVM to
have its crawling moments - or crawling standards.

So it's not that JVM itself sucks, but the stuff you typically want to run on
it makes it a horror.

~~~
WTFpeepul
I respectfully disagree that frameworks are causing corporate java
applications to exhibit poor performance. I've never seen evidence of it. The
extra layers of abstraction added by the framework certainly do slow things
down, but in the corporate world it's the database that has the biggest impact
on app performance. The microseconds spent executing a few extra commands is
negligible. Bad programmers will always create poorly performing software and
the corporate world is full or bad programmers who are using frameworks. To
place the blame on the frameworks and not the programmers is misguided in my
opinion.

~~~
dfox
it.s combination of factors: most custom software vendors combine pretty
incompetent programmers (on average) with crappy inhouse frameworks built by
these programmers.

------
dreur
Hahaha I love that sentence : In the process, I’m evaluating a bunch of J2EE
portlet-enabled JSR-compliant MVC role-based CMS web service application
container frameworks...

Just Wowwww :)

~~~
teilo
Is it bad that that sentence made perfect sense to me?

~~~
kunjaan
Can you please explain what it means?

~~~
aaronblohowiak
How technical are you?

------
InclinedPlane
I've read this before and it's an excellent diatribe. However, it's as much of
a knock against Java's limitations as it is against frameworks in general.
Frameworks in other languages are not nearly so onerous or convoluted.

~~~
forinti
I don't understand why this culture of making things ever more complicated has
grown up around Java. I've given up using these trendy frameworks and make do
with just Struts/Tiles and plain JSPs. I've recently rewritten an application
that used Oracle ADF and it came out 10% the size of the original.

What I've found is that many IT departments feel pressured to use Java but
don't really want to learn Java, so they try to find an IDE that will let them
build the GUI without coding and a framework that will turn most of the job
into configuration through XML. The result is that the solutions are a lot
more complex and people hate Java.

~~~
superuser2
But.. but... but... we're an Enterprise! Any language that doesn't require
writing a Dao and a DaoImpl and a Service and a ServiceImpl and a Controller
and a ControllerImpl and an extremely verbose JSP template and about a hundred
lines of XML to do something trivial is a toy!

I don't care if YouTube scales to hundreds of millions of users with Python,
our 200-user website is _mission-critical_ and demands _scalability_!

~~~
boyter
The above comment describes everything I work with on a day to day basis at my
job. Every solution contains multiple layers of abstraction from the aspx to
the code behind, to a controller to multiple services to multiple daos and
with all of them implementing something to allow for testing.

Except very little is tested (its getting better) and everything is so tightly
coupled it dosnt make a difference anyway.

~~~
arethuza
I once had to try and salvage something useful from a huge J2EE application
where the development team were obviously as they say "taking the p*ss".

At one point I counted 23 layers of abstraction between the fairly simple JSP
page through EJBs and a connector to eventually make a simple SOAP call to get
the data to go on the page. Everyone of those layers had an interface, a
factory and an implementation....

~~~
arethuza
Some of the source code was missing too - so I had to decompile great chunks
of stuff and wade through the resulting code to find out what was going on.

Imagine my delight when I found multiple jar files, all with the same name but
with different contents, all included in the classpath for WebSphere.

Something like 98% of the code did nothing useful.

------
api
Frameworks are like crack. At first they make things feel great and quick and
easy, but eventually the framework forces you to work _around_ it and adds
layers of complexity. It invades your application and forces you to do
elaborate dances when you need to do something a bit differently than the
framework thinks you should do it. Eventually you wind up spending more time
fighting the framework than writing your app.

Rails, .NET, various J2EE bloatware, etc. are all things that I've seen the
same pattern with.

Eventually I realized that there was no such thing, really, as a good vs. a
bad framework. All frameworks are bad frameworks. I realized that I should
spend no time looking for a framework for the same reason that I should spend
no time looking for a disease.

Instead of frameworks, we need better and richer _platforms_ with better and
richer _libraries_ , support for a variety of good languages, etc.

~~~
misterbwong
_Instead of frameworks, we need better and richer platforms with better and
richer libraries, support for a variety of good languages, etc._

Seems like this is what .NET and the JVM are trying to achieve. MS is putting
up a lot of different languages (C#, VB, IronPython, IronRuby, etc) and the
JVM is experiencing somewhat of a rebirth with languages like clojure and
scala (not to mention good ol' boring java).

~~~
api
I was referring to things like ADO.NET, event driven control data bindings,
etc.

------
shasta
After seeing the emerging pattern, I skipped to the end to see if they just
sold spice racks. Too bad, I'd have liked that ending better.

------
bosch
The best part is that even though it was written 5 years ago, it's STILL
relevant today!

------
smitjel
This still rings true even today with JEE development...I long for the day I
can write ruby for a living.

------
coliveira
I don't like frameworks, but they have their place. If you know enough to
create a framework, you should better do itself. However there are two
situations when they are necessary: (1) people who have not enough knowledge
to build one and don't want/need to acquire that knowledge; (2) quick
applications where there is no justification for the time invested in working
at a lower level.

------
johnwatson11218
I like to think about frameworks in terms of those long tail distributions.
They do well for many common cases but as you go further and further out in
the distribution it becomes more and more convoluted to get your solution
written in terms of the framework. In most cases the users end up asking for
very unique features that never occurred to the framework designers.

------
telemachos
Everyone is too polite to mention it, but that must have been a _really_ bad
break-up.

------
hartror
Not all frameworks are created equal.

