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).
I assume it's been posted here to show how much the thinking has changed since 2008.
Not just with the precompilers - LESS/SASS/Stylus - but with the overwhelming amount of web apps being developed with modern CSS frameworks like Bootstrap and Zurb Foundation.
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.
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.
Even within the strict scope of CSS this post shows it's age. The phrase above in particular reaks of being written in a time before philosophies such as OOCSS. Additionally, popular frameworks are no longer tied as tightly to fixed-pixel values.
If somebody were vehemently arguing these sorts of points today, I would be concerned that I was dealing with the type of developer who resists change or is opposed to exploring and understanding the approaches of others.
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.
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.
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.
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.
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.
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!?
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?
You can download bootstrap, modify their variables and compile it yourself. That way you don't have load more than one files and have rules that will never get used.
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.
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.
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.
I just use the Responsive Skeleton framework: http://www.getskeleton.com/ which is basically a grid system with some media queries. Then I can build whatever I want on top of that.
Saves time, overwriting a bunch of code and I can use it with whatever I want - Less, SASS, MYTH, etc.
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:
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).
I have the same conflicting feelings about it. One the one hand, yes the HTML should be semantic and not have things in it like "col-2". My thinking is that it's not so terrible as long as it's classnames. The tags and IDs can be more semantic and the classnames I kinda allow the cheating in my mind, considering it to be meta-data.
At a certain point we do actually have to produce a site or an app. If I mange to get the product released while keeping the code clean, organized and consistent then I feel like I'm doing OK.
Very much this. By wrapping your mind around the new possibilities the whole 'seperate style from content' becomes much more trivial (and so much more maintainable) that the discussion mostly ends at this point.
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.
No, you don't need all this, there are tools to help. Look at Susy for example. God knows how many times I deleted '<div class="row">' out of markup templates.
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'.
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.
Exactly. For someone like me who likes building websites for fun (and by myself), but sucks at design and CSS, Bootstrap is a godsend. Because of it, I can concentrate on the stuff that's fun for me while having a pretty reasonable-looking website.
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?
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.
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.
43 comments
[ 5.5 ms ] story [ 107 ms ] threadNot just with the precompilers - LESS/SASS/Stylus - but with the overwhelming amount of web apps being developed with modern CSS frameworks like Bootstrap and Zurb Foundation.
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.
Even within the strict scope of CSS this post shows it's age. The phrase above in particular reaks of being written in a time before philosophies such as OOCSS. Additionally, popular frameworks are no longer tied as tightly to fixed-pixel values.
If somebody were vehemently arguing these sorts of points today, I would be concerned that I was dealing with the type of developer who resists change or is opposed to exploring and understanding the approaches of others.
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.
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.
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/
[2] - http://www.youtube.com/watch?v=UxVivkXUfdU&t=25
You can even customize it on their server if you aren't comfortable doing it yourself: http://getbootstrap.com/customize/
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.
I don't agree. I've launched several semi-successful sites where I've used Bootstrap solely because of the looks. Why exactly is that wrong?
Saves time, overwriting a bunch of code and I can use it with whatever I want - Less, SASS, MYTH, etc.
Plus the code is about 200% cleaner.
[1] https://github.com/twbs/bootstrap/tree/master/less
[2] https://github.com/twbs/bootstrap-sass/tree/master/vendor/as...
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).
At a certain point we do actually have to produce a site or an app. If I mange to get the product released while keeping the code clean, organized and consistent then I feel like I'm doing OK.
Your CSS could easily be shortened to:
And your markup could be much cleaner: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:
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.So what are we doing?
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.