Framework Fix

Published 17 years, 10 months past

“You know,” I said to the guys at the car lot, “I just don’t understand the deal with this car here.”

“Oh, it’s absolutely worth it!” they exclaimed.  For the next half-hour, they extolled the power of the engine, the smooth handling, the tight cornering, the rakish styling, and all manner of other wonderful features of the car.

“Wow,” I said.  “Thanks!  But it turns out that what I didn’t understand was how that steering wheel thingy and the foot pedals worked.”

That, in a nutshell, is what happened with the frameworks post.  Predictably, it drew a large number of detractors and supporters of various frameworks, and of the whole concept of frameworks.  Since I focused a good deal on how the tutorials and other materials (yes, including the effin’ manuals) confused me, it should have been no surprise that there’d be a whole lot of debate about the “hype” surrounding frameworks.

But here’s the thing: I didn’t get what frameworks really were.  I wasn’t complaining about the hype.  I was complaining about my lack of understanding, and to a large degree how little help I’d found in correcting that problem.  This is, as it turns out, because my problem was such an elementary misconception that no framework documentarian would think to address it.

How elementary?  My perception was that frameworks were ways of putting a simpler (or perhaps just different) syntactical front end on a language.  My belief about Ruby on Rails, for example, was that the Rails part was almost like a new interpreter that hid Ruby from the programmer.  I didn’t grasp that it was Ruby.  I thought it was a simplified or more elegant or somehow different language that generated actual Ruby on the back end, the same way Ruby or any other language interpreter eventually generates assembly language (or, if you like, a lot of ones and zeroes).

So that was the “very basic, fundamental, obvious thing” I was missing.  Hard to get much more basic than that, really.  I’m entirely not sure how I formed that perception, but there you have it.

My perception now, as I explained in a comment to my own post, is that frameworks are:

A framework… can be thought of as a collection of libraries, though in actuality a good framework is both that and a formalization of best practices, condensed into an efficient syntax and approach.

That may not be 100% accurate, but it’s a hell of a lot closer than before.  As a result, I feel like I have a much better grasp on the situation and no real reason to worry, so thanks to everyone who commented.

Oh, and I swear that Mr. Snook and I had no idea we’d be publishing on the same topic at nearly the same time.  At least, I had no idea.  If he did, then I’d like to talk to either his fortune teller or his server access logs.


