CSS in JS - Traditionalist sentiments put to the test

CSS in JS is very much a 'thing' nowadays when it comes to building applications on the web. I decided to test my 'traditionalist' sentiments with CSS and take on an experiment. I went in with an open mind to truly answer the question... is CSS-in-JS it really better than traditional CSS?

I was pretty convinced I knew what was going to be the outcome. I have always had an eye on CSS in JS however never really got around to fully form an opinion on it. Being a ‘traditionalist’ I am very beholden to CSS standing on its own and Javascript having its own space and styling components wasn’t one of them.

As a bit of background, early on in my career, I was in your classic ‘web agency’ operation. Building websites for businesses. Javascript at that time was effectively JQuery, and anything stylistic with Javascript was a right pain. So, let's just say those years were formative in me taking an anti-stylistic approach to Javascript.

I since moved to the product space building large scale applications with a tonne of logic and scaling complexity and really embedded myself in the 'React' world, but still leant on CSS as a styling mechanism.

 on a production product and was intrigued by its function. I saw first hand its potential. The idea of housing stylistic variations of the same component in the same file seemed 

import * as React from "react";
import styled from "styled-components";

const StyledButton = styled.button`
    padding: 3px 10px;
`;

export const Button = () => (
    <StyledButton>
        Button Text
    </StyledButton>
);

This made a lot of sense as it kept everything in a nice package. From my experience in large scale application, things in 'nice packages' and components that 'made sense' is an exciting space to exist. With this, everything I needed to know about the button logically and stylistically was housed in the one file.

My conclusion at this time was “It can work for things like components, but if you were to introduce layout styles like 

, it will become overwhelming. So my position was, “anything structural should be CSS, anything logical can be a 

To put this to the test, I decided on a rather simple experiment. Compose 3 identical UI’s which each have a toggle navigation menu, a banner image and 3 columns. A fairly ‘boilerplate’ agency layout.

 using purely CSS (Sass), One the _'new way'_using purely JS (

) and a 3rd to put my position suggestion “logical components in styled-components, and layout in CSS” to the test.

https://github.com/lindsayjopson/css-vs-js/tree/master/css

The general structure of the folders suggests, in the 

 folder house global and shared styles and variables. Things like $black, $white, $base-spacing etc.


// contentBlock/index.js

import * as React from "react";

export const ContentBlock = () => (
    <div className="content_block">
        <h3>Content Heading</h3>
        <p>
            Content
        </p>
    </div>
);

// _contentBlock.scss

.content_block {
    display: flex;
    flex-direction: column;
    flex-basis: 100%;
    flex: 1;
    padding: 20px;
}

The separation of concerns here is pretty clear. The 

 file takes care of the React rendering, and the 

 takes care of the layout. In practice, I have enjoyed this separation. It's the classic “put a classname here, place the CSS for that classname there”. 

From an onboarding and understanding perspective on ‘how things fit’ is pretty clean and clear.

https://github.com/lindsayjopson/css-vs-js/tree/master/js

The folder structure is exactly that of above, for this exercise I really wanted to make them as close as possible without letting ‘folder structure’ get in the way of the final thought. For this, I effectively merged the 

import * as React from "react";
import styled from "styled-components";

const ContentWrap = styled.div`
    display: flex;
    flex-direction: column;
    flex-basis: 100%;
    flex: 1;
    padding: 20px;
`;

export const ContentBlock = () => (
    <ContentWrap>
        <h3>Content Heading</h3>
        <p>
            Content Text
        </p>
    </ContentWrap>
);

To me, this makes total sense, you are combining everything regarding a 

 in one place. Its small, its tidy and its logical.
However, 

For this, we need to understand a couple of concepts.

 file which housed all the Sass variables.

//colors
$white: #ffffff;
$black: #000000;

//font
$base-font-family: "Source Sans Pro", sans-serif;

//colors
export const white = "#ffffff";
export const black = "#000000";

//font
export const baseFontFamily = "'Source Sans Pro', sans-serif";

These can then be imported into files much like any other variable.


import { white, black, baseFontFamily } from "./globalVariables";

 file. This houses all the classic ‘base’ styling for an app.

body {
	font-family: $base-font-family;
    font-size: $base-font-size;
}

 file which automatically makes those set.

 function which you pass in the same content as above without the Sass Variables`.

import { createGlobalStyle } from "styled-components";

import {
	baseFontFamily,
	baseFontSize,
} from "./globalVariables";

export const GlobalStyle = createGlobalStyle`
	body {
		font-family: ${baseFontFamily};
		font-size: ${baseFontSize};
	}
