A Few Thoughts about Bootstrap


#1

Hi there peeps,

I recently read these lines somewhere, which
in many respects echo my own thoughts.

I hope that these lines don't spoil your day. :biggrin:

coothead


#2

This is my complaint about most CSS frameworks. In my opinion, a good CSS framework would not provide any HTML, only some sane CSS For elements like <nav>, <main>, <footer> etc.

I still maintain that it's far less complex to build a design without bootstrap than with it. The only advantage bootstrap offers is the ability to use other people's CSS without modification.


#3

I don't really enjoy writing CSS and using a grid framework (I'm not the biggest fan of Bootstrap, but something similar, if not slightly more lightweight) makes my life much easier.

I think CSS frameworks definitely have a place in web dev and dismissing them out of hand is a bit like cutting off your nose to spite your face.


#4

My sentiments entirely.

I've just mocked up a (quite) complex header/navigation for a site that's based on Bootstrap, the result is achieved with 1/4 of the code.


Beginner Question-Alert Box
#5

IMHO unless you want your site to behave and look exactly like Bootstrap it is not a wise decision to use it. If you're trying to save money and your needs are really basic and don't mind not having an original looking website then perhaps it makes a good case.


#6

Here's my simplified "bootstrap" which can be included to save a http_request:


/* https://booking.design/implementing-system-fonts-on-booking-com-a-lesson-learned-bdc984df627f */
body  {font: 16px/1.2 BlinkMacSystemFont, -apple-system, "Segoe UI", Roboto, Helvetica, 
         Arial, sans-serif;}
