If you’ve been paying attention, you know that a simple discussion about CSS frameworks has turned into quite a bit of a mess. This is in large part due to inadequacies in the way I presented my thoughts, and also in some part due to what can only be called hypersensitivity, snobbery, elitism, and flat-out ignorance on the part of a lot of CSS authors. Thankfully, someone much more level-headed than me and, quite frankly, a lot smarter than all of us, is here to save us all. He’s James Bennett, a Python and JavaScript programmer extraordinaire who also happens to be a solid CSS author. James wrote a freakin’ great piece called Let’s talk about frameworks (again), in which he explains a lot of things that the vast majority of web designer simply don’t understand.
This concept of “frameworks” is pretty new to us designers and CSS authors. However, it’s not new to engineers. These guys have been dealing with frameworks, libraries, and snippets since the dawn of ages, it seems. James helps to explain why, from the perspective of a programmer — a very experienced, very expert-level one — frameworks are often developed, used, and published. He talks about the advantages and disadvantages of frameworks to developers, based on of many years of computer science and frameworks being built and used for almost every computer language ever created — years that us web designers simply almost never have (most of us are not programmers at all, and certainly not serious ones who have great experiences outside the realm of simple web scripting).
After defining exactly what a framework is (as well as what a “snippet” and a “library” is), James talks some about whether or not the concept of a framework applies to front-end web development, and specifically to CSS. He talks about situations where they work better than others. He discusses the commonly-held arguments for and against frameworks with no bias.
James notes that the flame wars that have been occurring here at jeffcroft.com are the same flame wars programmers have had for years and years, and suggests we simply learn from them, rather than fighting these battles over again.
There are people, such as Andy Clarke (see, I’m trying to name names now, since I’ve recently been flamed for “railing against a shadowy cabal”), who suggest that writing CSS and HTML is an art in and of itself, and not a means to and end (I can say this with a great deal of certainty — Andy and I had this discussion on IM just today).
…programmers tend to see duplicated work as a bug, and try to fix it. The result, in many cases, is a framework.
— James Bennett
While I respect that viewpoint, I don’t agree with it. Writing code is, for me, just a way to do what I really care about: building amazing things on the web, hopefully taking advantage of its ability to bring people together and uniquely communicate messages along the way. Andy points out that I think like an engineer, and not like an artist. This is absolutely true — I’ve never claimed to be an artist (nor do I want to be). For me, the process of writing HTML and CSS is not a particularly creative one — it’s engineering, pure and simple. It’s building something. If you agree, you may find that serious programmers have been building things with code for lots of years, and that maybe, just maybe, we can learn a thing or two from them. If you don’t agree, and you choose instead to prop CSS and HTML up as some kind of craft that is only for artistes, and not for pathetic little engineers, I invite you to read anyway, if only so you can point your noses upward and laugh as we little people try to make writing HTML and CSS faster, more elegant, and simpler. :)
Either way, you’re going to want to run — don’t walk — over to James’ brilliant piece. Seriously. Just read it. And for christsake, flame him, not me. Please? :)
001 // James Bennett // 11.19.2007 // 11:07 PM
I was just trying to start a blog war with Seattle, actually, but now you’re all lovey and fawning over my immense wisdom, so apparently it didn’t work. And I think I need a towel.
Stupid grungy Starbucks-drinking deadbeats, the lot of you!
002 // Mike D. // 11.19.2007 // 11:20 PM
Two things:
The potpie was delish.
Your use of split columns for body copy on this site is offensive to me as both an American and a scroller of browser windows. Seriously… that is a much bigger crime than either using or not using a framework.
003 // James Bennett // 11.19.2007 // 11:20 PM
And there is a level of artistry involved in code, regardless of whether you’re using a framework (and a good framework often lets your own code be far more concise and elegant than it might have been otherwise), it’s just that there’s not always a lot of beauty or elegance to be found in, say, writing wrappers around
XMLHttpRequest;)004 // Mike D. // 11.19.2007 // 11:25 PM
Dude, I thought HTML was only “frowned upon” in comments! Didn’t know it was stripped too. No ability to link? Another crime! Off with his head!
Croftie, I’m heading down to Bouwer’s in Fremont in five minutes. Let’s do some Jager shots.
005 // Jason Grigsby // 11.19.2007 // 11:43 PM
LOL. I’m with Mike on this one. The two columns are a crime. :-)
006 // Dylan B. // 11.19.2007 // 11:44 PM
I have been following these feuds for the past couple days, and I guess I’m just getting really confused. Why is anyone arguing about open source completely customizable CSS. It could help people that aren’t skilled with CSS and web-standards get their feet, and others who don’t want to use don’t need to.
I guess I just don’t see how this whole thing go so out of hand, but the good thing is that with all this arguing some very intuitive and interesting points were made.
007 // Kevin Tamura // 11.20.2007 // 12:04 AM
Ok I’m with the rest of the peanut gallery here, I just don’t like the 2 column layout for body copy.
008 // Keith // 11.20.2007 // 12:20 AM
I think we need to avoid lumping CSS and HTML together here, at least for argument sakes.
When we’re talking markup (HTML) I can see a certain level of artistry and/or craft involved. Markup, to a certain degree is designed. I get that. Markup, again, to a certain degree, conveys meaning, especially when the presentation layer (CSS) is removed. (I say CSS in parens. because no matter what we choose to believe markup does have some presentation element to it - when seen sans CSS.)
CSS though? CSS has no value beyond styling HTML. It coveys no meaning whatsoever. I suppose you could argue there is an art to writing CSS - but I’d argue there is very little value in that art beyond saving time, doing it in a way that appeals to you and your team, etc. (Something a framework could do for you perhaps?) Doing CSS the “right way” is kind of misleading. Unless you’re arguing about how it effects your markup.
Which, I suppose, it the main issue here and an understandable knock against CSS frameworks. They can dictate your markup, which clearly isn’t ideal.
Sure their tied together, and that’s part of the “problem” but let’s be honest - as long as your presentation layer looks and acts as your designer intended and your syntax is clear to those who might need to edit it, etc. it doesn’t really matter all that much how you write your CSS.
I don’t think you can say the same for your markup. There is a logical argument for semantic markup, for taking the time to design, or craft your markup.
(How I even go to thinking about this I’ll never know.)
009 // Jeff Croft // 11.20.2007 // 12:20 AM
sigh
I’m completely incapable of a writing a blog post that generates meaningful discussion anymore, aren’t I?
010 // Jeff Croft // 11.20.2007 // 12:23 AM
I don’t think there’s any more artistry in writing code than there is in taking out the trash. Sure, you can argue there’s an “art” to doing anything well. And certainly, to do anything well takes some skill knowledge. In that sense, I suppose code is art. But I’m doubtful you’re going to find the markup for the CSS Garden hanging next to the Mona Lisa anytime soon.
011 // Jeff Croft // 11.20.2007 // 12:24 AM
Keith: There certainly are good reasons to write clean, valid, semantic HTML. But, the myth that using a framework somehow prevents you from doing that is flatly absurd.
012 // Keith // 11.20.2007 // 12:38 AM
Jeff - Oh, I know. But I can see the concern that if people use a canned framework and don’t know what they’re doing they might let said framework dictate their markup.
I’m just pointing out that I understand that argument AND supporting the idea that markup anyway, could be seen as an “art” of a sort. (Then again, it really depends on how you define “art” and you’ve already got WAY to many insane semantic debates surrounding this stuff.)
I’ll refer you to the comment I made when I linked to your original article:
“IMO CSS frameworks are fine for some things, and not so fine for others. As long as you know what you’re doing and how they can help (or hurt) you should be good with them.”
We saw a case just today where Tom had used Blueprint and because of that he may have to start over from scratch. Granted, this is more an issue of not knowing the requirements (not his fault) and I don’t blame him for going with Blueprint, but because of it’s limitations he may have been better off rolling him own. It just illustrates what I feel is a HUGE grey area. There are no right or wrong answers here.
These are tools, it’s all about how you use them. If you can use your favorite tools in a way that saves you time and effort without sacificing meaningful quality - by all means, do it. But recognize the risks involved, if there are any.
Does it need to be more complicated than that?
I don’t really understand the heat involved in some of the arguments here. It’s like arguing over what kind of hammer to use or your favorite BBQ sauce. Somewhat interesting, maybe, but how people get heated about it is beyond me.
013 // Sara Flemming // 11.20.2007 // 12:47 AM
I think there’s an art to writing code only in the context of the eventual content. Otherwise, it’s just a bunch of characters in a specific order.
I’m not about to sum anything up or try to make light of anything (except your appalling lack of emoticons, Jeff, I mean really), mostly I’m fascinated at the reaction to a name being put to something we do. Like a name makes our effort somehow less.
Also: word.
014 // ben // 11.20.2007 // 3:19 AM
The Evil-Google-is-Fronting-Blueprint bit was… well, you gave me a hard time for it, and rightly so, in the comments to my reply post. (That said, I avoid using most Google resources most of the time without respect to their provenance, with the exception of search, Maps, and more recently Blogger.)
Were I to replace it, I would point out what others have today - there’s not so much takeaway for me in hitting the learning curve of a new tool, because I know the basic tools awfully well.
…And I’ve been thinking, when would I use something like Blueprint or YUI or CakePHP or Rails? For things like setting up app authentication, it would be one hell of a timesaver. Ditto with really awful vertical orientation problems.
…But that’s the thing - I plug a black box (really, am I going to take the time to read the underlying source in order to grasp how it does what it does? You neither? Huh…) into my application, and if (when?) it kerplodes, I’m in a deep heap.
When I imagine a comparative n00b doing the same thing, I’m horrified, and when I imagine that same n00b billing hours, I’m furious.
Soyeah, to the framework angels I plead for delivery of something with:
…Which is really no different than what James says is possible.
And also, you finally made a subscriber outta me - not for the sake of seeking outrage, but rather to garner a much different perspective than the ones I’m accustomed to.
015 // Jeff Croft // 11.20.2007 // 3:23 AM
Clearly, you shouldn’t be diving into a framework without understanding it pretty darn well, first. Doing so could only be classified as a mistake.
Also clearly, these frameworks are generally not designed for, as you call them, “n00b’s”. Suggesting that someone learn these frameworks instead of the languages they’re based on it also a mistake. Thankfully, I don’t think anyone has suggested such a thing.
016 // Charles Roper // 11.20.2007 // 3:38 AM
I don’t think that’s strictly true. You have to actually use something in order to understand it. I’d wager that very, very few people actually read through - and understood - the Rails or Django source before they dived in. Same with HTML and CSS - I bet everyone here fumbled about with these technologies at the start, making mistakes, getting it wrong and not fully understanding. I think Ben’s assertion that one must fully understand a technology before being permitted to use it is unpragmatic and plain wrong. To take Rails as an example, many programmers have become better programmers as a result of using it. They have learnt new patterns (MVC, REST, etc), better structure and better practises (DRY, refactoring, keeping things concise and readable).
017 // Richard Rutter // 11.20.2007 // 3:39 AM
I don’t want to get drawn into this, but I can’t help but observe that such a mess is what usually happens when sensible argument becomes unnecessarily personal, and especially so when it’s framed as such.
Somewhere beneath this, there’s a proper debate to be had. Maybe when things have cooled down a bit.
018 // Andrew Ingram // 11.20.2007 // 8:11 AM
Let’s assume for a moment that most people are quite happy to use frameworks and the only real area of contention is the use of a layout framework for CSS.
The reality is that most people would want to use a layout framework (who doesn’t like making their own jobs easier?). But at the present there is no satisfactory way of doing this using just client-side CSS whilst also allowing the perfectionists (or whatever word you’d like to use) to maintain their pristine and streamlined markup. It’s not a case of just choosing a different framework that more tightly matches your requirements, because as far as I can tell it’s basically impossible to release a CSS framework aimed at simplifying layout without hijacking markup.
I’m all in favour of taking necessary steps to meet deadlines, and to this end something like Blueprint is ideal. But I don’t think I can make the leap to saying this is a good thing, just a necessary one.
I personally hope that one day it’s possible for all HTML content outside of the head tag to be all signal and no noise. This isn’t realistic at present due to the limitations of CSS, but whilst I may personally be using a layout framework in the meantime I won’t be pushing the use of them because they don’t match my long-term idealism regarding the web.
I hope that helps clarify the “opposing” viewpoint a little bit more.
019 // Aleph Ozuas // 11.20.2007 // 8:24 AM
God, the use of split columns in your site is really, really boring! Great post anyway, and I agree with your viewpoint.
020 // Ove // 11.20.2007 // 10:01 AM
It’s been interesting reading these posts and comments last couple of days.
I wonder sometimes who we think we are and what makes us so friggin special when we start saying that writing HTML/CSS is an art :-) I don’t want to get into semantics, but how is it not a craft like other coding? I think this attitude (calling it art) might be an underlying source of some of the comments you’ve gotten Jeff.
I think using frameworks in CSS is part of CSS growing up. We use frameworks on all other languages server and client side, and what makes us so special that we can’t use frameworks for CSS as well? If anyone can save the project some time and the client some money, good for them! If you’re not ready to use the the grid part of a CSS framework (like me), good on you as well, at least we’re all using a CSS framework to some degree.
Oh, loved the link to James Bennett, thanks.
021 // Adam Arndt // 11.20.2007 // 10:37 AM
I don’t think that I can add much that hasn’t already been said, but I will throw in my two cents anyways.
I agree that frameworks are a wonderful tool. Their existence in almost every programming language out there is a testament to this. I am working on developing my own since I find myself constantly duplicating code/logic across our corporate websites. However, as you (Jeff) and others have stated, the user of these frameworks should be intimately familiar with the language (CSS, HTML, back end, etc.), as well as the inner workings of the framework. Frameworks are not a substitute for knowledge. Looking at the broader picture though - if the client is happy, and their audience/customer has a pleasant experience, who cares?
022 // Andrew // 11.20.2007 // 10:45 AM
Trying to channel the perspective of the (lowercase) Semantic Web / microformats guys, I think you’d have an argument on your hands if you were to suggest that designing good HTML representations of data isn’t fundamentally a creative activity. I’d say quite the opposite, actually. Sure, if you don’t care - and there are many good reasons not to care, a lot of the time - about the reuse of data embedded in webpages for anything other than its rendering and display in some sort of browser, then unsemantic class names are neither here nor there.
However, if you’ve got an eye on automated processing of, data-extraction from, and data-mining of resources on the Web, then semantically meaningful class names in HTML (when coupled with GRDDL and the like) can be really important. (That’s equally true for people wriing Greasemonkey scripts and the like too - anything which dynamically interacts with or post-processes Web content.)
From a pure graphic design perspective, maybe they don’t matter, but then you’re into a philosophical argument about what the Web “should be” and how you should design for it, at the architectural rather than the visual level. The tradeoffs are going to be different for different datasources, too; I work on scientific applications where semantic processing is really important, but that might well not be as true for what you do.
So it’s a matter of what tradeoffs you’re trying to make. And, yeah, it’s difficult. We all knew that already, though…
023 // Jeff Croft // 11.20.2007 // 10:55 AM
@Charles Roper: You’re right, people certainly do dive into frameworks without first understanding the languages they’re based on (I started using Django before learning Python, for example). I don’t think this is the right approach, though. In order to be really successful with a framework and not, you’re going to need to know the language it’s based on, as well.
@Richard Rutter: Agreed. It definitely became unnecessarily personal, and I definitely contributed to that. I have apologized to those involved several times Some have accepted my apologies and some have not. I hope those who have not will eventually choose to move on — for now, I’ve done all I can. Thanks for not getting involved yourself.
024 // Jeff Croft // 11.20.2007 // 10:55 AM
I would say this is accurate. The question is: how is that “pristine” markup any better than semantic, valid, and very clean markup? For me, it’s really not. But if you’re the type who insists on “pristine,” then the layout bits of the frameworks that exist today really aren’t for you. No doubt about it.
I do, too. The proliferation of frameworks for a particular language is certainly a sign of maturity, critical mass, and real-world usefulness. In this sense, the fact that they are starting to show up for CSS has to be viewed as a good thing, even if you have no interest in using them, yourselves.
Definitely not. People keep bringing this up, but not a single person in all 150+ comments that have been posted around here have said that frameworks are a substitute for knowledge. I’m not sure why it keeps coming up, since it’s clearly a non-contentious point.
That is, I suppose, the heart of my position. If there are logical, provable, explainable downsides to doing something a particular way that outweigh and logical, provable, and explainable upsides, I”ll avoid those techniques. For example, there are very pragmatic reasons to use web standards over tag soup (less code, better performance, better maintainability, more flexibility, etc.). Right now, I feel like there are very pragmatic reasons to use frameworks in certain situations (faster development, less browser testing, consistency amongst teams, etc.), whereas the primary downside people cite (“it makes my code less ‘pristine’”) doesn’t have logical, provable, explainable consequences that negatively affect the developer, client, or end user.
Being “pristine” may be very important to you in the same way that washing my hands way more often than I should is important me (OCD? Sure, I guess I am). But, I’m really not able to give a good explanation as to how washing my hands so much is actually better for me. I just like to do it. If you like to have pristine code, then by all means, have pristine code. But don’t act like you’re doing it for the sake of art when you’re really just satisfying your inner need for perfection.
025 // Matt Wilcox // 11.20.2007 // 1:44 PM
I think this is a good example of exactly why the whole thing blew up in the first place. It’s not the ideas you are discussing per-say, it’s the way in which you generalise your audience and proceed to talk down to them without seeming to realise you are doing it. A lot of CSS authors are hypersensitive and elitist? Really? Are so many of your readers truly so ignorant and snobbish? These are not nice words to be associating, however vaguely, with any of your readership, let alone with ‘a lot’ of them.
Again, this is a heavily loaded sentence. It reads that if you happen to believe there’s an art involved in authoring HTML and CSS then you must think engineers are pathetic. And you must also be quite a prick who likes belittling anyone with a different opinion.
You seem to load your points in such a way that ‘the other opinion’ must be held by some egotistical pompous ass. You appear to project that manner onto anyone who may take a different viewpoint before they have even said anything. Is it any wonder you think those people are being confrontational even if they are not?
Even your end note special note for the hyper-sensitive is a half hidden accusation. Why mention hyper-sensitive? Why not just dispassionately say your piece rather than call out hyper-sensitivity when you foresaw how your article might be read by those of your readership who are not aware that you and Andy are friends?
The problem isn’t your content (which, may I say, is always interesting and enlightening), it’s your writing style.
026 // Jeff Croft // 11.20.2007 // 1:56 PM
It certainly seems like a lot of them are hypersensitive and elitist, yes. As for ignorant, I was referring to their ignorance about the hows and whys of frameworks — facts they are ignorant to because most of them have never done serious programming. I certainly wasn’t saying the people are just generally stupid.
It’s a whole lot less loaded when you don’t remove the smiley that clearly indicated my being planted firmly in cheek. But, you’re right — your edited version of it does sound pretty loaded.
I mention hyper-sensitive because a lot of people don’t seem to be able to take a joke. In this latest post, I was very careful to indicate the points at which I was joking with smilies. You’ve ignored them. I stand by my sense of humor. A lot of jokes aren’t very funny if you ignore the tone which which they’re thrown around (here, obviously, tone was indicated by the use of emoticons).
027 // Matt Wilcox // 11.20.2007 // 2:21 PM
Please don’t misunderstand, I did see that you were intending it as a joke (nor was I offended, despite sitting in the middle of the fence on that particular art/engineering topic), my point was rather to try and illustrate how easy it is to miss your intended tone and get totally the wrong idea because of the writing style.
Smilies are so misused on forums by the kind of people who think they can say anything and get away with it by putting a :p at the end, that I for one no longer ‘read’ them. If you can mis-read the tone of a sentence it’s just as easy to mis-read the tone of the smilies strung at the end. Does a :-) say “haha, i’m being fun” or does it say “haha, up yours” when placed at the end of a loaded sentence? Jokes where you need to understand the tone they were written in are far too easy to mis-read in text form - whether you’re hypersensitive or not ;-) [see what I did there? Am I joking or am I a bit pissed off? … ;-)]
Anyway, keep on posting articles - the last couple have had a few unfortunate overtones, but as always they’ve been stimulating.
028 // Jeff L // 11.20.2007 // 2:50 PM
I agree completely. Back to when you called HTML and CSS coders nothing more than monkeys. You have a lot of good things to say, but it’s a shame you feel the need to insult people to make your points.
As far as frameworks go? All depends on the need, I suppose. I guess my biggest argument about CSS frameworks specifically is just that I’d doubt that for general consumption they would be flexible enough to handle a variety of designs. For someone who has to maintain a bunch of internal sites with similiar layouts, perhaps.
029 // Jeff Croft // 11.20.2007 // 3:44 PM
I appreciate the constructive criticism about my writing style. I’ll take it into consideration. However, I don’t know that I really want to change it. It’s gotten me where I am today. If I don’t have strong opinions and a way of communicating them that makes people think, I don’t see a whole lot of point in writing at all.
That having been said, I definitely don’t intend to insult anyone — especially individuals — and I’ll try to be careful not to do that in the future.
That is so completely not what I said. It’s a pretty drastic bastardization of what I said.
If a particular framework limits you, then I would say it’s not a very good implementation of the idea. The point of frameworks is to take care of those tasks that you have to do on every single site — tasks like resetting browser defaults. If a framework is limited to handling these sorts of things, I don’t see any way it could not be flexible enough.
030 // Matt Wilcox // 11.20.2007 // 4:12 PM
Certainly whether you want to change your writing style or not is a choice for you, and while I am attempting to point out how your words can be (mis)read, I don’t mean to imply that you should change your style, only that you may benefit yourself by taking a look at it. There most certainly is a need for passion and provocative thoughts - and it is those very things which keep me coming back here. The demeanour displayed through your site is also why I feel comfortable commenting at all - you come across as an interesting “sound geezer” (to use a Britishism) who wants to engage with an audience to improve themselves through debate. That’s all good stuff.
Your writing style may or may not have got you where you are today (however I suggest that it will have had little to do with your achievements in the grand scheme of things, that it has simply been along for the ride), but I hope you are aware that the style an author writes in itself elicits a certain type of reaction from the reader. If you are not happy with the reaction going on with your blog entries, then I suggest the only viable non-destructive option is to take responsibility for how people read (and misread) your words and to ensure your style doesn’t easily provoke what you feel are inappropriate interpretation and responses.
:)
031 // Jeff Croft // 11.20.2007 // 4:17 PM
Thanks — that’s all stuff I definitely try to achieve, so I’m glad it’s coming through.
You may or may not be right here, but either way: if it’s not broken, don’t fix it — right? :) You could, of course, argue that there has been something broken about it the last few days, and I wouldn’t disagree.
Generally, I am happy with the reaction my blog posts generate. I wasn’t happy with the reaction of the first post on CSS frameworks, and I have subsequently, as you suggest, taken a look back and what I wrote and why it resulted in those reactions. That look back resulted in me apologizing several times to several people, and being very careful to indicate where I’m being light-hearted in follow-up posts.
So…I know you’re trying to help, and I do appreciate it. We all need to be called out once in a while, and I certainly deserved it, here. I just believe I’m already taking the steps you suggest, is all.
Thanks!
032 // Matt Wilcox // 11.20.2007 // 4:27 PM
Well if you’re already onto it then I shall shut my cake-hole. :)
I’m looking forward to the next post, as always. Cheers Jeff.
033 // Andy Clarke // 11.20.2007 // 5:06 PM
(Muppet clarification: The words that follow are intended to be humorous. Reading the following words implies that you have read and accepted the Terms and Conditions for this comment which may be found somewhere under my bed in a shoebox.)
“The final word on frameworks, from someone way smarter than me”
I thought from the title of your post that you were talking about me. Oh well, back to being a poncy artist I suppose.
034 // ben // 11.20.2007 // 7:03 PM
@Charles Roper 16:
You write that I make an “assertion that one must fully understand a technology before being permitted to use it” and call that assertion “unpragmatic and plain wrong.”
You’re reading an awful lot into what I wrote. Cf. Jeff’s comment about how he started using Django before learning Python - and your own feedback suggests that we should all just dive in, with alacrity if not actual abandon.
For most of the people in this thread - people who’ve presumably got quite a bit of experience building sites, as a rule - that’s one thing. They (we) know which forums to go to with questions, they have extensive professional networks, and they have reputations to properly feed and care for. They’re likely to walk before they can run.
They’re also more likely to have libraries of their own, which is why I am deeply suspicious of the true nature of the target-audience-in-fact…
What of less experienced people, especially those on the make? (Think the guy who’s crazy-better at selling than he is at actually building the things.) What happens when someone has a bad experience with just such a vendor? Do the manner in which frameworks are promoted and supported encourage thoughtful use, or thoughtless use?
I’m not saying that frameworks shouldn’t be used, much less that they shouldn’t exist - just that the current state of things (tool sophistication, abstraction issues, median level of developer knowledge) stands to create at least as many problems as it solves.
The $bestToolEVAR is a wonderful thing, but in my ten years of practical experience such things tend to be Swiss Army Knives used in situations where the dev team would be better off using Xacto blades - heavier, more unwieldy, and ill-suited to doing any but a very few jobs well. Thus my hostility.
035 // Jeff Croft // 11.20.2007 // 7:07 PM
To put it bluntly: that’s their problem, not mine.
You could make the same argument about, say, power tools. Without proper instruction, someone could cut their arm off. Because of this, the manufacturers of power tools have some responsibility to either provide proper instruction or make it very clear that this tool is for people that know what they’re doing (or both). If people still cut their arm off — well, that sucks, but it’s not the tool manufacturer’s fault.
036 // ben // 11.20.2007 // 8:01 PM
…Just so we’re clear - when someone comes on the scene with tools they don’t know how to use and a customer gets screwed, that hurts all of us.
I’m not saying that any one person or named group/clique should be called to task for that outcome.
Rather, I believe that as a community of tradesmen we have a responsibility to our market and to our own - and that the status quo (including the zeitgeist with respect to frameworks) does a really crappy job of fulfilling that responsibility.
It’s obvious that clients get part of the blame for the problem too - because too many of them have unrealistic expectations - but regardless of who gets the blame or why, I’m a strong proponent of ideas that will resolve the problem instead of exacerbating it.
I’m done going totally meta, now. Thanks for reading.
037 // Jeff Croft // 11.20.2007 // 8:15 PM
I do agree with this, but I also think that this responsibility we have to the web, our community, and “our own” comes second to the responsibility I have to the people who are paying my bills (directly, my employer, and indirectly, our clients). Generally speaking, I try to put the user first, because if the user’s happy, so is the client (usually), and therefor so is my employer.
Most of the things I talk about here on my blog are simply techniques, tools, and ideas I have that seem to work for me, towards my priorities. I don’t pretend they’ll also work for you, towards yours, but I still think it’s healthy to talk about why I do what I do, and I think it does help people more often than it doesn’t.
038 // Charles Roper // 11.21.2007 // 2:38 AM
Same with any profession. That’s why in some professions you need to be fully qualified (in the formal sense) or possess a licence to operate. Are you suggesting web designers should be qualified and certified before they are set loose on the market? I am profoundly against that idea.
I absolutely agree as web professionals we have a responsibility to our own. However, I don’t agree that the current web community at large does such a bad job of fulfilling this responsibility. Name one other profession where there is such a culture of sharing knowledge, technique and best practice. For free.
Bottom line is, I don’t think it is frameworks that are at fault here; it’s unprofessional, ignorant people trying to make a fast buck. There will always be those people about and I don’t envy the client’s task of trying to avoid them. But to denounce the concept of frameworks in general as a bad idea - as you have clearly done - is to aim your frustration at the wrong target. I personally firmly believe that frameworks (in the strict and loose sense) have done far more good for the web than bad. They have inspired people like Jeff (with Django and Python) and myself (with Rails and Ruby) to learn something new (and learn it well). They have inspired long-in-the-tooth developers to re-look at how they code and take on new patterns and best practice (MVC, DRY, REST, Agile development, etc.) How can the negatives of these things possibly outweigh the overwhelming positives? How many clients are truly “getting screwed” because of naive or unscrupulous designers and developers?
I hope that this relatively new idea of CSS frameworks can inspire a similar new wave of thinking and best practice in the community. I must admit, the blogs have been a bit stale of late, with seemingly endless posts about what conference one speaking at or where one is jetting off to on yet another tiresome international engagement. Current CSS frameworks are far from perfect; they need nurturing and care. My own frustration mirrors Jeff’s in that it seemed everyone with a voice (i.e. decent readership) in this community was dismissing CSS frameworks as being at best “only for rapid prototyping” or at worst “a bad idea”. It seems an incredible shame that new ideas get so bluntly dismissed like this but, then again, no one is stopping anyone from blogging about or otherwise promoting new ideas. That’s the beauty of the web. I personally applaud Jeff for taking a stand and busting some balls. He cracked a few eggs on the way, but how else does one make a delicious omelette. Or should that be cake? With cake-mix or crafted from scratch? Okay, we’d better not get into that one again. :-)
039 // Dan Conner // 11.21.2007 // 9:27 AM
just want to say that reading through these posts and their comments has been good for me, I think some of my ideas and values I have been challenged in a good way. thanks for sharing your thoughts Jeff, and your commitment to the comments on your site is without precedent.
040 // Andrea // 11.21.2007 // 10:17 AM
A few thoughts:
041 // Jason Beaird // 11.21.2007 // 10:43 AM
I don’t really understand the heat involved in some of the arguments here. It’s like arguing over what kind of hammer to use or your favorite BBQ sauce. It’s funny you say that Kieth, because people here in SC will go to blows over the supremacy of their favorite BBQ base. Being from FL, I think they’re all nuts, and honestly I feel the same way about this CSS frameworks discussion. While I understand what Malarkey was saying with his playful cake-mix jab, I also know that frameworks in programming are just plain common sense. For the sake of all that is worthwhile and noteworthy, please stop flaming Jeff in the comments of his own blog so he can write about something new for once. :)
042 // Kenny Meyers // 11.21.2007 // 10:56 AM
Hey Jeff,
We met at Seattle Refresh, I had the name tag on my arm.
I understand that a lot of people’s feelings were hurt here, including yours, and I really can think of only one reason why.
It must be the French.
Cheers! Kenny
*Disclaimer: This is a joke.
043 // Andrew Meyer // 11.21.2007 // 2:05 PM
I’m new to this discussion, but I just have a few things to note. I’m particularly fascinated with the notion of code being art and therefore something that artists (?) should not outsource to a framework (or library, or snippet, respectively). I am an art student currently and something in some of my classes we’ve considered at length is our cultural history with labor and the effect it has had on our perception of value in art.
Since more labor oftentimes leads to a greater market value (there are many things we get billed on based on the amount of time it took to accomplish), there is a notion that the value of a piece of art should be related to the amount of work that went into creating it. The validity of this notion should be questioned, especially in the context of web design/development/etc.
If the purpose of web design or application design is to meet some sort of need (to get something done), the value of it should be assessed according to how well it does this. The amount of time or effort that went into it’s creation need not be considered if it accomplishes its purpose well.
Therefore, if using a framework/library/snippet best accomplishes the purpose of the given scenario, by all means, it should be employed. And that, not at all, to the discredit of the designer/engineer/artist who made the decision to do so. After all, they’re accomplishing the goals efficiently and successfully.
044 // Jeff L // 11.21.2007 // 3:42 PM
So, would you consider a single browser reset file (like Yahoo offers, or Eric Meyer recently provided) a framework?
I wouldn’t….
Blueprint seems like a framework….. YUI Grids seems like a framework. If you developed a site around those and then wanted to get rid of them, you’d have a ton of rework to do - the markup would be pretty well coupled w/ the CSS.
A browser reset CSS isn’t quite the same. Even at my job, we have a base set of 5 CSS files we start every project with… base, interface, content, navigation, forms. All our basic ID’s and classes are prefilled. The base file contains actual CSS, the other files just contain placeholders for nav, footer, etc.
I still wouldn’t call that a framework though - the CSS gets written for each new site. I’m not sure what I WOULD call it, though.
I think the general theory of what you are advocating here is great, and maybe more people actually do it than realize it, because I think the word ‘framework’ just doesn’t apply well to CSS.
045 // Jeff Croft // 11.21.2007 // 3:54 PM
The scope of that is probably small enough that it’d be more accurately defined as a “library,” but really, who cares what you call it? The basic purpose is the same as Blueprint’s: to abstract a common set of style into something you can reuse over and over.
New CSS gets written for each Blueprint site, too. I’m not sure why you’re so concerned with what you’d call it, but if you must name it, it sure sounds like a framework to me.
The sad thing is, most people are spending o much time focusing of the name of the thing, they’re ignoring the concept and theory behind it.
046 // Matt Wilcox // 11.21.2007 // 5:02 PM
@ Andrew Meyer
I wouldn’t consider mark-up an art, after all art is about expression - and mark-up / coding style doesn’t change the expression of the final output. But I would consider it a craft.
Please allow me to make a crude and not entirely accurate analogy:
Anyone capable of using a saw, hammer, and nails can make a functional wooden chair. Or that same person could save time and build a better chair by buying a pre-fabricated kit from IKEA. Neither chair will be as good as one made by a master carpenter - not because they do not function as well (all of those chairs get sat on, they all support you just as well as the others) - but because there is a different level of quality in each method of construction. The chairs and their methods of construction are analogous to the ways in which people may choose to author a website.
The hobbled together one works fine and may even look good, but it has rough edges and doesn’t use “proper” joinery techniques. This is similar to someone familiar with basic HTML but not experienced in many of the caveats and practices that might be used (Web Standards, Accessibility, etc.).
The IKEA chair is functional, and pretty, but there are many similar copies, and the skills learned in making it will not help you make a table from scratch. They only help if you build more IKEA furniture. You may learn a little about carpentry itself from studying how the IKEA chair has been made - but you only learn the IKEA method of chair construction. This is similar to using a framework to create a website (whether that framework be a CSS one, or a JavaScript one, or a WordPress blog, or whatever you want to think of as a framework for the web.)
The master carpenter’s chair is well made, well designed, unique, and the skills he used to make it can be applied to other furniture very well. The master carpenter has learned the proper use of the tools of the trade, and the best ways to use them. This is similar to expert coders building websites.
This is why I believe that XHTML and CSS authoring, though very simple and non-programatic, can still be considered a craft. There are many ways to get a visually and functionally similar result, but the methods used and reasons for those choices vary considerably.
Just as any chair does the same job as any other, with some you can appreciate the quality of the craftsmanship, and some work more elegantly than others. Whether you as a user care which you need or want depends entirely on what you circumstances, resources, and requirements - there is nothing wrong with any of those chairs.
047 // Matt Wilcox // 11.21.2007 // 5:09 PM
My last sentence reads terribly, my bad! Should be:
Just as any chair does the same job as any other, with some you can appreciate the quality of the craftsmanship, and some work more elegantly than others. Whether you care about those subtleties, and what you require as a chair user and maker, depends entirely on your circumstances, resources, and requirements - there is nothing wrong with any of those chairs.
048 // Jeff Croft // 11.21.2007 // 5:20 PM
Matthew: I think your chair analogy is pretty good. The IKEA systems are no doubt a framework, of sorts. And you’re right — in the case of chairs, everyone would rather have a beautifully hand-crafted one than an IKEA one.
But here’s where the analogy falls down: Whereas that IKEA chair will, at some point, show its “true colors” as less-than-masterfully crafted, a website built using (for example) Blueprint probably won’t. With the IKEA chair, regular people (i.e. non-carpenters) are going to eventually find that it scratches easily, doesn’t last as long, isn’t as sturdy, etc. On the other hand, regular people (i.e. non-web designers) are probably never going to be able to tell that a site built using Blueprint is anything less than completely hand-made. It won’t be less reliable, slower, less beautiful, etc.
Web designers will be able to tell, but regular people won’t — which is why I said in my original post that the only thing hurt by the use of CSS frameworks is the feelings of web design purists. Developers, clients, and end users (i.e. regular people) aren’t negatively impacted at all.
049 // Matt Wilcox // 11.21.2007 // 5:58 PM
You’re quite right Jeff, the analogy only works so far before breaking. This particular one is a bit stretched when you get to the issues you point out - though I suppose if you were to stick with it you might say that the quality of the supplier dictates how soon (or whether at all) the punter notices any limitations or deficiencies in the chairs (Are IKEA chairs better than B&Q chairs, for example).
Framework’s are similar, in that some are better than others for particular uses - but I admit the anaolgy is still weak, and that you are correct in that end punters are unlikely to see any ‘flaws’ (perhaps trade-offs is a better word) that they will associate with the framework itself. However that does not mean that there aren’t any that the punter no-less experiences (again, very dependant on the framework.)
For example JavaScript frameworks do have noticeable drawbacks, among which are multiple http requests due to the way they are factored (jQuery’s plug-in system for example), and file sizes that are much larger than they strictly need be. Particular functions may run slowly on certain pages in certain uses - Gmail, for example, can really bog down. So can Yahoo Mail. That’s because of the JavaScript frameworks they run on. Now, the end user may not be able to understand that the reason some web 2.0 applications are slow is because of the penalties abstraction (frameworks) can cause for performance - but that doesn’t change the fact that they experience those penalties. The difference is that instead of blaming a framework, they simply think the product is slow (Gmail, Yahoo Mail, Digg…). i.e., rather than blaming the joinery for a wonky chair, they blame the chair itself as being intrinsically wonky.
Anyway, that’s rather getting away from the topic - CSS frameworks (I still prefer ‘library’) are so simple that the actual performance penalties are currently not that big. The JavaScript frameworks however point to issues that could be experienced were CSS frameworks to grow sufficiently complex. Blue-print, for example, has developed a plug-in system like jQuery. So it is already emulating the problem of additional http requests delaying page load and increasing server processing time and traffic, in addition to having ‘bloated’ CSS files.
Again, none of that means that frameworks are bad (I love jQuery for example) - but simply that frameworks, even simple CSS ones, do have pros and cons, and that a responsible developer will look at those cons and judge whether the framework in question is right for them. Which is what most people have already said. So, getting back to the original point “What’s not to love about Frameworks?” - performance impact, learning curve, and increased complexity. But they have a hell of a lot of advantages that can outweigh those ‘not loveable’ things.
050 // Jeff Croft // 11.21.2007 // 6:01 PM
I do agree with everything you’ve said there, Matt. Well-said.
051 // Matt Wilcox // 11.21.2007 // 6:14 PM
“Increased complexity” needs better definition. From an authors standpoint complexity of course decreases - that is after all part of the point of a framework - to take the hard work out of implementing certain functions and behaviours. However, by abstracting that authoring complexity, it does increase management complexity. A framework needs to be maintained and integrated, and any inherent bug or limitation of the framework itself means doing complex workarounds (or even worse hacking the framework itself). This is why some frameworks are inappropriate for some jobs - they actually increase complexity. You tend to have to know the framework well before you can decide if it will work as expected for a certain project.
That is what I meant by “increased complexity”, and again, it doesn’t hold too well for CSS frameworks at the moment, because CSS frameworks at the moment are so simple. But it could easilly do so in future.
052 // Pieter-Jan // 11.22.2007 // 11:14 AM
[quote] That is what I meant by “increased complexity”, and again, it doesn’t hold too well for CSS frameworks at the moment, because CSS frameworks at the moment are so simple. But it could easilly do so in future. [/quote]
Agree on that one, but I heard that there will be some big changes in the CSS framework. After the updates it should work fine with other frameworks. But when it comes? I don’t know :)
053 // Fouad Masoud // 11.25.2007 // 8 AM
A voice from the Arab word.
Well! I’ve been reading through all the posts and the comments and related posts and related comments for a while now. So I pretty much have a solid idea about what the debate is all about. And I would never go into such a debate unless I feel strong about it.
If am to have a say on this I would ditch the whole idea of CSS frameworks out the window cause I really cant think of anything that can be “framed” other than the CSS reset, and for that matter its already out there being used by most of us if not all of us. Jeff said that he only cares about the design well as designs are getting more and more attractive they’re getting more and more complex thus each and every design is a unique case of its own, pushing a CSS framework means thinking in a layout box. Blueprint for example is a set of good CSS blocks, though I don’t really like the grids there; still I would never adopt such a thing, but ill extract what’s good from it to use in my own work. To me a CSS Framework sounds more like “Farming the CSS work”.
Now name it as you wish “Frameworks, libraries, and/or snippets” at the end its something for smart people and dumb, smart people use it as a way to perfect there work and to make it easer, better, and quicker. Dumb people on the other hand use it to stay dump. With the web growing and while having lots of newbie’s and people joining the web industry; frameworks are making a big problem not solving one, they are giving dumb people the mean and reason to stay dumb. Those people are learning Blueprint “for example” memorizing the names there and the structure while they can’t build one of there own. I can imagine a forum or a blog for trouble shooting problems with using such a framework. Or asking someone about the version of CSS he/she is using and he/she saying blueprint.
CSS Framework sounds good to the ear, very hard to implement. Yes everybody has his set of CSS in one file, but it’s his own he knows what and where to edit and delete, I my self tried to use blueprint in one of my projects and I ended up overwriting almost everything. Somehow I think it’s the case of everyone.
XHTML/CSS is a craft “I agree” so is “sculpture” to me a web site has to go through the process of creation; a designer creates the solid merely image concept an XHTMLer gives it a shape that’s well known to the web and a developer gives it life. The problem with XHTMLers is that they are always in the middle of things they are bottle nicks for some companies. XHTMLing in some companies is done by the designers sometimes, while other times it’s done by the developers if not both………………………..
054 // Fouad Masoud // 11.25.2007 // 8:02 AM
………………But guys you tell me how many people out there working with the web knows the difference between each and every HTML/XHTML/CSS/JS version ever built, how money people has tried every CSS trick in the book, how many people knows all browsers by heart, how many people validates there work, and how many people has the passion to think (markup is: Logic, semantics, SEO, Bandwidth, speed, visitors, accessibility) most of that applies to CSS. Tell me how many read all the specifications and how money knows what’s coming and going. I am proud to be an XHTMLer who has all that in his pocket and I am proud for being able to be on top of things, and I am proud for being able to spot any problem and fix it “in worst cases” in an hour. Can a newbie armed with frameworks do that I really don’t think so.
Can someone replace me at my company, I don’t think so, can someone who visited a couple of site and read a couple of books about HTML/CSS do what I do, never! That’s the case with all HTMLers out there. We aren’t easy to replace. And we aren’t afraid to lose our jobs working on the XHTML/CSS front has its ups, you get to design and develop too, when its time “speaking for my self” ill shift.
You once said that learning HTML/CSS is very easy “it is easy” as easy as holding a brush or opening Photoshop it’s always easy to identify the tools but its not that easy to have the skill to use that tool.
This can go for ever.
055 // Sean McGee // 12.11.2007 // 12:17 PM
Wow. When did us web designers become elitists?
Are you all listening to yourselves? There are FAR more important things going on in the world.
Ben: I suggest you devote your energies to saving Darfur than bashing frameworks. You obviously have no programming background if you can not see the benefit of frameworks.
Jeff: Your posts rock, keep up the good work.
056 // Michael Schuerig // 12.12.2007 // 5:44 PM
I’m a programmer, love frameworks, and only incidentally write CSS every now and then.
From my perspective, there is no such thing as a CSS framework. The debilitating limitations of CSS simply preclude this. CSS has barely any means of abstraction, you can’t even do things as basic as defining constants for colors and dimensions.
These limitations impose a very low ceiling on what so-called CSS frameworks can do: You gain just one level of abstraction over specifying style properties for each element individually. That’s not entirely bad, of course.
Still, the resulting markup tends to be unpleasant. Apparently, it is quite common, to have numerous classes per element that barely convey any semantics.
Now, a true framework would provide a “mechanism”-layer in just the way Blueprint or YUI! grids do. But, and that is essential, it would allow the designer to define a semantically meaningful “policy”-layer on top of that.
This further abstraction is not possible within CSS — and that’s too bad.
057 // Wes Turner // 12.17.2007 // 11:35 PM
So there were designers and developers united at a harmonious bake sale. After singing kumbaya, the developers unfolded battle-tested tables and chairs and the designers arranged the tablecloths and centrepieces. Some patrons purchased store bought cookies, some dug the home baked biscuits. Relevantly, a heated discussion erupted when a subversive suggested using manufactured linen for the tablecloths, rather than finely sewn silk. All in all, the bake sale went over well. Thank you Jeff.