Grow your CSS skills. Land your dream job.

Opinions on CSS Frameworks

  • # April 7, 2013 at 6:44 am

    I have just joined a development team on a client website which is half built using bootstrap and I think it would be much easier for me if I didn’t have to decipher through all the unnecessary css.

    # April 15, 2013 at 9:25 pm

    That is just it in my opinion. A bunch of extra stuff you will more than likely never use. Unless you learn the framework you will be using in and out and apply everything to every project, I think it is better to collect various snippets as I go that i find myself using all the time…

    Though i will say i dabbled with Blueprint on a few projects and it really wasn’t bad at all. I just prefer keeping things a little more organized/cleaner.

    # April 16, 2013 at 6:03 am

    I have used a bunch of frameworks and have been frustrated by the same issues as the rest of you. In particular, I was amazed by the lack of consideration for big screens as RWD seems obsessed with smaller viewports.

    As a result, I set about making my own. [You can see it here.](http://ashloudon.me/respondo/ “Respondo”)

    My focus was on keeping the learning curve as shallow as possible, avoiding bloat, maximising semantic elements and scaling **properly** across viewports. I also thought that we should have a touch-specific style sheet.

    The downloadable version is uncompressed and well commented so you can jump straight in.

    # April 16, 2013 at 10:08 am

    Try Sass with Compass or Bourbon.

    they are so useful, fun to use and nothing is imposed. You import what you want to
    use. There are several layout options as well, including Susy, Zen Grids, and Neat.

    # April 16, 2013 at 1:26 pm

    I use bootstrap when I’m developing a back-end without a front-end to plug into. I do more back-end work (developer, not designer), and I like output to at least slightly correlate with the desired end product.

    Frameworks clearly have a use. I don’t think their target is experienced designers, though.

    # April 16, 2013 at 3:02 pm

    Normalize is practically indispensable. It takes care of many little bugs between browsers but still leaves the natural functionality of the browser in place. Resets like Eric Meyer’s “Reset CSS” make a big mess of CSS and remove all basic styling, it’s just not a good thing to do project time wise or load time wise.

    Bootstrap has a lot of CSS it uses which can be heavy, but if you’re using LESS it’s easier to get what you want and then strip out the rest.

    The 960 Grid System is also very helpful if implemented correctly. If you’re designing for a CMS then you can create templates for the clients and they can more easily format content when they have no prior experience with HTML and CSS.

    It all depends on what your project is, but I would highly suggest Normalize and the 960 Grid System for every one if possible. I’ve built sites for companies all over the world and believe me it has saved me much frustration at times. lol

    # June 10, 2013 at 6:51 am

    I have written a blog post on this topic as my opinions have changed quite a lot regarding frameworks over the past few months!

    Feel free to give it a read: http://joshuajohnson.co.uk/blog/opinions-on-frameworks/

    # June 11, 2013 at 2:23 am

    Working on Css Framework is quite a mess. There are so many classes and inherit classes that overwrite if we create our own custom class. I am not in favour of using framework. Framework sucks really.

    # June 24, 2013 at 10:24 am

    I like a nice responsive grid system like http://csswizardry.com/2013/02/introducing-csswizardry-grids/ and normalize, but that’s really about it

    # June 24, 2013 at 11:35 am

    I like this post btw » http://hugogiraudel.com/2013/03/04/css-grids/

    # June 24, 2013 at 11:51 am

    > I like this post btw » http://hugogiraudel.com/2013/03/04/css-grids/

    I’m flattered. :)

    # June 24, 2013 at 11:51 am

    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?

    Next please!

    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.

    # June 24, 2013 at 2:17 pm

    In my opinion, the problem in general (and I say “general” more because I don’t think it’s restricted to CSS frameworks only) is that people more often than not misunderstand the use of frameworks. I feel like what happens is someone says, “OMG, *insert framework* is the best thing in the world and I’m going to use it for every one of my new projects!”. That may not make any sense for your next project, but we sometimes hammer at the square peg to make it fit the round hole over and over and over.

    Wordpress frameworks can make sense for certain applications. They were at some point built for one specific project or evolved out of someone’s project niche, right? But there are WordPress designers that base every new project they have on one framework they liked.

    I kind of mirror one of the guests of the Shoptalk Show when she said every time she heard ‘framework’ she internally cringed because to her each project should typically be unique because it doesn’t need the same stuff as the project before it.

    # June 24, 2013 at 11:28 pm

    I’ve been a developer for a long time, and whether it was php, perl, python, actionscript, javascript or css, I inevitably always ended up saving snippets of code into a file and making a custom framework. As project needs change, things would get added. What happens though is other developers working in the same company often add their own code and sometimes they make it better, sometimes worse. The great thing about frameworks is how it helps teams work together. When everyone on the team can look at the framework docs and know what needs to be done, it makes it easier for things to get done. You’re not always waiting for maybe that one guru on the team who knows the custom code so well because they wrote it. It also means that when you’re looking to hire another dev, you can know that if someone knows the same frameworks, he or she is able to step right in.

    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.

    - keith

    # June 25, 2013 at 12:46 am

    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.

Viewing 15 posts - 16 through 30 (of 35 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".