body  {background-color: #005; color: #fff; border:0; margin:2px 4px 2.0em ; padding:0 0 2em; }
dd   {margin-left: 3em;}
h1   {font-size: large;}
hr   {color: #fdf;}
#livesearch {color:#333;}

.bd1 {border: solid 1px #ddd;}
.bgc {background-color: #ccc;} .bge {background-color: #eee;}
.bgs {background-color: snow;} .bgl {background-color: lime;}
.bgy {background-color: #ff0;}
.btn {margin-left: 0.42em; border:outset 3px #eee; padding: 0.12em 0.42em;}
.BOT {left:0; bottom:0;}
.dib {display: inline-block;}
.fga {color: aqua;} .fgy {color: #ff0;} .fgs {color: #99f;} 
.fgw {color: snow;} .fgb {color:#00f;}
.fg0 {color:#000;}  .fg3 {color: #333;} .fg9 {color: #999;} 
.fix {position:fixed;}
.fll {float: left;} .flr {float:right;}
.fss {font-size: small;} .fs2 {font-size: 1.42em;} .fsn {font-size: medium;}
.fwb {font-weight: 700;}
.jbs {margin: -8px 12px 0 0; height: 2.42em;}
.hhh {display:none;}
.mga {margin: 0 auto;}
.ooo {margin: 0; padding: 0;}
.p42 {padding: 0.42em;}
.rad {border-radius: 0.42em;}
.tac {text-align: center;} .tar {text-align: right;}
.tdn {text-decoration: none;}
.w88 {width:88%; max-width: 888px;} .w99 {width:99%;}

Edit:
Just validated and noticed the following CSS error so changed the above :frowning:
.fsn {font-size: normal;}


#7

I took shared parental leave for 6 months and another web dev was hired to cover me during that time. The website was redesigned in that time and because he wasn't a front end developer Bootstrap was chosen.

the more i look at it the more i hate it. It is ugly bloated code.

<div class="col-md-4 col-sm-6 col-xs-12 fact">
<div class="col-lg-3 col-md-3 col-sm-4 col-xs-4">
<img alt="Infographic" src="/img.png" class="img-responsive"/>
</div>
<div class="col-lg-9 col-md-9 col-sm-8 col-xs-8">
<p>Some text</p>
</div>
</div>

All those classes to have a box with 2 boxes inside! Why do you need a class called class="img-responsive" on an image? Just make the images responsive if you need that using id's.

It's like going on holiday and taking absolutely every item of clothing with you and when you get to a Sunny destination having to go through and only pick the warm weather clothes. You still have to carry all your winter gear around with you 'just in case' you need it. I prefer to just pack what i need!

Its part of the reason why our site is now so much slower than when i left it, oh and also full of errors :frowning:


#8

Huh? Isn’t that logic analogous to “I’m not a carpenter so power tools were used.”

It’s surprising how many look at frameworks as being some kind of codeview level WYSIWYG that doesn’t require the user to have any knowledge of the basics the framework works with. When the reality is one needs to be good with HTML, CSS and good with bootstrap.


#9

I was mostly paraphrasing what i had been told when i returned. something along the lines of it being the quickest way of getting the site up and running etc as the developer was more of a backend developer.

it will give you a quick starting point i guess. I just don't like where it leads. I hate having to overwrite classes etc like having all of your light switches in your house turned on and the only way to turn each one off is to put a cover over each light bulb you don't want on. It's still using power but to no advantage and every now and then light creeps out where you don't expect it. Analogies galore today :slight_smile:


#10

My problem with frameworks (like bootstrap) is that a lot of people use them as a crutch rather than a tool. The people that tend to use them are the ones that shouldn't be using them in the first place because they don't understand the basics of css.

The grid approach in bootstrap is flawed in all but the latest version where flex is used and learning all the classnames is harder than learning css properly to start with. There is no secret to having 3 or 4 elements across a page - you certainly don't need a grid to do that.

However, on a number of projects with large teams I have seen the benefits of a systematised and documented approach that a framework can provide where many members may be working on the code at the same time. In these cases a framework can help but that doesn't mean you need to forget the basics and you can indeed slim down the framework to suit your needs and get rid of a lot of the extra junk that goes with it.

I think it also pertinent to note that 'slapping a class on an element' is a far more maintainable approach than long descendant selectors that tie your styles to the mark up. I have been guilty for a number of years for creating clean html with minimal classes only to find that in the long term the pages were not easily maintainable as they rely too much on a specific structure.

e.g.

.highlight{background:red}

Is far more maintable than:

header + p > span {background:red}

It's fine on a small site that you have control of but when another developer requires a span in front of your highlighted span for an icon (or other message) then the page is immediately broken. Or the client wants another paragraph in front of the one already there then again the page is broken. Clean html is important but maintainable html and css is more important.

If you work on small sites or your own site then you certainly don't need a framework at all. You don't need them on larger sites either but you will need to have a documented structure where a team is working on the code at the same time and writing and documenting a system like that could take more time than getting something off the shelf.

In the future I think the use of frameworks like bootstrap will diminish as CSS grid takes over as there is no point in creating a grid for a grid (mind you I think CSS grid itself is overkill and probably a little too complicated for its own good ).


#11

Those sentiments are perhaps, a bit sensational, but I have some thoughts on this.

Consider the differences between HTML and CSS. HTML is barely changed and provides pretty good fallback and browsers handle problems pretty well. It's really easy to learn and any basic webpage can be structured using a dozen tags maybe. It's just not hard to look at and figure out where stuff goes, it's pretty easy actually.

That said, I really don't understand this maddening drive to make HTML as pure and simple as possible. E gads a container element! An extra span!
These things don't make HTML any harder to reason about, and if they are classed properly, they make it easy to change things too.

Now consider CSS. This is incredibly complex and getting worse by the day. Consider the overriding nature of the cascade, deep level selectors, child, descender, sibling, etc. Consider that it not only styles things, but can animate and transform them too. There is even 3-dimensional abilities! Then you add media queries (more cascade issues), state selectors (hover, active), pseudo elements (before, after), pseudo classes (last-child, nth-of-type, etc). Even functions like calc().
There is a glorious amount of complexity and a huge number of problems that come from too much CSS, too complicated CSS, unmanged CSS etc. Who hasn't fought for hours trying to figure out why some styles don't work, or a selector is off, or positioning went bad, or cascade has problems, specificity preventing new styles, throwing out !important in frustration, one simple change entirely breaks a different part of the site.

And yet with all the complexities of CSS, people still cry and whine about simple stupid easy-to-read HTML being a little more ugly!!

Do people not realize how incredible easy it is to work with styles by just having a bunch of direct classes that do what is needed, then spending all our time trying to write minimalistic HTML linked to incredible hard and hard to read and hard to reason about CSS? Nobody is impressed any more that you can write #mypage .coolthing .someblock:hover > .top p:first-child:not(.special) span.
That right there will give you nightmares. But hey, at least you didn't have to put an "extra" class on the span and just style it directly! Super clean HTML yo!

And this whole idea of not putting how things "look" in the name of a CSS class. Well yes and no on that one. CSS is for deciding how things look, aaaaaaand CSS classes are for linking to those "looks". So why is the class .thebigone a bad thing? Cause it "describes" that something is a big one? This is bad for some reason?
Are we in the business of making sure our classnames purposefully DON'T tell us what they might do, or the effect they might have? Because......HTML or something?

On the other hand, I completely disagree using a class like .red and writing CSS .red { color: red; }. This is obviously bad because if the client some day wants red to be orange, you have to change all the HTML references as well as the CSS. Or worse, don't change HTML and now you are stuck with .red { color: orange; }! At least use a classname more like "brandcolor" or "brandalt" or something.

Here is what I'd say. Don't spend too much time worrying about your HTML being slightly thick with extra containers, it is literally zero effort to still find where the content goes. It doesn't take someone long to search for the p tag or an h2. But if you trade complexity in HTML for complexity in CSS, you are asking for a world of pain!
It's like, hey look, I only have one single div surrounding all my content yeah! Ok but that one div now containers a crap ton of styling and is very rigid. If your container has margin on the sides, what if you want a background color behind the margins? If you've built a long complicated selector, what if you want to insert a new element that breaks the chain? What if you want to reuse styles but can't because that one class is clogged with too many specific styles? You have to start duplicating styles and creating wet CSS (as opposed to DRY).

Rather the way to look at it is, create reusable styles on containers and don't over populate the container with too much styling.
I typically have a wrapper div, it goes edge to edge, top to bottom, no padding, no margin. This is a good place for full size background images or colors etc. Another inner container may have some margin or padding on the top and bottom to separate from other containers, but none on the left and right. Then another container inside that which might set the alignment and max width of the block depending on what content is needed in it. Then another one in there to set up inner content backgrounds or borders. And another for inner content paddings or grid. And another for grid blocks or floats. And another to wrap the actual content elements, etc etc. And each block has a class, and each class has just a few basic layout properties.

OMG, such complex! many unreadable!

Actually, what it does is create a whole bunch of layout options that can be reused. Do I need a full width container or a limited width one? A container with a background or one with extra padding? Do I need a grid?
This is all very easy by going more complex in HTML (still baby easy to read), and super less complex in CSS, a handful of single classes, no specificity issues, no cascade, no complex selector patterns.

And then somewhere within those containers I'll slap an additional class to define that specific block, perhaps an ID which can later be used for in page linking for example. Or a unique class to provide additional options on those various layout boxes (such as what the background image or color actually is).

I'm all in favor of having a bunch of classes and structure in HTML, with super easy CSS behind it. This doesn't mean I like Bootstrap. I'm actually more of a Foundation guy. But those grid systems especially are very handy. Foundation's XY grid is flex based using modern stuff, you can even change the order of blocks (finally) on various screens. It makes much fewer decisions about how things look than Bootstrap does. It has some base styles for typography and forms but otherwise you have to do most of the styling. Foundation classes are for grids and utilities and such.

My advice; stop worrying about complex HTML, which literally nobody has trouble dealing with. And instead worry about clean and simple CSS, single level classes, simple selectors, reduce cascade and specificity fights. Module based class naming. Use SASS if possible. Organize files.

I work on complicated sites all the time. A complicated HTML template might grow to 200 or 300 lines of code, but the complicated CSS that goes with it can be over 10,000 lines of code. No joke.
Let's stop worrying about HTML and separation of concerns in class naming, and focus on better CSS and modularity!
Heck this very forum page has about 460 lines of HTML, snore. But the CSS expands to about 14,600 lines. Is it more important that HTML is as simple as possible? Or that CSS is as simple as possible? The CSS for this page was so big my browser dev tools couldn't even open it.

Worry about your CSS my friends. We don't live in an age of sites built with HTML, we live in an age where sites are built with CSS. There are no more browny points for getting the leanest, most class-free, container-free HTML any more. IMO


#12

Well, you answered that question yourself. :rolleyes:

coothead


#13

All for analogies I think frameworks have blurred professional boundaries in the same way the digital camera did to photography. It no longer requires much thought to take a shot because it no longer requires so much money, hassle and time to get the pics developed. Therefore there are a lot more 'professional' photographers out there and it may be actually a little harder to spot a genuine one


#14

The only thing I have against complex HTML is that it may end up adding up to being too much text for the server to output making the page slow. I have seen this happen plenty of times. Parsing and rendering HTML is a very expensive operation when there is lots of it and it is VERY easy to end up with an application with lots of cumbersome HTML, pick any CMS...


#15

I don't think so.

If I have classes like ".largebtn" and ".smallbtn", it's far less likely that suddenly they will want to conver largebtn into "tinybtn".

On the other hand, if a class like ".red" is used throughout the site, it's extremely likely someone might want to adjust the brand color at some point.

So I disagree. It's fine to have "bigone", but not "red". Because red is very specific color. Any "shade" of red might work, but if they change to blue, that hurts. But "bigone" has lots of variation possibilities. What if they want it slightly bigger, 4 more pixels? Well it's still a bigone. Or even smaller by a few pixels, it's still bigger than the normal one, or the small or tiny ones.

Also consider, how many possible buttons sizes might a site need? 4? 8? Tiny, small, regular, medium, large, xlarge? But how many colors are in the spectrum?

To each their own, of course. There are no solid rules. I'm just saying I'm fine with "bigone", but not "red", as a class. They are quite different to me.


#16

I don't know about this. There is output compression and stuff like that. Plus, again, HTML typically is not that huge, unless there are hundreds of repeating content blocks or something. An average page of an average content site is just never going to be all that huge unless it's generated garbage from a bad CMS.
Half the time it seems there is more meta data in the header and footer and style blocks and script references than there is actual html!

In any case, I reject the category of suggesting that HTML becomes "complex" simply because either a) there appears to be more containers than absolutely necessary; or b) some elements have many classes.

To me, that isn't complexity.

Some might say it's complex to have every file on your computer contained in one folder. And some might say it's very complicated to spread your files out all over thousands of folders to "organize" them.
I might say it's less complex to "organize" HTML content within a series of "folders" (containers), each having a unique and reusable purpose. Rather than dumping all page output in a couple folders with a ton of CSS applied.

One way to think about organizing HTML and CSS is to consider never making a content object directly effect its parent block/container. This thinking is part of BEM, as an example.
If you have some block but you want there to be more space after the last paragraph, you would not thrown extra margin on the bottom of the last paragraph. Because in that case you are using the content element to define the parent. Rather what you should do is define the bottom padding you want, on the actual container.

Or another example I often see is with a logo. Typically a logo graphic doesn't have any extra space around it (in the jpg/svg/png itself). So people often throw on a top and bottom margin to "push" space around it into the parent block. This is not good practice. The parent block should define what spacing it wants, it shouldn't be the job of the content/image to define the parent block. This way you can place the image anywhere on your site as needed without that extra margin. It's more reusable that way.
Your reusable components should not make assumptions about the surrounding environment of where it is placed. Your containers should make the choices about paddings and spacings and margins and borders and widths and heights and positioning and all that.
To follow this principle though, you might have a couple extra containers helping place the inner content exact where needed. A couple extra classes defining the dimensions where the content will go. It's a small but beneficial tradeoff.

Anyway. My ultimate point is, rarely is HTML the problem. It always seems to be CSS I'm fighting with. And this is either because somebody had to get real clever with long complicated selectors and selector logic to avoid extra classes and containers, or too much CSS was applied to classes that are reused through the site. This leads to creating dozens over override conditions, complicated cascade and specificity issues, and !important declarations everywhere. All because they didn't want a few more containers or some extra and reusable classes used.


#17

The author seems to have a problem with object-oriented CSS in general here, not with any framework in particular. Whether or not this is a good approach is of course a matter of debate (and it largely depends on the project), but it has some undeniable advantages:

  • The code is much more maintainable; most notably, it's easier to apply changes and fixes globally -- you generally just need to adjust a single class (or variable)
  • It reduces code duplication in the CSS, leading actually to smaller file sizes
  • It keeps the specificity small
  • You can just look up elements and components in a library/style guide and knock out some custom content without a developer having to write a single line of extra CSS

However, if you're not happy with this approach you can still accumulate styles by @extending bootstrap classes or using the @mixins it provides in your SCSS:

main {
  @include make-row();

  > section {
    @include make-xs-column(12);
    @include make-md-column(6);
  }
}

The opposite is the case: each class has a very specific purpose, which keeps duplication in the CSS to a minimum. I don't see where this would cause any class redundancy... the trade-off are of course more verbose class lists.

Well in most cases you can use any element for wrapping that deems you appropriate, but a div certainly lends itself well for that (especially in the documentation) since it has no further semantic implications. As the HTML 5.1 standard says:

The div element has no special meaning at all. It represents its children.

And that this results in "two to three times the HTML as one would have without it" seems a bit exaggerated to me, let alone "as much CSS as one would have without the framework". This is simply not true unless you want to completely override everything bootstrap provides.

It actually gives you pretty fine grained control over what to include and how you want it to look (well OK it will still look like old bootstrap). ^^ The bootstrap 4 beta doesn't seem to have this option yet, but you can of course only @import the SCSS parts you need. Anyway the point is, when you start writing extensive CSS to overwrite the defaults, you may have overlooked that you can simply adjust these at any time.

That all being said, I'm not a huge fan of bootstrap per se either; but IMHO a framework-style approach like this is generally a good idea when you have a somewhat larger project. Otherwise you'll sooner or later end up with piles of legacy code that nobody dares touching as you don't know where it might still be in use, and in turn heavily nested selectors to override the specificity that is way to high already.


#18

Nobody is saying to completely dismiss CSS Frameworks. People are looking for better frameworks. Better means lighter frameworks. Skeleton and Jquery UI is my personal choice.


#19

I am. :rofl:

coothead


#20

I never use native bootstrap classes in my HTML. I use my own, app-specific, semantic classes. Then, in my LESS, I make the association between my classes and whatever framework (eg Bootstrap) classes I want. It does take some effort, but that effort is mostly shifted to the implementation - the semantic-to-bootstrap LESS stuff.

Overall, am very happy with that approach, keeps my HTML clean. I value this.

Yes, still left with some leakage - nesting of elements to make stuff work - but not much.