Five comparisons between Twitter Bootstrap and Semantic UI

There are plenty of CSS and layout frameworks on the market. I've had the privilege of using two of them - Twitter Bootstrap and Semantic UI. Both frameworks are used to provide responsive layouts and improve the UI. While they're similar in very basic ways, they are different enough to warrant a comparison.

Here are 5 ways they compare...

1. Features

Both Twitter Bootstrap and Semantic UI use a grid layout for responsiveness. Twitter Bootstrap uses as 12-column grid while Semantic UI uses a default of 16 columns (which can be changed). Some say this increased granularity gives Semantic UI the edge, but from my perspective I'm not sure it makes that much of a difference.

They both have features like button groups, accordions and beautified form inputs. This is where Semantic UI arguably has the advantage, as it boasts many more variations on those features than Twitter Bootstrap. Semantic UI's icon set, for example, has about 617 in 25 categories to Twitter Bootstrap's 264... the free ones anyway.

Twitter Bootstrap's icon set (left)
Semantic UI's icon set (right)

Both Twitter Bootstrap and Semantic UI offer features that the other do not. For example, Twitter Bootstrap has a Jumbotron feature, and Semantic UI has a really nifty-looking rotating cube feature. But even on quantity alone, Semantic UI has the obvious edge.

2. Marketability

Twitter Bootstrap is almost a household name among developers. Most devs have used it since 2011, at one time or other, to do up websites. Semantic UI, on the other hand, is the relative new kid on the block, having been here since only 2015, and at this time does not even have a Wikipedia entry.

The obvious inference here, of course, is that Twitter Bootstrap has way more support and documentation.

I know Bootstrap!

But the real edge is that almost everyone has heard of Twitter Bootstrap, whereas fewer have heard of Semantic UI. So putting Twitter Bootstrap on your resume is more likely to get you jobs. Even during interviews, I've had interviewers nod sagely when I mentioned Twitter Bootstrap, and give me blank looks when I mentioned Semantic UI.

If you mention Twitter Bootstrap, most people will immediately assume you understand Responsive Design. Which isn't strictly true, but perception is what it is.

3. Look-and-feel

Twitter Bootstrap isn't considered generic without good reason. Most people use the free default theme, which results in Every Fucking Bootstrap Website Ever. Which can be a shame because Twitter Bootstrap can look really good, if you're willing to pay for different themes. Even if not, contributors have offered their own Twitter Bootstrap themes, which can add some variety.

Semantic UI's default and optional themes, all free of charge, already promise a dizzying array of effects that won't immediately scream SEMANTIC to people who view them. Of course, the fact that Semantic UI isn't famous like Twitter Bootstrap, probably helps.

Twitter Bootstrap's color scheme (top)
Semantic UI's color scheme (bottom)

