Project Organization

A brief history of CSS organization strategies

We started with no organization. This is fine on small sites, but if you're coding something larger than 3 pages it gets hairy quickly.

Then OOCSS came out. OOCSS says, "make things out of small building blocks and then put them together to make bigger things - like LEGOs!"

https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/

The goal of OOCSS is never to repeat code. If you want a grid, you create the following classes:

.row {
  overflow: hidden;
}

[class*="col-"] {
  float: left;
  margin: 0 15px;
}

.col-full {
  width: 100%;
}

.col-half {
  width: 50%;
}

<div class="row">
  <div class="col-half">1</div>
  <div class="col-half">2</div>
</div>

Simple and it makes sense.

Everyone copied this basic concept to write their own CSS architecture books:

https://smacss.com
http://atomicdesign.bradfrost.com/table-of-contents/
https://www.youtube.com/watch?v=1OKZOV-iLj4
https://css-tricks.com/bem-101/ (a naming convention people have been applying to the OOCSS school of thought for years)

The downside to OOCSS is everything is coupled to everything else. Take Atomic Design for example. If you change an atom, it affects every molecule that made use of that atom. In some contexts that might be fine. In others, it might not.

To counter this coupling while continuing the OOCSS march people started wrapping up one or two CSS rules as "utility classes":

With these approaches it's not uncommon to see markup like:

<div class="Grid Grid--withGutter">
  <div class="Grid-cell u-size1of2 u-before1of4 u-after1of4"></div>
</div>

<div class="blank-u-pdAs blank-u-mgVlg blank-u-md-pdAlg">My item</div> (this markup only adjusts padding and margin)

So instead of duplicating CSS rules in CSS, they duplicate illegible CSS classes in markup.

Enter ECSS. http://ecss.io/

In a way, ECSS argues we should migrate repetition out of our markup and into our stylesheets. This doesn't violate the "DRY! DRY! DRY!!!" rule any more than OOCSS does since ultimately to style any 2 elements with the same rule, you will somehow have to repeat that rule.

It directly decouples styles from markup. If you need to remove padding from a button, you do so in the STYLEsheet instead of the markup.

It is still acceptable to have settings and a baseline (like a reset and element styles) so you're not completely giving up flexibility.

As a result, you end up with flexible code where you can remove entire blocks of CSS without ever worrying about it affecting other parts of your CSS (i.e. atom changes won't affect molecules).

Taking this one step further and applying it to all code

Deleting blocks of code is nice. It's reeeally nice. When you replace a chunk of code, you simply delete the old block of code and everything Just Works™.

As a result, some people have started re-thinking how we organize our entire projects. They argue that instead of grouping our code in a completely useless way (by file extension), we should get something out of where we place our files. This is where the concept of atoms/molecules can actually work... If we think about our entire layout in terms of areas that we call "components", we can begin grouping entire code blocks into these components.

By grouping our code by components, we can once again simply delete huge chunks of code without ever worrying about what is tied to what. Done with a calendar? Delete the entire components/calendar directory and push that commit. Need it back? git revert delete-calendar-SHA.

TL;DR

The gold standard for project architecture/maintenance should be answering yes to the question, "can I delete this without breaking stuff?"

If you can delete huge chunks of code, you never have to worry about your code devolving into spaghetti. If you have to crawl through every line of code your project has before deleting something, you'll likely put it off and the project will continue to get worse.

ECSS and component-based architecture is currently doing a good job at answering this problem. Like anything, I'm sure it can be improved upon and the author is careful to always say everything is very dependent on the project you're working on, but for now it provides a much needed & refreshing alternate viewpoint on project organization.

corysimmons/project-organization.md

Project Organization

A brief history of CSS organization strategies

Enter ECSS. http://ecss.io/

Taking this one step further and applying it to all code

TL;DR