My Thoughts on Inline Styles

React’s favoured approach to defining component markup (i.e. JSX) isn’t as controversial as it was 3 years ago when people caught their first glimpse of it. There are still many who dislike it out of (what I consider to be misplaced) principle, but most who try it tend to understand the benefits. The road to getting styles to be defined in the same manner — included directly in the component JavaScript file itself — has taken a more indirect route. I think there are two main reasons for this:

1. People are solving different problems

Making styles maintainable is still an area of much subjectivity and disagreement. It’s hard to get people to converge on a decent solution to problems, when most haven’t fully appreciated the problems that need to be solved. Christopher Chedeau’s talk “React: CSS in your JS” introduced the now famous slide listing the 7 major problems with CSS. Every problem felt like a familiar battle, but seeing them listed and explained clearly was a major turning point.

Methodologies like BEM solved most of the problems, and CSS Modules does it better by making you have to go out of your way to create the problems in the first place. So we’ve ended up in a weird situation where a talk that was effectively favouring inline styles (or some variant) to solve 7 specific problems, has led us to a place where the problems have been solved without using inline styles at all. Great!

2. Writing inline styles isn’t as nice as writing CSS.

This is conjecture and opinion, but I think most people find writing style rules in JavaScript’s object notation a much more cumbersome experience than writing CSS syntax. There’s commas and quotes everywhere, you have to abandon hyphenated declaration names in favour of camel-case ones, it’s just awful. Given that we’ve apparently solved all the big problems using CSS Modules, why subject ourselves to the unpleasant syntax of writing inline styles with JavaScript’s syntax? We’ve even managed to convince ourselves that it makes perfect sense to write our markup in our JavaScript components, but styles are… different. However, Ryan Florence uploaded an excellent short video explaining why he loves inline styles, and I found myself agreeing with his points.

Where I’m at

I’ve been using Sunil Pai’s Glamor library and been liking it a lot (it also helps that he’s incredibly motivated into making it the best experience for doing inline styles). So I have a few thoughts to add to the noise:

I don’t like the syntactic verbosity of inline styles, and especially Glamor’s basic API which is an explosion in a syntax factory (it has some alternative ways of binding with React, but I haven’t settled on one yet), but I find the benefits outweigh the extra keypresses.

It’s important to me that even if I write inline styles, they get turned into actual stylesheets by a build process. Automatic vendor prefixing is a must too.

If you don’t allow yourself to use the cascade, some types of UI require fundamentally different approaches. Components define what’s inside their box, it’s up to the parent to define the outside, this means you should avoid defining margins. An example would be a list with spacing between each item, let the parent control the spacing.

My intuition tells me that if you get to the point where you’re defining a lot of style rules (other than media query overrides and pseudo selectors) on an element, it’s a sign that your component is doing too much and you might need to look at breaking it down into smaller ones.

I don’t really like defining style objects independently of the DOM structure, it subverts the benefits of doing your styles in JS in the first place. This isn’t a hard and fast rule, but again if you find you need to do it for the sake of legibility, your component might be doing too much. I’m doing this a bit with Glamor, but i’m still only using it superficially, and not exploiting it’s full API. This is the main reason I now prefer the approaches of JSXStyle and Glamor, as opposed to Aphrodite. I still need to look into Radium properly.

There’s an inherent conflict between build-time styles and runtime styles (such as physics-based animations), they might require different solutions.

The thing that really sold me on inline styles, was getting a pull request to review and having to continuously jump between different files to be able to understand changes. I’m very much in favour of coding patterns that make it easier to read a diff. Doing a code review on something with inline styles is much easier.

The whole 7 problems with CSS thing managed to kickstart some very important reevaluation of best practices, but I let myself fall into the trap of assuming those were the only problems.

As a developer I want to be able to just write inline styles, and the build process split them up into stylesheets (for static styles) and genuine inline styles (because they’re dynamic, e.g. animations). Essentially I want to define all the behaviour of a component within the component itself, and let a build process take care of optimising the deliverable.

In conclusion?

At this point I don’t really have a conclusion, i’m mostly ruminating on the current state of play. However, I will say that after sticking with CSS Modules for over a year (after previously using BEM for a similar duration), i’ve been slowly buying into inline styles, and I think it’s the right direction. I’m hoping as more people reach the same conclusions, we’ll see a convergence on some really great APIs.