14 ms·
Why I Hate Frameworks (2005)
- banachtarski 13y agoThis sums up more or less why I ditched Rails altogether.
- killnine 13y agoYou know, I really don't enjoy frameworks either. For one, I like to know about everything that is in my app. And two, I've been at this long enough to know when you choose a one-size-fits all that means you are trading something for it, usually something I'm not willing to trade. But about 3 hours into a new web app idea this past weekend, I stopped because I'm beginning to see the web dev process as ridiculous. So I started looking around for something that would stream line the process. If you do web development, and you want to build and ship fast, what language do you use?
- loupeabody 13y agoFunny 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...
- astrodust 13y agoDitched...for what?
- banachtarski 13y agoWriting 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.
- wakaflaka 13y agoReinventing the wheel at every turn!
- nathan_long 13y agoWriting your own framework may be the best decision for your project. However, it's almost guaranteed that the next developer on your project would find a known framework with known conventions to be easier to understand. I'm not saying your tradeoff is wrong, just that there is one.
- grammaton 13y agoThis is a known anti-pattern.
- astrodust 13y agoThe real anti-pattern is "My application is simple, so I don't need a framework". Simple applications are ideal for frameworks. It's the crazy hard stuff where frameworks break down.
- banachtarski 13y ago
- dashoffset 13y agoReally? IMO, there are many reasons why you would want to ditch Rails, but factories of factories is not one of them.
- banachtarski 13y agoIt'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 13y agoThe article is from 2005, and I'm reasonably sure that nearly every geek in the world has read it already.
- brianmcc 13y agoEvery 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 13y agoSome people might have just started programming last year. Why would they have read this article in 2005?
- pivnicek 13y agoMy first encounter, and it would have hit the nail on the head, if I'd bother to spend the 3 weeks developing it.
- danielweber 13y agoStill 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."
- niuzeta 13y agoI think we're past the era of overusage on design patterns and the dreaded factory factory factories?
- alan_cx 13y agoShakespeare is still a great read.
- deleted 13y ago[deleted]
- atc 13y agoI hadn't read it. I disliked the article -- over simplified, far too general, poor analogy -- but it was new to me.
- programminggeek 13y agoAll frameworks that start out as small tools are destined to become the thing that they hate if they ever get popular.
- nathan_long 13y agoAll 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 13y agoI 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 ;).
- coldtea 13y 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.
- dashoffset 13y agoWould you mind to give us an example?
- coldtea 13y agoRails. Now it's as bloated as the frameworks it used to mock for not being nible enough.
- dashoffset 13y ago
- mcintyre1994 13y agoThe 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)
- bhauer 13y agoI 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 13y agoLet's rename this post: Why I hate badly designed frameworks with unnecessary abstractions.
- 7mediaws 13y agoYes, 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.
- jeremysmyth 13y agoI 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.
- badman_ting 13y agoOh boy, an overwrought analogy. Everyone loves those.
- samatman 13y agoAnything with that many hammers is going to end up overwrought.
- tootie 13y agoComparing 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 13y agoIn Alabama we call them "trailers."
- stcredzero 13y agoA trailer's not a framework, it's more like shrinkwrapped software.
- stcredzero 13y agoIt's the overwrought analogy written to end overwrought abstractions, which are themselves analogies.
- gonnakillme 13y agoJesus, the casual misogyny in this article is staggering.
- sheraz 13y agoA 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.
- 14113 13y agoSo I'm assuming you missed all the references to murdering ex-girlfriends? I found it really unsettling, and somewhat sickening to read.
- sheraz 13y agoYou mean ll two of them? Yeah, and they were simply part of the story. Grow a backbonejs already. (see what I did there?) In that case I suggest you stay away from most literature, film, and the humanities in general.
- 14113 13y agoSorry that I don't find references, in the middle of a tech article, to killing people in brutal, vicious ways all that appealing. Sure, I'll happily watch a slasher flick, but that's the time and the place for that. This is completely the wrong context, and exactly the kind of thing driving women out of tech.
- BillyMaize 13y agomisogyny - Hatred of women. How does that have anything to do with the article? You must mean some other word.
- gonnakillme 13y ago
- niuzeta 13y agoYou should really add (2005) datemark at the end; the discussions portrayed in the link are at best stale, while entertaining.
- rheide 13y agoToday's version: Hammer Factories as a Service.
- dustingetz 13y agothese 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.
- mwfunk 13y agoJust 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.
- deleted 13y ago[deleted]
- dmiladinov 13y agoNow I'm confused - I thought Benji Smith wrote this?
- sanderjd 13y agoInteresting 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.
- cmicali 13y agoSo 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?
- bhauer 13y agoRails-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&test=db&l=3k http://www.techempower.com/benchmarks/#section=data-r6&hw=i7... [2] https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/restexpress/src/main/java/hello/controller/MongodbController.java https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... [3] https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/dropwizard/src/main/java/com/example/helloworld/resources/WorldResource.java https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
- cmicali 13y agoThanks! 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.
- ebenoist 13y agoWhat is with all the casual yet incredibly violent references to violence against women? Do we really need that in an analogy about software frameworks?
- cbb7 13y agoIt's called humor. I know they say feminists are humorless but you take the biscuit.
- ohwp 13y agoOfcourse 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 13y ago> just returns the element without any extra functionality I hope it at least protect from XSS attacks.
- dclowd9901 13y agoA 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 13y agoI 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?
- bhauer 13y agoI 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.
- edwinnathaniel 13y agoI 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 13y 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 13y agoWere you hammered when you wrote this?
- zzzcpan 13y agoHere'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 13y agoI lost interest at the tasteless killing your ex-girlfriend joke...
- kops 13y agoThe word "portlet" is like a huge warning sign to me that reads "run...like hell....while you still can...."
- drcode 13y agoThis 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 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/ http://pedestal.io/
- stcredzero 13y ago> tiny interchangeable libraries for specific tasks. So, the UNIX folks had a good idea, then.
- AndrewDucker 13y agoIt'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.
- VLM 13y 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 13y agoI 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?
- VLM 13y agoAlmost certainly. And that's another reason I can't stand it, its a my way or the highway culture rather than there's more than one way to do it culture (my mistake for hanging with the wrong crowd), and its marketed as a tool for noobs to quickly ramp up a simple CRUD plus a bit more. Its marketing doesn't match its design. Its a tool for experienced experts to work slightly faster using the One-True-Workflow which they already know. On the other hand, most books, online tutorials, etc, show it as a noobs playground. Its like taking the kids to a neighborhood park that turns out to resemble an Indiana Jones movie set. I had zero ruby experience when I started fooling with RoR in 05, 06. All rails did was get in the way of developing those language skills. Training wheels on a Harley Davidson, something like that. Write once, upgrade never because it'll stop working and as a noob shielded from the cold hard world by the framework, you won't have the experience to be able to figure out why. What a pain. The whole experience, just suffering. Off the top of my head, around 05/06 going in as a complete ruby and rails noob, there was no noob-obvious handholding way to handle many-many CRUD. Things have in fact probably improved quite a bit since then. The problem is with a one-true-path culture, everything has to be rewritten to fit the enforced style of the day. And frankly for some meaningless intranet "CRUD plus a little more" app thats now become somewhat biz critical, I don't want a life of permanent rewriting. Ah, whatever, just ignore my ranting. My experience has been horrific and it'll color my judgment. I'm sure for everyone else its all candy corn and unicorns and balloons all day long, and will continue to be so. I'll just use something else.
- swah 13y agoVery sweet piece from Benji Smith, reminds me of Steve Yegge's "Execution in the Kingdom of Nouns"...
- mehulkar 13y agoI'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 https://twitter.com/naval/status/360890615896092673
- PDegenPortnoy 13y ago"general-purpose tool-building factory factory factory" Heh.
- stcredzero 13y agoOne 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 13y agoThis 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 13y agothis 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 3y agohttp://web.archive.org/web/20180927070411/http://discuss.joelonsoftware.com/default.asp?joel.3.219431 http://web.archive.org/web/20180927070411/http://discuss.joe...