`;

So the stuff we have been playing with up until now have been rather simplistic, not a log of ’style’ is involved and mainly sitting around layout function. For this exact reason, I added a toggle-able navigation. As far as ’style’ goes I would say this is still on the ‘basic’ style, but it was a good indicator of adding complexity to the system.

import React, { useState } from "react";

export const NavMenu = () => {
let [isHidden, setState] = useState(false);

    return (
        <div className={`nav_wrap ${isHidden ? "hidden" : "visible"}`}>
        <div className="nav_toggle"
            onClick={() => setState(isHidden === true ? (isHidden = null) : (isHidden = true))}
        >
            <div className="hamburger">
                <div className="line"></div>
                <div className="line"></div>
                <div className="line"></div>
            </div>
        </div>
        <ul className="nav_menu”>
            <li className="nav_menu--item”>
                <a href="#">Menu Item</a>
            </li>
            <li className="nav_menu--item">
                <a href="#">Menu Item</a>
            </li>
            <li className="nav_menu--item">
                <a href="#">Menu Item</a>
            </li>
        </ul>
    </div>);
};

The functionality to note above is as follows. When 

.
By doing this, an additional className will be toggled on the 

. In CSS we have the following to support this stylistic change.

.nav_wrap {
	&.hidden {
		left: -350px;
	}
}

.hamburger {
background-color: \$grey-light;

    .hidden & {
        background-color: $white;
    }

    .line {
        position: relative;
        border-top: 2px solid #000000;
        top: 5px;

        &:nth-child(2) {
            top: 11px;

        }

        &:nth-child(3) {
            top: 17px;

        }
    }

    &:hover {
        cursor: pointer;
    }

}

.visible {
	.hamburger {
		&:hover {
			.line {
				top: 14px;
				transform: rotate(45deg);
				transition: 0.3s;
                &:nth-child(2) {
                    display: none;
                }

                &:nth-child(3) {
                    top: 12px;
                    transform: rotate(-45deg);
                }
            }
        }
    }

}

While I have removed some of the general styling of this component from the above example, I would like to draw attention to the complexity added to the CSS for this interaction.

There are hover effect which impacts nested elements 

 interactions when the navigation is set to 

. While in the CSS only version, this doesn’t feel too far outside the norm. Whereas if we are to then bring this into JS Only we are faced with the following.

Now we can start to see some scalability concerns with this method. Without appropriate abstraction, components that exhibit high interactivity from a stylistic perspective, matched with a component with a high stylistic complexity; this could easily become extremely cumbersome.

So the question becomes, where is the line? At what point do we decide what should go where, and does the idea of logic remain in component and layout remain in css still ring true to which was originally hypothesised?

https://github.com/lindsayjopson/css-vs-js/tree/master/merged

“All fixed static styles (those that will not change on events) are housed in CSS, and those that react to events are handled in JS”.

//\_navmenu.scss

.nav_toggle {
	position: absolute;
	width: 45px;
	height: 45px;
	right: -45px;
}

.nav_menu {
	list-style-type: none;
	padding: 0;
	margin: 45px 0;
	overflow: hidden;
	background: \$grey-light;
}

.nav_menu--item {
	display: block;
	width: 100%;
	font-size: 18px;
	padding: 8px 20px;
	&:hover {
		background-color: \$grey;
	}
}

Here the driver was to allow context to styles. To understand ‘how the styles change’ based on different events, and use that as a measure on how we separate concerns.

Going through this exercise this felt like a really nice balance and when explaining why this makes sense to other engineers felt quite sensible. Making changes to the state takes place through Javascript, so if some stylistic changes also take place depending on the state of a component, why not also do that in Javascript.

There was one hurdle that this has created. When adopting one style over another the global variables were super easy to maintain. In CSS I had one 

 file which stored all the colours and widths etc I needed, in JS I had a globalVariables.js file which stored all my colours and width. However, with a merged version I needed to maintain two versions of the 

. To me, this is a necessary factor for me to convert to this method of developing.

This exercise has done its job for me on my personal journey to explore a hypothesis I had. While the result has completely changed from the original result I thought I would get (CSS is still king) and that’s perfect!

The conclusion has proven that the usage of CSS, CSS-In-JS all depends on what you are doing. I would say if you are going for a static site or application, go with CSS. If you are going for an application with a bit of dynamic rendering, go CSS-in-JS it's great! If you want to try a bit of both, go with a merged approach. Just be sure on where you draw the line of ‘what’s CSS and what’s js’. My approach was to keep all the styles that change based on JS in the 

 file, all static styles in an accompanied 

The main issue we get with anything when it comes to styling anything is the pace in which it turns to chaos when it scales.
All of these approaches can turn into a mess if they are not kept to their intended separations of concerns. Be clear on your ’best practice’ for the application. Write it down, make it clear.

Below is a small list of Pro’s and Con’s formulated throughout this work. I hope you enjoyed the article and will explore the potential to. Bring JS, CSS or both into your next project.

AUTHOR

Lindsay Jopson

CSS in JS is very much a 'thing' nowadays when it comes to building applications on the web. I decided to test my 'traditionalist' sentiments with CSS and take on an experiment. I went in with an open mind to truly answer the question... is CSS-in-JS it really better than traditional CSS? I was…

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Free Tools

CSS in JS - Traditionalist sentiments put to the test

Tags

Responses (0)

Free AI Career Tools

AI Job Listings

ATS Resume Checker

Startup Perks

Masterclasses

Tutorials

Fullstack React with TypeScript