Twitter Bottstrap is the single greatest thing to happen to my web dev abilities. I now go from start to shipped in under 3 days on most ideas, whereas before it would take 2 days for dev, then 2 weeks for design that I could never get right.
I've been using Zurb Foundation for a recent contracting gig, and am pretty happy with it. Can anyone who is more into these things compare it, in a thoughtful way, to Twitter Bootstrap?
I find foundation great for rapid prototyping, I can build a mockup in foundation in a few minutes and then iteratively improve on the design until it becomes a real product, as the name implies it's really a foundation to build on, it doesn't give you everything but it gives you 90% of what you need in a way that isn't restrictive.
Bootstrap gives you a lot more than foundation does, but I find it very restrictive, it's hard to make a bootstrap site not look like bootstrap (if anyone can point me to some counter examples I'd be interested). This is unsurprising since bootstrap was designed by twitter for a consistent look across their internal tools.
So my verdict is, for internal tools / quick hacks, use bootstrap. For mockups and real products, use foundation.
Bootstrap's styles are more polished and comprehensive than Foundation's. Foundation's CSS file is very well commented and half the size of Bootstrap's. Bootstrap's modals work with IE8, with Foundation's modal I get an error. Foundation's Orbit JS slideshow is easy to implement, but seems a little buggy in FF.
phpnode got it right - I'd be more inclined to use Bootstrap in cases for which I have no design, or a simple design with latitude for many elements. Client extranet, back-end utilities, etc.
I've used them both. A major advantage Foundation has was a responsive grid system, thought I've read that responsive grid for Bootstrap is in the works.
One weak point I see in bootstrap is that you'll get somewhat of a default look, similar to default/common blog themes. It would be great if there were some kind of "bootstrap mixin" that quickly changes a few of the colors and other CSS options to create a slightly different experience. Nothing really major, which is why I'd be reluctant calling it a theme (i.e. more like "Bootstrap Hot Dog Stand" than "Bootstrap Themeforest").
The problem with bootstrap is only a small portion of it's design aspects can be changed. This is a problem with the way they've (not) used LESS. The only variables are colors and the font. Options for sizes, spacing, some layout options how you want to the topbar to work are all much more limited and harder to do. So for the most part aside from color, if you are using bootstrap it's going to look like a bootstrap site.
This is fairly different from say Blueprint/Compass where almost anything can be tweaked just with SASS varaibles.
But the whole point of Bootstrap is for _non_ designers to be able to make decent looking sites with minimal effort. Give them control over things like spacing and font sizes, and most of them will get it very, very, wrong.
Well, the grid system of bootstrap could be used for a lot of wrongness, but by then you'd be avoiding most of its base system anyway and could do the same amount of damage with any kind of simple CSS grid.
I'd go a step farther and say that even the little bits you can change are prone to abuse and/or simple hard to get right for a number of non-designers. The generator system above actually just fills in some blanks, which isn't exactly the difficult part for programmers. It's what you fill in those values… My idea for some part of "custom" generator would be selecting a palette from a reasonable large number and then probably some basic font types and weights, similar to type-a-file[1]. Then add some customized icon set[2][3], and you've got something that's at least a bit more unique.
As the links above are probably intended for someone who hasn't yet come across a CSS framework, I'll post the following comment.
Using Blueprint CSS (and probably 960.gs too) feels like going back to table-based layouts. You set up columns, and extra wrapper divs. I don't know if it's a help or a hindrance.
I'm far, far from being a "front end" coder. So I can't comment on if this produces good HTML. If however it allows me to get something up quickly without having to become a "front-end" coder, then it's going to be very useful for me.
Incidentally, it doesn't "produce" any markup. There are form generators for at least Rails available, but generally you do whatever to get the markup to conform to their expected structure.
That being said my experience is heavy on the forms portion of their styling, and there is an extraneous div.input wrapped around each element, but you'd often do something like that on your own anyhow.
I've listened to the debate about this for ages, taking everything on faith. From what I've learned, you can't truly separate layout and HTML. The best you can do is make it so minor layout changes will require only changes to the CSS. Big layout changes always seem to require changes to the HTML. People cite ZenGarden as an example of major changes with just CSS, but their markup is full of more id's and classes than would be reasonable for an everyday site. And people spend a long time tweaking to get stuff to work across browsers.
So I completely agree that using this (and most other CSS frameworks) is going backwards a bit in mixing layout with HTML. But I actually always did that. I just wish writers on the subject would help me not be confused by starting out by admitting that they are not following the notion of layout done in CSS.
Some people posted on here that Bootstrap is just for getting quick prototypes done, and then when things are stabilized, you should switch over to semantic, properly separated CSS. But if so, is that the intentions for all grid based CSS frameworks?
The intention of CSS grid frameworks certainly was at one time limited to rapid prototyping, but I'm seeing more and more sites deployed with default grid classes and CSS intact.
Using divs with classes of row, column, span_X, grid_x, et al. is, from a semantic standpoint, no better than using tables. And Bootstrap's CSS file is nearly 2500 lines, unminified with a 47K minified file size. That's a lot of overhead if you only need grid, typography and pretty forms.
It makes a lot of sense to keep the full CSS file linked while iterating the design/layout, but once it's in production, the grid classes can be replaced with semantic names and the extraneous styles removed. Here's an article I found on the 960gs homepage that covers not only combining/renaming classes, but also minimizing the amount of extraneous container divs: http://www.webdesignerdepot.com/2010/03/fight-div-itis-and-c...
No. It is incorrect to use tables used for layout, and this widespread practice has made it impossible for user agents to treat tables specially.
A div exists to have no meaning. Using it for layout doesn't hurt anything except page size (unless there was a more specific element that you could have used accurately instead).
I don't understand how we're in the year 2012 and people are still repeating these "rules" without any understanding of why they might matter.
You're confusing my reference to DIVitis with my comment about layout in the HTML. The examples providied by the Bootstrap page are stuffed with unnecessary DIVs. I'm a web developer, so I know that DIVs exists to provide containers which add no semantic meaning to the page. But putting classes into your HTML which say class='row' or class='leftcolumn' means that you can't just change the CSS in order to change the layout - which is the whole purpose of CSS in the first place. All grid systems suffer from this weakness.
Consider this example based on the Bootstrap examples - you have three boxes containing stuff within a DIV with a class of 'row'. At some point in the future you decide to turn this into a column. Easy to do in the CSS - just change the width to the with of one item, and they'll stack on top of each other. BUT, now you have a column labelled 'row' in your HTML. This is a fairly simple to rectify example, but this problem is pervasive in grid systems.
A big thank you to all who worked on it!