If you want hard numbers though, just consider color schemes. Twitter Bootstraps default theme comes with 6 colors. Semantic UI has 12 (in both cases, we're not counting black). And this can be a simple but huge factor in flexibility of design.

Also, Twitter Bootstrap has 4 size categories - lg (large), md (medium), sm (small) and xs (extra small). Semantic UI has 8 of them - massive, huge, big, large, medium, small, tiny and mini. Though it's worth noting that Semantic UI's size categories aren't rendered with perfect consistency throughout their elements.

4. Difficulty level

Twitter Bootstrap is easier for someone with totally no jQuery knowledge, to use effectively. For Semantic UI, it's a lot harder because jQuery is used often, either as an initializer or to manipulate the controls. Even though many features have a non-jQuery version, this results in a drastically less rich user interface.

If you're only using Twitter Bootstrap or Semantic UI for responsiveness, then this doesn't matter.

Semantic UI's code sample

Personally, I like Semantic UI's style. The jQuery animation features in its feature set allows me to do a lot of cool things without actually writing my own.

Although if you want to really customize stuff, it might be easier in Twitter Bootstrap. Semantic UI offers a lot of customization options, but it can't cover everything and sometimes trying to shoehorn their existing options into what you want exactly, is a pain in the ass.

5. Class names

Twitter Bootstrap uses class names that don't read like normal English.

<div class="row">
    <div class="col-xs-12 col-sm-6 col-md-8">Column 1</div>
    <div class="col-xs-6 col-md-4">Column 2</div>
</div>

Semantic UI's class names look like this.

<div class="row">
    <div class="twelve wide computer six wide phone eight wide tablet column">Column 1</div>
    <div class="six wide computer four wide tablet column">Column 2</div>
</div>

Some say this makes Semantic UI friendlier to use. I'm ambivalent here. See, I have this habit of writing my own CSS classes. And it's far harder to clash with CSS class names like btn-lg than with names like segment or basic.

Conclusion

Personally, I'd take Semantic UI any day of the week. It's got features I need, and I don't have a problem with using jQuery. But Twitter Bootstrap might be better for people who want decent results with a minimum of fuss, and more if they're willing to cough up the cash. And in any given professional environment, the chances of Twitter Bootstrap being already in use are astronomically higher.

Pick up a CSS framework today. It's a xs effort for massive gains.
T___T

To the Strong and the Bold

With the introduction of HTML5, there has been a fair bit of confusion regarding the tags <strong> and <em>. Many developers have regarded these tags as replacements for <b> and <i> respectively. Even HTML Editors such as CKEditor and Adobe Dreamweaver have introduced these as defaults. Click on the  button in either of these applications and you're likely to get a <strong> instead of a <b>. Likewise, click on the button and you'll get <em> instead of <i>.

What people don't realize is that, unlike certain tags like <font> and <center>, <b> and <i> have not been deprecated. That's right, they are part of the HTML5 specification.

HTML5 Specs for the STRONG tag: http://www.w3.org/TR/html5/text-level-semantics.html#the-strong-element
HTML5 Specs for the EM tag http://www.w3.org/TR/html5/text-level-semantics.html#the-em-element

What exactly are these tags for?

We'll start with the difference between <strong> and <b>. Once you understand this, <em> and <li> should follow quite easily.

On the surface, to the human eye, there is no difference. <strong> and <b> both turn text bold, as shown below.

This text is <b>bold</b>
<br />
This text is <strong>strong</strong>.

This text is bold.
This text is strong.

The difference is that <b> is purely cosmetic, while <strong> has semantic significance. You use <strong> when you want to put some extra weight on a word, to increase its importance. You use <b> when you only want to make text bold.

With semantic significance, you can change the entire meaning of a sentence.

He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.

Contrast this to the code below. The headers are rendered with the <b> tag, not because they have any special significance, but because it would look nicer to have them in bold.

<table>
   <tr>
                <td><b>Header A</b></td>
                <td><b>Header B</b></td>
                <td><b>Header C</b></td>
                <td><b>Header D</b></td>
   </tr>
   <tr>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
   </tr>
   <tr>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
   </tr>
</table>

Result:

Header A	Header B	Header C	Header D
Data	Data	Data	Data
Data	Data	Data	Data

Of course, one could argue that we could just solve this thing with CSS (and you'd be quite right), but CSS is not the subject matter here. Just to be pedantic, the CSS descriptor font-weight:bold is also purely cosmetic.

Yes, to the human eye, this still makes no difference. <strong> and <b> will still appear as bolded text. It will, however, make a great deal of difference to a machine. The builders of the HTML5 specification probably intended for semantic markup to play a part in SEO (Search Engine Optimization). Thus, the separate tags even though they both look the same to you. Because if everything in bold was important, that would lead to a lot of cranky search results!

New fun stuff!

Apparently, you can also nest <strong> tags.

<strong>He never said he stole <strong>her</strong> jewels.</strong>

To the human eye, this does nothing more than bold the entire block of text. When a machine reads this, however, it's supposed to place importance on the sentence, and even greater importance on the word "her" within that sentence.

What about <em> and <i>?

So now, apply everything I just said about <strong> and <b>, and apply it to <em> and <i>.

What does this mean for future development?

Well, at this point in time, until everyone gets used to the idea and starts applying this standard, you could probably get away with using the tags interchangeably. But looking to the future, you're advised to adapt. Heaven knows when HTML5 syntax will finally stop fluctuating though, so take your time.

Until then, fortune favours the <b>, so go get <em>!
T___T