
CSS 'frameworks' are missing the point (2008) - shubhamjain
http://stackoverflow.com/a/203133/388350
======
sergiotapia
I don't know about you "leet hacker pros" but I do know that using bootstrap 3
helped me make my site[1] completely responsive - with ease the like of which
the world has never seen the like of which[2]. If you are using bootstrap for
it's color choices you're doing it wrong.

What I do is have bootstrap.css vanilla loaded, then I load a
bootstrap_overrides.css.scss where I override styles/colors/looknfeel. Make
bootstrap my own, you know?

[1] - [http://smitecamp.com/](http://smitecamp.com/)

[2] -
[http://www.youtube.com/watch?v=UxVivkXUfdU&t=25](http://www.youtube.com/watch?v=UxVivkXUfdU&t=25)

~~~
mdular
You can compile Bootstrap yourself from LESS or SASS, pushing your own values
into the Bootstrap variables (and ideally sharing this configuration with your
custom styles). In the process you can choose not to include some Bootstrap
components, reducing it's weight significantly. It's NOT a lightweight
framework.

~~~
sergiotapia
I know I can do this, but I don't because I prefer to just download the
boostrap latest vanilla, and override as needed. That way every time there is
a new version I don't have to do mental gymnastics on what variables are new
or renamed.

~~~
mdular
I get your point, but at the same time your argument is an odd one to make.

At least the SASS-port of Bootstrap declares it's variables as defaults -
meaning they would not be set if they were set earlier (in your
configuration). This makes upgrading the gem (or plain source files) rather
simple. But sure, you might have to check if anything was renamed or added.

But with overriding you do not only create redundant, unnecessary styles (and
bytes), but if you now upgrade your bootstrap files as you suggest, you also
have to change your overrides - which depending on the amount of changes you
did will be significantly more work (and 'mental gymnastics') - if changes
were introduced.

So you gain very little (less setup effort) but lose quite a lot.

------
JeremyMorgan
Useless, not so much. The best solution all the time? Also not so much.

I agree with the points about it being just a large set of declarations, there
aren't a lot of good ways to lazy load CSS (that I know of) so in some cases
you're pushing a lot of bytes that you don't need to and creating dead weight.

Also the presentation in markup point is one I have been saying for years. We
hear about the death of tables and why it needed to happen and go back and do
similar stuff. But without extensive use of something like jQuery you have to
do it.

I think these frameworks are awesome for people like me. I'm a backend coder,
and I am not that good at CSS. I love being able to whip out a layout and
interfaces in a fraction of the time, so I can focus on what I do best. It's
not that I'm afraid of CSS (I can write it) it's just that I'm afraid of
wasting time.

This is the primary reason these frameworks have flourished IMO. Useless? Not
even close.

~~~
robmclarty
For sure. Bootstrap is good for... bootstrapping. After you've got your MVP
working and you're ready to make a real, custom, unique, differentiated,
improved user experience, you're going to need to hire a designer and someone
who can write CSS. Bootstrap isn't going to make the interface for your Great
New Thing (TM) and if your great new thing can be built with Bootstrap... idk,
maybe it's not so great?

------
_mtr
Completely invalid advice in 2014. LESS and SASS now provide everything that
CSS "can't do" in this answer.

~~~
Cynddl
The answer is still valid. LESS and SASS are CSS preprocessors, not
frameworks. Sending spaghetti code to the user's browser can be limited but
LESS and SASS do not address the flaw of CSS frameworks.

~~~
ryanbrunner
I think the point is that frameworks can be more effective now thanks to tools
like LESS and SASS (it's certainly possible to use Bootstrap this way, at
least with the sass translation). Compass is another example of a framework
that SASS enables.

Bloat of a hundred framework rules? - None of these will be included if you
use mixins and selectively mixin the stuff you need.

Unsemantic grid sizes - Personally, I think this is something where utility
trumps perceived "cleanness" of semantic HTML, but if you want to you can use
mixins for this as well to hide the grid stuff in your CSS.

Not responsive - SASS and LESS don't do anything specific here, but this is
_definitely_ an outdated comment - Bootstrap's responsive grid is probably
better than anything you could code yourself without devoting a lot of effort
to it.

------
overgard
Frameworks are awesome when you want something that's good enough without a
ton of work. I used to use bootstrap for a lot of tools that I didn't want to
look ugly, but that didn't need to be pixel perfect design masterpieces
either.

------
majc2
SO Question asker here - funny how advice from 6 years ago looks really odd
now! Just as a bit of context, the state of the art was BluePrint and YUI. Oh
how far we've come.

------
natural219
Even with less or sass, a basic, modern grid will have at least three levels
of DOM-level logic that determines presentation, so you have things like this:

    
    
      <div class="container">
        <nav class="row nav-header">
          <div class="col-sm-2 my-logo">
            <!-- your stuff -->
          </div>
        </div>
      </div>
    

that you could _perhaps_ use mixins to replace _some_ of the elements with
(you could mix-in "row" to "nav-header", and "col-sm-2" to "my-logo"), but
regardless, you still need three DOM nodes, and trying to fit those into a
purely semantic separate-structure-from-presentation box can get extremely
tiresome.

I definitely don't like this. That said, the speed and flexibility of
frameworks like Foundation/Bootstrap are just so vital for my front-end speed
that I can't imagine giving these things up.

One other advantage is that, if you're working with other front-end developers
who have used your same framework, there is a lot of knowledge sharing that
happens automatically (knowing when and where to use containers, for example,
can save a lot of headache when two devs are working on the same front-end
layout).

~~~
bjornsteffanson
You should check out Bourbon Neat:
[http://neat.bourbon.io/](http://neat.bourbon.io/), or leverage Sass' @extend
directive.

Your CSS could easily be shortened to:

    
    
      .body {
        @extend .container;
      }
    
      .nav-header {
        @extend .row;
      }
    
      .my-logo {
        @extend .col-sm-2;
      }
    

And your markup could be much cleaner:

    
    
      <body>
        <nav class="nav-header">
          <div class="my-logo">
            <!-- your stuff -->
          </div>
        </nav>
      </body>

~~~
natural219
Sorry, I don't think you understood my comment. First of all, container isn't
used like that (you don't want to wrap your entire content in one container --
maybe you want a different full-width background for your header vs your body,
for example). Secondly, this technique is exactly what I was describing --
using mixins (or @extend) in your CSS to eliminate the redundant classes.

Still, your final output produces three levels of DOM, which was exactly what
my point was. No matter how much you try to export your grid code into your
CSS (and you should try!), you will _always_ run into situations where you
need that <div class="row"> and there will be no way to semantically handle
that.

Furthermore, there are some limitations even when combining semantic elements
that cause issues. For instance, I often write this code:

    
    
      <div class="row well"> 
    

To find that the exact margin/padding values I want for my well interfere with
the default padding/margin values provided by row defaults. In those cases, I
almost always have to add an additional DOM level and separate my classes to
achieve my effect.

~~~
bjornsteffanson
I did misunderstand - apologies.

------
blktiger
When paired with less/sass, css frameworks can be used to build up your site
without inserting non-semantic classes into your html (by using
mixins/functions).

------
normloman
Frameworks are overkill for most of my projects. Maybe it's because I don't
write web apps, but I never need all of the features included in something
like bootstrap. Just a few of the modules. What's more, I'm overwriting much
of that code anyway when I style the site. In that regard, frameworks take
more work, and make sites harder to maintain.

I find frameworks more useful for rapid prototyping. I can make a cheap
wireframe with some bootstrap styles, and quickly move things around until I
get the layout I like. then I'll build the final draft from scratch.

~~~
ehutch79
You're mostly right that it's great for prototypes. However it's seriously
great for building webapps where design doesn't matter. such as when maybe a
half dozen people will ever see/use it.

------
jbeja
IMHO, the only ones that are "useless" at least for me, are the one that force
design decisions on my project, that why i end up using my own rules or just
use inuit.css if a feel lazy.

------
undoware
Pause the baby-photo gawking for a moment and consider the argument that's
still valid. There's an interesting reason why it is not entirely possible to
separate content from presentation: one cannot be abstracted from the other.
And this is interesting rather than a commonplace because -- mark this closely
-- we're still doing _something_ , some useful work, when the HTML and CSS are
put in separate files, even when the classes are things like 'span-27'.

So what are we doing?

------
PinguTS
It was true at the time. But as times have changed, the answer to this
question too if you think about possibility to do transitions in CSS and
define key frames for those transitions. Things previously done in Javascript
are now (partly) possible in CSS only. With that it makes sense frameworks for
CSS.

It does not matter if the framework is mixed in by SASS or LESS, because from
that point of view you could argue that Javascript frameworks are not
required, because they could be mixed in as well.

------
kaonashi
Stackoverflow had sense enough to close it as flamebait.

~~~
ehmuidifici
So the same could be done here! =)

------
davidhariri
I totally agree and have been saying this for years. CSS frameworks run a high
risk of overkill for 99% of apps. They also offer no potential for learning
and it's more difficult to strip back a framework than it is to build your
own. It's also super boring. No idea why anyone uses them for any creative
work. Also what is the deal with grid systems!?

~~~
ulisesrmzroche
They're really useful, and been around forever.
[http://en.wikipedia.org/wiki/Grid_(graphic_design)](http://en.wikipedia.org/wiki/Grid_\(graphic_design\))

------
callesgg
The nice thing with CSS frameworks is that one only has to design for one
device/screen. The designs for smaller screens, printing and other visual
device differences, just works.

------
websitescenes
And the lie detector determined that was a lie.

