CSS-in-JS – The Component Takeover

Since CSS first came into existence over 20 years ago most websites have evolved into complex applications that require us to constantly revise our approach. There’s been many developments in its time to allow easier scaling of projects and a more consistent approach to styling. However the rise of JavaScript frameworks over the last couple of years has thrown a new spanner in the works causing a divide in opinion.

CSS in JS has come about in response to the component-based approach of these frameworks. It refers to including our styles within our components and writing them in a JavaScript syntax allowing the developer to use native JavaScript features in their styling. There’s a common misconception that this means inline styling – while in some cases this may be true – inline styling does not allow use of pseudo classes and some of the other more useful features of CSS.

The upside of CSS-in-JS

• Automated critical CSS loading – only the styles that are actually being rendered on that page are loaded resulting in a reduced file size and a positive effect on speed and performance.
• The clash of the class names – unique class names are automatically generated, not only taking away the need to fret over naming conventions but also avoiding time wasted over typos or duplication
• No more dead CSS – despite there being many tools that claim to help find those unused bits of styling, its risky when your not sure what styles are leaking through to where. With styles completely contained within a component, if you remove the component you remove all the styles along with it. Simple.
• Dynamic styling – elements can be styled based on their state or props without the need for managing loads of separate classes
• Maintenance –  Lets be honest as great as CSS is, and yes it gets better every year, there are still some fundamental flaws with the way it works. One that affects us all is maintaining a neat codebase particularly over a long period of time and with numerous parties involved. Not only do we have to keep track of naming conventions there is no doubt that this method could save phenomenal amounts of time if implemented correctly, no more hunting through endless files trying to find every bit of styling leaking through to that component.

The downside of CSS-in-JS

• Inconsistency – One of the biggest objections to this way of working is inconsistency. So much work has gone into creating best practices and ways of working that make our UI’s as consistent and naturally flowing as possible. A lack of global styles would make this much harder to achieve.
• Raising the bar for Junior Developers – this sudden surge in the use of JavaScript frameworks has massively raised the bar for entering into the world of development as a Junior. It is one thing knowing the basics of HTML, CSS and JavaScript but to know JavaScript well enough to build a site using a framework is a huge leap in knowledge and requires a much deeper understanding.

CSS-in-JS Libraries

There are many libraries available that aim to make writing your styles straight into your JavaScript components as easy and flexible as possible. The most popular of these libraries is ‘styled-components’ (which is used by the likes of Lego and Vogue amongst many other huge household names). It is supposedly for people who ‘like’ CSS and allows developers to write styles in the same way they are used to, just inside a .js file. In second place in the popularity stakes is Emotion, they are incredibly similar and have an almost identical API as well as share pretty much all the same features. Below are examples of the syntax used in each.

The styled-components way

const Title = styled.h1`
font-size: 1.5em;
text-align: center;
color: palevioletred;
`
render(<Title>Hiya!</Title>)

The emotion way

const titleStyles = css({
fontSize: ‘1.5em’,
textAlign: ‘center’,
color: ‘palevioletred’
})

render(<h1 className={titleStyles}>Hiya!</h1>)

There’s always going to be opposition to a new way of doing things, and in this case I don’t think either side is right or wrong. CSS in JS has its place, and to me, that is in a component heavy JavaScript project in which it feels natural to work in this way. While many see CSS-in-JS as something all on its own, I view it more as one evolution of CSS that has branched off and is great in specific cases. Every project is different, and therefore will require an approach that is suited to it and your team.