Comments (19)

  1. I’m still not clear on one thing, are we on a “framework hype”? Man it’s all PR. We’ve had frameworks since day one, yes for web!

    I guess it’s all after 37Signals release of Ruby on Rails this whole thing started to get known by web-designers. C’mon man, .Net, J2EE, PEAR, Mojavi, ZOPE, HORDE, and all the other valuble frameworks…???

    Looking for definition? ;) Wikipedia to rescue

    But again I don’t think a framework can make a designer a developer, maybe it’s just my opinion.

    And before I forget to mention Adobe’s new AJaX framework.

  2. Actually Snook published this mini post about your post (yes, I commented on that one too, sory) before, I got here through that link.

  3. Yes, a framework is very much like a library. There is just one important distinction:

    With a library, you control the flow of execution. You write the main program and call out to the library to do bits of the work as you see fit.

    With a framework, it controls the flow of execution itself. You write the bits that differentiate your application from others that are similar, and the framework calls your code as it sees fit.

    In a way, it is an inside-out library.

  4. It sounds like you’ve got it right. I like Aristotle Pagaltzis’ definition, but the term ‘framework’ has been so overused and (often) misused that you’re best thinking of a framework as a really big set of libraries. Generally, this means it is intended to tackle a very broad problem. Ruby on Rails, for instance, is tackling the difficulty of web development. The .NET Framework tackles the difficulty of general programming. See? Broad.

    It’s not too rare for frameworks to even venture beyond simply being a collection of libraries. The .NET Framework also contains an entire new programming language and development tools. So your confusion with Ruby and RoR is far from being blameworthy.

    Sorry I’m late. :-)

  5. Sam: yeah, in general, your comments about the vagueness of the term are true. When it comes to web frameworks, though, the narrower (and thus also more userful) definition I gave is really quite close to reality.

    It is certainly true for Rails and Catalyst, and from what I know about it, I”d be surprised if it wasn”t true for CakePHP.

  6. This is yet another reason why the Y!UI team has refrained from calling our utilities a “Framework”

  7. Aristotle, that’s an excellent definition.

  8. Well, a framework is supposed to do some of your programming for you. In reality, you usually have to build your whole program around the thing. Generally, you either have to use the whole framework or none of it. And it locks you in.

    Does this simplify your programming? Maybe, maybe not. Some people claim spectacular success. Some of them are bloody awful, and the learning curve is usually a major career move.

  9. A framework could also be a new front end or “little language” — Movable Type templates or even PHP from a certain point of view puts a new front end on HTML.

    Some languages like Lisp and I believe Ruby make it easy to create little languages that can be parsed within the language interpreter/compiler itself, so you can freely mix in code from the original language with the little language. (People do this in Perl, too, though implementing the little language is trickier.)

  10. AnotherGuest: it depends on how well the framework”s flow of execution matches the flow of execution of your specific app. If it”s close, then a framework will do a major amount of your work for free. If your app diverges too much from the kind of thing that the framework was designed for, though, then you”ll spend more time working against than with the framework.

    There are no silver bullets, but there are tools, and tools can be spectacularly useful if used in the right circumstances. You can”t even open a can with your bare hands, f.ex., but look how easy it is with a can opener. That sure doesn”t make the can opener an übertool capable of doing any job at any place in anyone”s hands.

    So it is with web frameworks. For some things, they are spectacularly useful; but the solution to every problem they aren”t. No surprises there.

  11. I’m just popping in here to thank you… Your last post brought out a bunch of *great* comments for those of us involved in Framework projects.

  12. In response to dotone’s comment, “I guess it”s all after 37Signals release of Ruby on Rails this whole thing started to get known by web-designers.”

    And it’s about time! There is so much sloppy, ugly code out there (and I’ve made some of it), and it’s nice that methods for organizing and structuring that code are gaining exposure.

    Overall, it seems like the majority of web sites and web programmers are about 8 years behind the rest of the software development world. For example, it’s only been within the last year or two that design patterns have started to receive attention in the PHP world. Ask most PHP’ers if they know what test-driven development is, and you’ll get a blank look.

    Anyway – the expanded definition given by Aristotle really is great, as is Mr. Meyer’s :) I would add, then, that frameworks are designed to meet some specialized need. In the case of Ruby on Rails, the need is building web apps.

    Last thing- Mr. Meyer is actually a bit accurate in his conception of RoR as hiding actual code, only it often hides Javascript and not Ruby.

  13. Pingback ::

    Script Artists » Archiv » Frameworks?

    […] das auch gefragt und verucht, Antworten zu finden: Eric Meyer: Flummoxed by Frameworks und Framework Fix Jonathan Snook: Why Frameworks Suck und Why Frameworks Suck (redux) Und […]

  14. The value of a framework is that it standardizes and simplifies the process for incorporating more sophisticated programming into (for instance) web applications. If you spend all day every day writing programs, and that’s it, a web development framework would be irrelevent. If, on the other hand, you spend your day designing and building databases, building the application to run it, and building a web interface to the entire thing, or if you’re responsible for integrating the database, application, and interface built by others into a working app, then a framework (such as Rails) can be a big help.

    So in the case of Rails, I don’t see it as something that makes programming easier…I see it as something that makes it easier to talk to the web with Ruby…and to integrate Ruby with html, javascript, etc. more smoothly.

    Sure, you could do it without the framework…just like you could buy the parts and build your own blender from scratch.

  15. Pingback ::

    Mostly Random

    […] Django and their brethren. Especially recently, with Eric Meyer’s flumoxing (and its subsequent fix) and Jeff Croft’s amazing reboot. But I have been wanting to j […]

  16. It can be more than just a collection of libraries. They actually manage what you are doing.

    For instance, in ASP.NET, managing what access users have to what pages is very simple. You define the roles for a folder, and use either Windows or your own custom security handler. ASP.NET just does it for you. You don’t have to tell it to call a subroutine in each page, it’s done for you.

    A framework should be another level of abstraction, not just a bunch of libraries, but a whole way of working. When you wrote BASIC, you didn’t have to worry about pointers. It was hidden from you. You could just get on with the problem that was one level higher.

  17. I’m not against doing anything that makes my life easier but how many times have you been on a site where the author attaches a framework/library that contains 10, 20, 30 functions and they are using 2? Talk about bloat. The problem with frameworks is that people are using them who don”t understand the coding behind them. It is like a doctor with a shiny new scalpel who doesn”t know where to make the incision. They have the tools but not the knowledge to use them correctly.

  18. Ijust stopped by to thank you.I’m involved in framework projects and i’ve read a lot of comments on the blog that have really stimulated the creative juices.

  19. Pingback ::

    outbreak » Frameworks in the future.. (written on May 14th, 2006 by Marko Mrdjenovic)

    […] Eric posted Flummoxed by frameworks that started a huge debate about it (he also posted a later explanation). Yesterday I was also listening to Dustin’s episode 12: YUI Library Discussion about the […]

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>


if you’re satisfied with it.

Comment Preview