Why I Hate Frameworks (2005)

http://discuss.joelonsoftware.com/?joel.3.219431.12

by patmcguire • 13 years ago

87 118 13 years ago

discuss.joelonsoftware.com

banachtarski7• 13 years ago

This sums up more or less why I ditched Rails altogether.

loupeabody• 13 years ago

Funny enough, one commenter on this article advocated Rails:

"I don't want to start yet another religious war, but for a nice respite from the complexities of J2EE frameworks, check out Ruby on Rails. I'm playing with it now and it is a pleasure to work with."

I was actually surprised to see this is from 2005 too...

astrodust9• 13 years ago

It was frameworks like the ones Joel was railing against that inspired Rails.

A framework should help you do your job, not get in the way.

astrodust9• 13 years ago

Ditched...for what?

banachtarski7• 13 years ago

Writing my own! You'd be surprised at how lean the code is if you only write what you need. For others, I'd recommend trying one of the lighter weight frameworks (like Sinatra or something if you're into Ruby). Cowboy is good if you're into Erlang.

*edit: Perhaps "writing my own" was not the best usage of words. There is a way to provide server services without writing everything from scratch. I use a number of open source libraries but I refuse to fall into the usage of factory factory factory blueprints that bundle tons of features I don't need.

dashoffset3• 13 years ago

Really? IMO, there are many reasons why you would want to ditch Rails, but factories of factories is not one of them.

banachtarski7• 13 years ago

It's not just the factories of factories thing. It's actually the amount of cruft that I don't think is really necessary. I find that the pattern for programming with Rails is to find a gem that more or less does what you want and drop it in, at least, on most developer teams I've seen use Rails. What ends up happening is the creation of this bloated monstrosity that performs like crap for a number of unknown reasons.

datashaman• 13 years ago

The article is from 2005, and I'm reasonably sure that nearly every geek in the world has read it already.

brianmcc2• 13 years ago

Every couple years it resurfaces and every couple of years it still seems painfully relevant and current. And I keep reading it, sniggering away, each time :-)

readme• 13 years ago

Some people might have just started programming last year. Why would they have read this article in 2005?

pivnicek• 13 years ago

My first encounter, and it would have hit the nail on the head, if I'd bother to spend the 3 weeks developing it.

danielweber• 13 years ago

Still relevant.

I hate how, instead of being good at "technology X," employers are requiring people to be skilled at "company Y's version of technology X."

niuzeta2• 13 years ago

I think we're past the era of overusage on design patterns and the dreaded factory factory factories?

alan_cx• 13 years ago

Shakespeare is still a great read.

programminggeek• 13 years ago

All frameworks that start out as small tools are destined to become the thing that they hate if they ever get popular.

nathan_long5• 13 years ago

All projects written without frameworks are destined to re-implement framework-like features, but not as well, if they succeed.

