I like a nice responsive grid system like http://csswizardry.com/2013/02/introducing-csswizardry-grids/ and normalize, but that’s really about it
Now, I can’t say I’ve tried many frameworks. I’ve only really worked with Bootstrap, Inuit and Foundation, and so far I have found them all lacking in some way or another.
– **Bootstrap** looked like a great idea when it first came out, but working with it was a pain, not to mention the characteristic look. I migrated from LESS to SASS a while ago, so I haven’t had the chance to see if newer versions are any prettier. (To be honest, I’m a little reluctant to use Thomas McDonald’s SASS port of Bootstrap)
– **Inuit**’s certainly the one that has gotten the least in my way. It’s also about as extensively documented as a CSS microframework can be, which is a great thing. But, to be honest, as much as I have been beaten into admiration by Harry Roberts’ uncompromising blog posts, Inuit has done hardly anything to help me.
– And I’ve only had a brief look at **Foundation** before I knew I’ll definitely be using something else on my next project. The huge _settings.scss was the first thing that made me cringe, and then I saw that the whole thing, grids and all, sits on *goddamn ems*. Which is fine and dandy, I mean everyone loves those, right? Only if you’ve decided to ditch IE7 and provide minimal support for IE8 (not even grids!), why don’t you just get your sh*t together and use ***rems*** anyway?! They’re in IE9+ and every modern desktop or mobile browser imaginable for a reason, no?
The best way to do grids that I’ve ever seen anyone come up with, is the use of mixins. Only I couldn’t get Foundation’s grid mixins to work, at all. Those mixins were only one of the things that got me confused over my brief encounter with Foundation. The provided docs only made me more confused. And I value my time and my mental resources a little too highly to waste them sitting around being confused. All in all, Foundation seems to fall quite short of the promise made by its slick website.
Just picture this, just last week, as I was figuring out Foundation: I tell a h2 to be 12 columns wide, and suddenly the lateral padding becomes larger due to the h2’s larger font size, breaking the entire layout. (At least, unlike many others, they have the dignity (and common sense) to separate columns by padding and not by margins.) Apparently, this is why some folks recommend to use grid classes only as containers – but that’s a wee bit less flexible…
Less flexible? More like going back to the table age, I say! What is it other than replacing the occasional presentational class with tons of presentation-only, not to mention atrociously verbose, *non-semantic elements*? Who the hell comes up with these ideas, anyway? And if a grid column can’t seamlessly double as a grid container of its own, I’m outta here. How about being able to subdivide a nested container into the number of columns that it spans? I can kind of work without it, but is it too much to ask?
In principle, the concept of front-end frameworks makes perfect sense. They’re just libraries for the HTML/CSS/JS environment, right? What they (admirably) intend to do is bring DRY principles to the HTML/CSS world, which also makes ’em a perfect fit for preprocessors (didn’t see many CSS frameworks before the advent of those, did we?). And, at the end of the day, every other kind of programmer is able to rely on libraries that have been put together by someone else, and reviewed by a community of experienced professionals. So why should we front-end devs miss out?
However, I am filled with great dread at the thought that the frameworks which I have experienced fail to achieve the above; even more, they are the complete opposite. Miserable documentation forces the developer to look for answers in the source code for even the most simple of tasks. Having CSS-only versions of prepro-based frameworks is another thing that just feels completely wrong to me. You have no reason not to learn a preprocessor already! And, most importantly:
I have found myself reverse engineering every framework that I’ve ever used in order to undo something that I don’t want it to do, just about as often as I find that said framework is missing some fairly common ‘trick’ which I need to do on a daily basis, which is however neither obvious nor easy to pull off.
So far my personal “framework” features Normalize.css and a clean slate. I liked Semantic.gs before I was wooed onto the SASS bandwagon, so I think I’m going to try my luck with Susy next. I have also been positively impressed by the featureset of Compass and Bourbon; it’s high time I saw which one would fit me better.
P.S. They do say that putting asterisks in swearwords is akin to covering one’s mouth with one’s hand while performing fellatio amidst a public space on a busy day. In order to prevent myself from falling victim to such a wicked simile, I am compelled to apologize for the asterisks — but not the word choice! — rationalizing their judicious application by my unfamiliarity with this forum’s policy on profanity.
P.P.S. And sorry for the rant as well. I’m, like, just some dude with an opinion, man.
Yes, frameworks usually have more than you need, but that’s because they’re built to solve multiple problems. Many of the frameworks we know are young, and need to do a better job of being customizable. I’ve used a few built on SASS and having variables and mixins to customize how you use the framework is a big plus in avoiding bloat.
Frameworks can be frustrating at times, I’ve been there too. To me, the benefit of using a framework far outweighs the reasons not to use them.
Ideally speaking there is no point in using a ready-made framework, you should study there code structure & identify at what particular situations you can use it. Other wise a lot of un-used code stays in your application. The application bloats.
What I’ve done is completely separated twitter bootstrap framework into multiple files. Eg. layout.css: has all the bootstrap width classes, typography.css: All default text styling provided by twitter bootstrap, alert.css: all alert messages css, nav.css: all css code which generates menus, table.css: there table formatting css code. & so on…
Now when it comes to integration If I’m to create tabs for a particular module. I take one parent element & append all classes to it. Eg. #sidebar .nav, #sidebar .nav li
This does increase the code length, but I can always optimize it later, cause I know which are the common elements.
So my suggestion would be not to use a specific framework as it is, but to break it & use it.
I’m assuming most people here are freelancers who don’t work in teams.
When you have several people working on the project together, frameworks become crazy valuable, because everybody talks the same language, follows the same conventions, etc. Plus frameworks continually evolve, so when one of the team members figures out a better way to do something we can fold that right into the framework for the current/next project and even past projects.
Plus, when someone new joins the team, we have complete documentation and training to hand over to them to get them up to speed right away.
@JasonRCI Second that, I discovered this when I started working in agencies..
I didn’t like any of the existing frameworks out there, so I just created my own framework.
[Cascade Framework](http://cascade-framework.com/ “Cascade Framework”) combines a very light footprint with feature richness bacause of an ultra-modular OOCSS based architecture.
With [Cascade Framework](http://cascade-framework.com/ “Cascade Framework”), **YOU** choose whether to use, replace, overwrite or just exclude features like grid classes, responsiveness, color scheme, typography, table layouts, etc. That allows you to avoid the bloated mess you get with most other frameworks out there.
You must be logged in to reply to this topic.