The buzz is happening and people are really seriously talking about getting rid of CSS in their web applications. I’m not going lie – I thought the notion was ridiculous when I saw the first headlines. In fact, I initially assumed that it was just another trendy discussion from people who like theorize but not build real world software. But, then some well versed people started to get on the band wagon, and I read some great articles.

Among one of my favorite articles on this topic that you should read before continuing on this one is:

https://css-tricks.com/the-debate-around-do-we-even-need-css-anymore/ – This is a clear explanation on the debate at hand from both sides of the argument, and very well written. Thanks for this Chris!

What Really is the Core Problem?

I have to say that in more recent applications I have been putting together I can highly identify with some of the issues we face with CSS that really no one want’s to admit. Mainly the fact that everything is Global is a large concern for me. We have fought many battles attempting to ensure proper namespacing and standardization inside our CSS / LESS files. To be honest, I still get scared of the changes. You never know when a particular convention was not followed, and perhaps are using the same style in another component that is not locked down to your convention. And of course, this means no one will ever delete anything….it just grows… for its entire life.

I think anyone working on a substantially large project can identify with these core issues at some level, and it is clear to me that how to solve these problems are at the heart of the suggestion to get rid of CSS! Getting rid of CSS is simply the suggestion in solving this core problem. It is important to get at the root of the issues in order to identify a possible solution.

That being said, WE STILL MUST STYLE OUR APPLICATIONS WITH CSS – there is no way around that. In my introduction to this debate, I was initially left with the impression that the suggestion was to literally get rid of it… which just is not the case. The article above attempts to explain this thought a bit better as well, and discusses inline styles vs cascading style sheets.

The Happy Medium

Inline style usage is then the direction given on how to solve these issues with CSS. That is not to say that everything will be styled inline right in your HTML Template / View. If your using a JavaScript framework such as React, or Angular, these options often end in some type of component creation that easily allow you to build re-useable instances of elements and thus prevent you physically copying inline styles amongst elements. In fact, looking at Angular and how templates are built with JavaScript right into the template (which is a complete 180 degree reversal to the mind sight 2 years before its time), it is a natural progression to begin adding our styles here as well. In a lot of ways, that would offer so much more transparency in reading that code. You would immediately understand the involved JavaScript logic and CSS next to a component. And of course, you could make a change to the elements styles knowing the exact component you will be changing, and you’d be unafraid to delete unnecessary inline styles.

Although, I can’t help but think how ridiculous it would be to store all my chrome, headers, footers from the standard site design into inline styles. There must be a happy medium here? I hope….

So far the best solution that I prefer in practice is a combination of the solutions above:

• Keep CSS Around for Truly Global Styles: First the question is what is “Truly Global Styles”?. I’m talking two main things. The first being your base level styles for your site chrome, main headers and main footers, at its most basic form. If you change these styles you’ll likely be intending to change the styles of the entire site. Other styles such as global defaults including typography should get set here. Secondly, and as part of a completely different topic I think it is very important to architect your CSS like you do your code. It must be designed and well thought out and everything is re-useable. This is your core framework for building on top of. When building your CSS Framework remember your not just scripting through named elements on your page, but rather building classes that can be combined to form the basis of most things you need going forward (building blocks). While the debate is also quite large on whether using something like Twitter Bootstrap is a good idea / bad idea – ultimately you want to build something like this for your own application, and when you find yourself putting together a new page you have all the building blocks in place for that page already from a style perspective. Its then a matter of slightly customizing those styles…

• Use Inline Styles for Customization & Components: I’m referring to two levels of inline styles here as well. The first is that inline styles should be used in conjunction to page level templates to add small customization’s and alterations to your base CSS framework as needed. Secondly, when designing re-useable components or directives I see no reason not to use inline styles in these templates as well (on top of the base CSS framework class you may be using as well).

I’ve found that following these two guidelines keep my templates readable without large amounts of inline CSS, easily allow global alterations to truly global elements when I want, and creating / using a CSS Framework make myself highly efficient in designing new page templates as needed.

All of this being said, I’m just a guy trying to build well-architected applications. Generally the concrete implementations of “well-architected” changes every day as I learn more. What are your thoughts on CSS in this debate?