[egoodberry]

An even lighter-weight alternative: forgetting about CSS "frameworks" altogether. Aside from propping up prototypes really quickly (an exercise made trivial with these help of these little style collections) I just don't understand why anyone would want them in a real app. I've spent hours upon hours fighting the likes of Bootstrap and its copycats. And to what end?

[collyw]

OK, and where do I start? How do I make a pretty blue border around a text input to subtly indicate focus? What's the best gradient / padding to use in such circumstances? What fade in time will looks good? There are so many questions I could ask just about the text input highlighting.

As a back end developer who needs to do bits and pieces of front end stuff, I can see this taking me months (at least) to learn JavaScript CSS, and design to make something as anywhere close to bootstrap. Or I could just use what they have done (and thousands have tested) and save myself a whole lot of effort. And if you have other developers joining the team, at least they will be familiar with whatever framework you are using, rather than some in house crap that someone wrote ages ago, and has now left the company.

I have not looked at the source code for Bootstrap, but if it was crap I assume there would be a ton of articles ranting about like there are for PHP.

So (with Bootstrap at least) I am getting pre-written, tested, understood code, documented code, probably of at least "reasonable" quality, with a community online to help with problems. Does you own code have that? I certainly don't have time to write that stuff myself .

The more experienced I get as a developer, the less code I try to write. People with the "code everything yourself" attitude remind me of when I was fresh out of university, and didn't realise how incompetent I was at the time.

[egoodberry]

If you're designing sites yourself, I completely agree with you. I haven't much of an eye for design myself and always rely on foundational CSS to take care of these kinds of decisions when I build pet projects; however, I've always worked on teams that have designers who hand me high-fidelity mocks (or at least high-level style guides) that answer these questions. The implementation itself is simple enough once you've worked with CSS long enough.

[Silhouette]

OK, and where do I start? How do I make a pretty blue border around a text input to subtly indicate focus? What's the best gradient / padding to use in such circumstances? What fade in time will looks good? There are so many questions I could ask just about the text input highlighting.

The thing is, if you actually designed web UIs professionally and didn't rely on these toolkits, you could immediately make a reasonable first guess at all of those things and you'd be doing it in the context of your specific project. The total time to refine everything over the entire development cycle might be a few minutes, and most of that would be cross-browser testing, which obviously for professional work you should be doing even if you're using a toolkit.

I've nothing against toolkits. They can be useful for quick prototypes. They do a competent basic job for in-house tools written by people who aren't front-end developers and just need something that works. But for high-end UI work? I have never written a major professional project that still used any of these toolkits in the final production code.

Most toolkits aren't sufficiently reliable that you can trust them without testing, so you've still got one of the biggest and most tedious jobs to do whether you use one or not.

Often attention to detail is lacking in significant areas. Using a big name toolkit is no guarantee of quality; many of them have absolute howlers on their own demo pages that are immediately obvious in at least one major browser, often just in the visuals before you even start interacting.

But more than any of that, for real projects, you're often going to have branding requirements that will mean extensive customisation. All those default colour and typography schemes aren't worth much. And some all-things-to-all-people toolkit that works great if you use its defaults might be hiding all kinds of limitations if you're not using a flat design, or if your layout requirements are more demanding than "simple responsive grid", or if you want something that works right on mobile or supports proper keyboard navigation or meets accessibility requirements or...

Toolkits are great for basic work, and for a lot of projects that really is all you need, but you don't design a Rolls Royce by picking wheels and bodywork from a catalogue.

People with the "code everything yourself" attitude remind me of when I was fresh out of university, and didn't realise how incompetent I was at the time.

Code everything myself? Unlikely. Code things myself when quality matters and off-the-shelf isn't good enough? Always.

[cnp]

Code normalization: that's the key. Once you've got everything working everywhere via a base scaffold -- the hard part -- then you can very quickly iterate on design changes, or design in general. Bootstrap et al are generally quite easy to tweak once you understand how all of the components fit, and i'm sorry but CSS just isn't fun to have to write from scratch, especially on bigger projects.

IMO, if I were to arrive on a new project and saw the front-end devs reinventing the wheel, it would immediately set off a red flag.

[egoodberry]

"i'm sorry but CSS just isn't fun to have to write from scratch"

That may be your problem. Maybe I'm a glutton for punishment, but I especially enjoy this type of work.

[hhandoko]

It's fine when you are targeting one browser with a specific version (e.g. developing an internal web application with IE8 baseline). However, when you are building a web application targeting various browsers and versions, there will be subtle differences that may 'break' your UI.

CSS frameworks like Bootstrap provides you with a tested baseline, so you can be confident that the front-end you created will look the same across a wide range of browsers.

Certainly Bootstrap won't be suitable for all scenarios, but starting from a framework is generally a good idea.

[FreakyT]

My general take on it is: if you find yourself "fighting" the framework, then you probably shouldn't be using a framework.

Many websites have a whole lot of overlap in terms of UI patterns (a nav bar, responsive grids, etc). Is it really necessary for every dev to hand-code that nav bar, or fight with CSS's terrifyingly bad grid support? Not really, which is why these frameworks are nice.

[mau]

A framework is not only a good way to start. It's also a good way to uniform code, make things easier for new comers (larger projects usually have lots of new people that eventually write code), solve multiple common issues you'd fight by your own (e.g. browsers compatibility), community support and documentation. If you write your own you need to document well all things and things very careful how to arrange css classes to make code reusable and flexible.

[namidark]

Can you explain what you mean 'fighting'? I've heard this argument before but haven't seen any concrete examples.

[purringmeow]

Some of us like that you get cross-browser and device tested code that is super easy to use. You can choose what parts of Bootstrap to include in your app, so you don't bloat it.

Would you elaborate what you mean by fighting? Bootstrap is extremely simple to customize and I am no front-end guru.

[egoodberry]

In my experience, the fighting comes in when the designer (who generally has less understanding of the Bootstrap modules' intended roles) extends an existing UI concept that came out of the box. This is a perfectly reasonable ask on their part- it's a component on our site, why shouldn't we be able to customize it?

A specific example: Bootstrap expects dropdowns to be unordered lists with anchors as the top-level element, so having a fixed-position header as the first item while its children scroll is difficult. If this has been our CSS based on our markup, it would've taken fifteen minutes, because we could have gone in and done a bit of basic surgery on our module, making it more flexible. (This may not be the best example, but that's the general idea.)