(My statement isn't really ALWAYS true, but neither is yours.)

noir_lord• 13 years ago

I can't guarantee it is always true but I've yet to see a counter example on the code bases I've been exposed to.

It's almost like common problems have common solutions ;).

coldtea6• 13 years ago

All projects written without frameworks are destined to re-implement framework-like features, but not as well, if they succeed.

Of course they will implement framework-like features, that's inevitable. You'll still need routing, authentication, etc.

The win is that they'll implement them for their SPECIFIC use case, and only as much of them as they need, instead of having to accept the whole garbage that comes with a framework.

And you can cherry pick the best libraries for the cause, enging with even better ones that what any framework offers built-in.

dashoffset3• 13 years ago

Would you mind to give us an example?

coldtea6• 13 years ago

Rails. Now it's as bloated as the frameworks it used to mock for not being nible enough.

mcintyre1994• 13 years ago

The issue with this approach is we don't only need tools, what about when my tool factory factory factory creates a drill factory factory to build a drill factory so I can build a drill.. but then my drill needs batteries? Now I need to build a battery factory factory factory to build an AA battery factory factory to build an AA battery factory so I can build AA batteries.

But that approach seems absurd, what we really need is a more generic factory factory factory factory that can produce tool factory factory factories and battery factory factory factories, as well as all the other factory factory factories we might need in the future!

(On another note, try reading that fast ten times)

bhauer4• 13 years ago

I find this article entertaining but ultimately stale and a reminder that as much as we like to criticize the present, the past was not as rosy as we remember.

I haven't worked first-hand with a web framework that I would consider "enterprise" (and therefore encumbered by the kind of nonsense that is being pilloried in the article) in ages, certainly at least five years.

Most frameworks I have worked with in the past five years focus on helping me get my job done while not fussing with annoying details. That is precisely what I want them to do.

Better yet, the most modern of frameworks do that plus have put focus on performance, so they both solve stupid problems I don't want to deal with and do so quickly, giving me nearly the full capacity of the server's CPU to be wasteful/experimental/rushed with my coding style at first. Then I can optimize later to have a high-performance system because the framework itself is no longer the bottleneck it once was.

I love frameworks.

Justsignedup• 13 years ago

Let's rename this post:

Why I hate badly designed frameworks with unnecessary abstractions.

7mediaws2• 13 years ago

Yes, and that is really the issue here. Not all frameworks work the same way and some do come with an insanely amount of unneeded overhead.

jeremysmyth2• 13 years ago

I think it's more appropriately named "I don't like the word 'factory' when used in frameworks, and I [don't|refuse to] understand how they are useful to developers in their daily jobs."

I teach a Java web dev course that gradually works up from the servlet API through a bunch of different abstractions. I keep a drawn representation of the current stack at all points of the course, and keep a count of the lines of code required to do any particular thing. At the beginning, we need about 10 lines of code to process a basic GET request, and there are lots of explicit dependencies (inheritance, dependencies on HttpServletRequest etc.) and at the end, there are maybe two or three lines of code, and no explicit coded dependencies (several implicit, provided by the framework).

Once you add in a few pieces of actual work (DAOs, collections, CRUD functionality, database connection pools, query abstraction), the code is an order of magnitude simpler when you use a framework than when you don't.

It boils down to this: Using a smaller technology stack makes for an easier learning curve, but your day job after learning the basics involves ten times as much code ( == ten times as many opportunities for bugs, reinventing the wheel, antipatterns etc.), but investing in how to use a larger stack means your day job becomes much, much easier; you write less code, you focus more on your business logic, and you leave the dependency management and plumbing to the framework.

Sure, you might have to use the word "Factory" a few times, but that means you don't have to write the code to implement your object pools and collection handlers. That's already done for you.

specialist• 13 years ago

Sorry to pendant...

A boss once asked me the difference between a library (API) and a framework. Hmmm, had to ponder that one.

Besides the inversion of control -- eg don't call us, we'll call you -- I decided a framework is a prototypical (archetype) app, and you extend it.

Whereas a library is standalone that makes few assumptions about your app's "architecture" (eg the visible set of design choices).

I've written my own infrastructure (eg database wrapper, HTML generation, DOM & xpath, HTTP routing, logging, etc). I wouldn't call my loose collection tools a framework.

I'm trying to update an Eclipse RCP plugin for 4.x. (Hot damn what a struggle.) The RCP is a framework. It makes a huge number of assumptions (for better or worse) and there's the Eclipse Way of doing things.

bhauer4• 13 years ago

I'm not suggesting enterprise-style frameworks no longer exist, but simply rather that there are a wide variety of non-enterprise options today.

Also, you are correct, many of the collections of software packages we today, out of convention, call a framework are actually just collections of APIs. DropWizard on the JVM. Gorilla on Go. I recognize the academic purity and the difference in approach (like you said: don't call us, we'll call you). But in practical matters, I find it easier to just consider these collections a framework.

At the very least doing so allows you to communicate with others more easily.

"What framework did you use to build that web app?" "DropWizard." "Cool."

Or, you could answer, "No framework at all, but rather a collection of APIs." "You're some kind of smart aleck, huh?" :)

badman_ting• 13 years ago

Oh boy, an overwrought analogy. Everyone loves those.

samatman• 13 years ago

Anything with that many hammers is going to end up overwrought.

tootie• 13 years ago

Comparing frameworks to hammers is the completely wrong analogy too. A framework is, you know, a framework. Like insetead of buying 30 different hammers to build a framework, you buy a framework. Then you don't need a hammer. And the framework has slots for your fixtures that use standard fasteners so you can rely on fewer hammers and screwdrivers. Put up some siding and your house is done.

brudgers• 13 years ago

In Alabama we call them "trailers."

stcredzero4• 13 years ago

It's the overwrought analogy written to end overwrought abstractions, which are themselves analogies.

gonnakillme3• 13 years ago

Jesus, the casual misogyny in this article is staggering.

sheraz2• 13 years ago

A little dramatic, are we? There is no misogyny in this story.

Oh, and I'm thinking of using Laravel for my latest project. Seems to do a lot of what I need without building factories. I think frameworks have evolved since then.

141132• 13 years ago

So I'm assuming you missed all the references to murdering ex-girlfriends? I found it really unsettling, and somewhat sickening to read.

BillyMaize2• 13 years ago

misogyny - Hatred of women. How does that have anything to do with the article? You must mean some other word.

gonnakillme3• 13 years ago

Sorry for being unclear -- I'm referring to these parts:

And, if you want to kill your ex-girlfriend, there's really no substitute for a ball-peen hammer.
(Maybe they've never had ex-girlfriends. Or maybe they killed them with icepicks instead.)

nathan_long5• 13 years ago

Probably referring to murdering one's ex-girlfriend with a hammer?

jeremysmyth2• 13 years ago

Huh?

niuzeta2• 13 years ago

You should really add (2005) datemark at the end; the discussions portrayed in the link are at best stale, while entertaining.

rheide• 13 years ago

Today's version: Hammer Factories as a Service.

dustingetz• 13 years ago

these articles are what happens when a 24 year old peon engineer criticizes the industry accepted best practices of the time as determined by veteran architects with eight times the experience

edit to add some anecdotes: scalac and javac are written by the same person. The founder of Relevance, the company that funds Clojure development, wrote a book in 2006 about spring and hibernate.

sanderjd• 13 years ago

Interesting perspective! Ignoring the funny-but-silly analogy itself, it seems that at the time of the article, the industry accepted best practices as determined by veteran architects with eight times the experience were bad for a lot of the software being made using them. I'm all for deference to experience, but I think there is sometimes a dangerous temptation for experience to believe it is right because of its experience, rather than to use its experience to be right.

mwfunk• 13 years ago

Just so nobody gets confused by this comment, Joel was 40 when he wrote this, and was the program manager for Excel in the early '90s (> 10 years before this was published). So just to clarify, this was not written by a 24-year-old "peon engineer". I don't necessarily agree with what he wrote, but he does use capitalization and punctuation, so he's got that going for him.

dmiladinov• 13 years ago

Now I'm confused - I thought Benji Smith wrote this?

cmicali2• 13 years ago

So what is the right java web framework today? Play has gone down the scala route - is there really another rails-like web framework that today that would do what the author is asking?

bhauer4• 13 years ago

Rails-like is a confounding term. If you mean something as comprehensive, I'm not sure there is quite an analog. Although I personally don't usually want something as comprehensive.

If you mean something that is easy to get started, deals with the most annoying stuff, and gives you the fundamentals to implement an application, then I think there are some good options.

Of the Java frameworks we've tested [1], if you are ruling out Play-Java (because of a real or imaginary Scala design preference; I'm not judging that), I personally enjoy the coding style of Rest-Express and DropWizard. Check out the Rest-Express [2] and DropWizard [3] multi-query test implementations for a quick insight into their coding style. (Note the Rest-Express test was contributed by that framework's author.)

I'm not sure if this really answers your question, but I think it does speak to my earlier point in this thread that modern frameworks solve the problems I most care about and also (happily) tend to do so more efficiently--with respect to server resources--than the frameworks of a few years ago.

[1] http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

[2] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

[3] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

cmicali2• 13 years ago

Thanks!

Nothing against scala specifically, just using Play-Java (which we are) means you are bound to using sbt and when debugging into play internals you are looking at scala instead of java.

DropWizard is fantastic, will check out rest-express. I think the thing I miss from both that you do get in play (and rails) is the front end templating, assets pipeline, and useful assorted bits tailored to quickly building a html/js/css/api web app.

benjamincburns2• 13 years ago

It depends. When you say "Java" do you mean Java or the JVM?

It's certainly not anything like rails, but if I'm forced to work in Java I'm quite fond of SpringMVC, especially for building restful services that need to support a bunch of different serialization formats. Once you get over the fact that Spring-done-right is a bit XML-heavy, it's quite good. Also since most of the heavy-lifting is front-loaded into the the context initialization it can be very performant.

Otherwise for more simple stuff I just drop down to straight-up servlets and JSP.

If you can relax your requirement to just the JVM there are tons and tons of options...

ebenoist• 13 years ago

What is with all the casual yet incredibly violent references to violence against women? Do we really need that in an analogy about software frameworks?

ohwp• 13 years ago

Ofcourse the message here is 'too much abstraction'.

There are loads of bad frameworks that want to be too smart and too clean. I mean, there is nothing wrong with writing HTML. But I've seen stuff like:

   $output .= $framework->dom->returnInputElement('text', 'name', $initValue, $options);

That's nice and all but when it just returns the element without any extra functionality I think its just a waste of code and resources.

byroot• 13 years ago

just returns the element without any extra functionality

I hope it at least protect from XSS attacks.

dclowd9901• 13 years ago

A framework like this would probably scaffold the inputs for you based on your model structure, in which you do get back that you don't have to write boring ass crud stuff. Great for doing admin pages.

But for consumer facing stuff, you should probably abstract to something that templates (HAML, mustache, etc).

dcc1• 13 years ago

I think its not frameworks he has a problem with but JAVA itself, I came to the conclusions he arrived at a long time ago, JAVA doesnt save you time on large projects it makes you drown in needless bloat and abstractions and more worrying if working in a large team allows some members to float along easily. but hey its "an enterprise programming language" right?

bhauer4• 13 years ago

I think "JAVA" (sic) is still an enterprise language, yes. :)

The modern language known as Java (and most importantly, the coming Java 1.8) is not necessarily an enterprise language. Many people use modern Java to rapidly implement systems that, thanks to the maturity of the JVM, tend to perform very well without much effort--oftentimes none--put into optimization.

edwinnathaniel2• 13 years ago

I think you got it backward. Java could be overkill for small projects (although I never felt that way, ever).

Large projects need a complete solution that Java has to offer (Java as a platform, language, and its ecosystems).

Over the last 20-30 years, there's nothing out there in the market that really increase programmer's productivity other than Java (and its GC + tools like Maven, FindBugs, Jenkins, IDEs) and Rails (not Ruby, but Rails, Ruby itself is "meh").

I have yet to feel that way with other tools or programming languages yet (one of the reasons why they all failed the "mainstream" tests: only a select few thought that their niche tools are the most productive tools ever, the rest still aren't convinced and have yet to see big projects build on top of the said tools).

dragonwriter• 13 years ago

Large projects need a complete solution that Java has to offer

I'm not sure that as true as it is popularly perceived to be; I think it may be more true that there is such a history of use of Java and similar platforms (e.g., .NET) in the environments that produce large systems that there is a cultural bias to thinking it is necessary and that much of the current experience of large systems is centered on that kind of platform.

Arguably, building large systems with less dependence on the kind of pervasive system-wide compile-time interdependencies fostered by Java and similar platforms and instead relying on smaller components with minimal compile-time interdependencies integrated at runtime using well-documented communications protocols and interaction standards -- a real platform agnostic, potentially heterogenous, decoupled Service Oriented Architecture (without, particularly, the return to compile-time interdependency fostered by the approach to SOAP/WSDL common on Java and similar platforms) -- would be better for large systems, particularly when the large systems have components that need to adapt rapidly to changing needs.

tazsingh• 13 years ago

Were you hammered when you wrote this?

zzzcpan• 13 years ago

Here's the problem with frameworks: unnecessary complexity. Or YAGNI, as some may call it. This complexity leads to lots of incorrect assumptions about internal workings of the system and therefore bugs and security holes.

freejack• 13 years ago

I lost interest at the tasteless killing your ex-girlfriend joke...

coldtea6• 13 years ago

Yes, god forbid a blog post has any humor to insult puritan values...

nsxwolf• 13 years ago

Would you have preferred a joke about killing an ex-boyfriend?

kops• 13 years ago

The word "portlet" is like a huge warning sign to me that reads "run...like hell....while you still can...."

drcode• 13 years ago

This argument basically boils down to saying "frameworks are monolithic, and hence not flexible enough".

I agree completely with this, the best antidote to this IMHO are the ideas from the lecture "Simple Made Easy" by Rich Hickey http://www.infoq.com/presentations/Simple-Made-Easy

He argues for an approach to framework development where all the different parts of the framework need to be 100% independent and interchangeable. Essentially, instead of a framework you should have 20-30 different libraries that can fully stand on their own but can be combined to give a framework-like result. You can call it the "Chinese Menu" approach to frameworks.

To see this approach in action, look at the different libraries for Clojure server-side development (Ring, Compojure, etc) which consist of tiny interchangeable libraries for specific tasks.

The new full-stack Pedestal framework also follows this philosophy (and in fact I am sure the Pedestal designers expect large chunks of this framework to be discarded as new approaches are tried withing their system, but the plug-and-play nature of all their libraries allows for effortless swapping of component libraries.) http://pedestal.io/

stcredzero4• 13 years ago

tiny interchangeable libraries for specific tasks.

So, the UNIX folks had a good idea, then.

AndrewDucker• 13 years ago

It's true that if you want to build a spice rack then you don't need a factory to build factories to churn out hammers.

But if you're building a city then the chances are that you don't want the people who furnish each flat in it to have to worry about how the plumbing is done. You want them to be able to concentrate on just their bit, and let the infrastructure work around them,

And that's when these frameworks come in handy - when the people churning out CRUD code to process data don't have to worry about what the message queuing system is, or how their code is instantiated, or where it's going to be used - they just have to wire up a couple of standard interfaces, and make their specific code work.

Someone else will have set up the configuration for them (whose job it is to do just that), and they can get on with their speciality, rather than trying to fashion their own hammers out of rocks, logs and twine.

VLM7• 13 years ago

"they just have to wire up a couple of standard interfaces"

Which change constantly over time. I started playing with Rails in 2006 and refuse to touch it ever again. Oh god the tragedy when rails upgrades and now I have to figure out why the code no longer works. Perl CGI was never, ever, even in the bad old days, nearly as bad as that.

Rails is awesome for development. The rest of the software lifecycle, well... Lets just say it is never allowed to leave development. You're one apt-get intended to patch a security hole, away from a significant rewrite project. I hate it.

Someday, when its totally obsolete, it'll finally be stable enough to be "enterprise grade". Till then I've had enough.

domness• 13 years ago

I don't think I've had an issue like that over the past couple of years in my Rails career.

I'm sure you should have probably understood why your code 'no longer works', perhaps some bad Ruby/Rails programming practices?

swah• 13 years ago

Very sweet piece from Benji Smith, reminds me of Steve Yegge's "Execution in the Kingdom of Nouns"...

mehulkar• 13 years ago

I've had this conversation before in different terminology. I was concerned that a majority of service based businesses were building castles in the clouds and creating a bubble. Naval of Angellist recently tweeted something similar [1]. Essentially, it comes down to this: the more layers of abstraction you build, the farther you get from solving real problems. I guess this is the epitome of consumerism though.

[1] https://twitter.com/naval/status/360890615896092673

PDegenPortnoy• 13 years ago

"general-purpose tool-building factory factory factory" Heh.

stcredzero4• 13 years ago

One word: Java. By making Java a bit less dynamic, its creators could add in a bit of static typing and C-like syntax and market it very effectively. (Not what they intended, exactly, but what ended up happening.)

But what happened, is that Java lost just enough power and abstraction, so that the cost-benefit of burgeoning software tooling was still a net win. What Java lost in power, it made up for by writing more code. This is why Java web application servers, Java IDEs, Java messaging middleware became these lugubrious and unwieldy monstrosities, while we in the Smalltalk camp marveled at how we had equivalents that had start up times and enabled edit-test-debug cycles orders of magnitude faster while being comprised of less code -- and yet we were the ones saddled with the "legacy" label and the reputation of being slow. (And entire kinds of tooling like Spring and Maven -- just entirely absent and unnecessary!)

Summary: beware of the situation where something is hyped, but you still wind up with more tooling and writing more code than you would have otherwise.

Most likely, you can do it with less code.

I've been picking on Java here, but this applies to the majority of cases. It even applies to some things in Smalltalk. What are you really trying to accomplish, and can you get most of the same effect with less?

gwu78• 13 years ago

This is great. I was just thinking about this phenomena when I woke up this morning.

In the early days there were general purpose toolmakers. And tool users had to develop the skill to use general purpose tools. They could then tackle a variety of tasks.

Today it appears that the most effort goes to making special purpose toolkits (e.g., frameworks). The only "skill" that the toolkit user must develop is mastering the toolkit. But the kits are enormous, the documentation is enormous and the time commitment is, relative to the number and variety of tasks she will be equipped to tackle after mastery, enormous. I'd venture to guess most users of frameworks only use a small fraction of the toolkit. Hence they can only tackle a small fraction of the tasks that the toolkit could permit them to tackle were they to master all of it. To learn how to use every feature (every tool) within these specialized kits would seemingly take a "lifetime".

Is learning a "framework" worth my time? What happens when the tasks change and the toolkit I've mastered is replaced by a different one? What if I spent my time learning how to use the general purpose tools (still available on every computer running UNIX) that can be used to build special purpose toolkits instead?

Measured in terms of learning and skill development, maybe the greatest benefactors of frameworks are the folks that build them. That is a thought I had. Presumably they must themselves know how to use more general purpose tools. Thus they can build frameworks of more specialized tools. If this is true, that is a skill that is worth the time investment, in my opinion.

Joel on Software was a great forum. I only wish Joel was a UNIX programmer. His frame of reference always seems to be Windows.

epynonymous• 13 years ago

this is most likely a rant on jsp and servlets (cringe), judging by the time period, struts was probably used in combination with these technologies which had to run on some overly expensive app server or tomcat, and needed to include the j2ee sdk (java 2 enterprise edition for all you youngins) even if you're just using servlets, j2ee and ejbs were a whole other ball of mess.

i can relate, writing apps in rails, django, etc is much better than what was available back in the day (8 years ago!) for java side, spring was just starting to emerge around that time if not later which gives you a pretty comparable experience to rails.

dang• 3 years ago

http://web.archive.org/web/20180927070411/http://discuss.joe...

Why I Hate Frameworks (2005)

Related Stories