Update: I’ve announced react-pacomo, a solution for some of the problems with CSS outlined here, without the downsides of Inline Style.

So one of the hottest topics in the React world lately is Inline Style, i.e. setting styles with an element’s style property instead of CSS.

This new and shiny way of doing things promises to make your life easier. It eliminates the bugs caused by global styles, it allows you to package styles with your components, and it unifies the entire development process under the single language of JavaScript, fuck yeah. And now that all the cool kids are using it, it’s time to jump on the bandwagon too!

But don’t just take my word for it! See for yourself with this handy dandy list of all the problems which you could have fixed with plain old CSS if you hadn’t of drunk the cool-aid, and the new problems you’ll now have to deal with too.

Problems which Inline Style didn’t have to solve

Everything in CSS is a global

Let’s get this one out of the way first, because it is always the first thing that comes up in any list of reasons not to use CSS.

Yes, everything in CSS is a global:

.active { background: red; } /* ... lines and lines of unrelated code ... */ .active { /* oops */ background: blue; }

So namespace your classes and deal with it:

.app-NavItem-active { background: red; } /* ... lines and lines of unrelated code ... */ .app-ContactForm-active { background: blue; }

While this may look long-winded, if you’re using SCSS or LESS then the parent selector with a dash ( &- ) will make wonder what you were ever worried about:

.app-ContactForm { &-active { background: blue; } &-saving, &-fetching { /* style goes here */ } }

And on the React side, there are tools to generate these scoped class names for you. Or if you’re stuck outside the kingdom of React, CSS modules will accomplish basically the same thing.

But then again, sometimes you want global styles, like this:

@import url('http://fonts.googleapis.com/css?family=Roboto:300,400');

Or this:

html, body { position: relative; height: 100%; min-height: 100%; font-family: Roboto; }

And good luck implementing these with Inline Style.

Cascading gets in the way

There are a number of meanings of “cascading”, so let’s pick one: styles sometimes inherit their value from parent styles. For example, defining font-family: "Comic Sans MS" on body will cause most everything on your page to be cheerful and happy. Some people don’t like this, because it means that your component may end up with style which you didn’t specifically give to it. But style will still cascade, even when defined with Inline Style.

So why is Inline Style a benefit? Well, Inline Style let’s you write JavaScript helper functions to ensure that your components overwrite any inherited styles with their own styles. But seriously, let’s think about this for a moment: all you’ve really done is re-implemented cascading through JavaScript helper functions. Though at least it’s written with JavaScript now, amiright?

So let’s move onto the next meaning of cascading: if you create a selector for ul li , then your styles will be applied to ul li ul li and ul li ul li ul li too. Selectors aren’t very specific.

Easy fix: don’t use HTML elements in selectors. Instead, give your elements namespaced CSS classes which double as a way of documenting what they actually do. Your code will be clearer and more precise as a result.

Inline Style can be included directly from your component modules

This is actually a huge benefit. Nobody likes maintaining entirely separate project trees just for their CSS, or managing CSS files which live in completely separate locations to their corresponding JSX.

But now that we all have access to wonderful tools like Webpack, this benefit isn’t limited to Inline Style anymore. In fact, I place my LESS files right next to my JSX (or JS with Angular), and then include them like this:

import './DocumentForm.less'

But James – you tell me – those LESS files still depend on other LESS files which are separate to your components. And it isn’t like you can use JavaScript-loaded styles in production!

Half true. The LESS files do depend on other LESS files – but only ones included like this:

@import (reference) '~cloth-util-less/index.less';

That little (reference) ensures that no output is generated by the @import ; it is just a way of importing variables and mixins. This allows each component’s CSS to be completely independent of the other components.

And with Webpack’s ExtractTextPlugin , the generated CSS is all extracted to a real CSS file. Which can be cached separately! Have fun caching your inline styles separately.

Inline Style lets you use JavaScript, so you won’t have to learn CSS

Except that you will. Seriously, what are you people smoking?! See those property names in your Inline Styles? They’re CSS.

Ok, maybe you won’t have to learn media queries and pseudo selectors. But instead, you’re going to have to learn the equivalents for whatever framework you choose. Or maybe you won’t – because if you don’t use an Inline Style framework, you’ll spend so much time re-implementing media queries and pseudo selectors that you’ll know how they work back to front.

Inline Style gives you more power

This is about the only valid point that people make. You do get more power with Inline Styling than you would with CSS, or even with CSS compilers like LESS, SCSS or PostCSS. But do you really need it?

No website is complete without a terrible car analogy, and this might be my only chance to ever write one, so here goes: CSS is a moped. It sucks, but it is what you start out with. It is dangerous, slow, and it quickly teaches you why you need more power. LESS/SCSS is a Japanese car. It is reliable, it gets you where you need to go, it won’t need fixing any time soon, and it’ll still hit the speed limit if you want it to. Inline Style is this:

Problems you would have avoided if you just used boring old CSS

You can’t use any existing tooling

Sure, CSS is a bit shit. But that is why people have made a number of amazingly useful tools which aren’t:

Maybe you don’t use any of these tools. Which would surprise me, because it would be silly to jump on this bandwagon without having at least tried the industry standard solutions first. But let’s say you haven’t, and then a brilliant new tool arrives which targets CSS. Too bad.

But tools aren’t all you’ll be missing.

You can’t use any existing CSS

So you know all those styles you’ve written over the years? You can kiss them goodbye. But maybe you don’t write many styles, so it’s all good.

Except, you know all those styles that other people have written over the years? You may as well forget they ever existed, because they’ll be incompatible with yours.

But no worries, it isn’t like you have to put all your style in Inline Style. You can just gradually move your style over, and pull in parts of the occasional CSS library when it makes sense. Except that you can’t, because:

Inline Style is infectious

So you know how you can define CSS styles with a number of priorities?

Element selectors have the lowest priority — you can override them with CSS classes. Classes can be overridden with IDs, which can in turn be overridden with !important .

And you know what overrides everything? Inline Style.

Now you may be thinking, “That’s great, because now I never have to worry about anything overriding my styles”. Which is true, but you wouldn’t have to worry about this anyway if you just namespaced your classes properly. Notice a pattern here?

But you will have to worry if you ever need to apply third-party styles, because Inline Style will kill them dead. And if you want to add some CSS to a component which defines its own Inline Styles? You’re shit out of luck. And if you want to override anything without passing in options as more Inline Styles? You just can’t.

And this might not be a problem for you. But unless your project is just a toy, you’re not the only one who counts.

Designers speak CSS

If you work on a team of anything other than the most talented people, you’ve probably already experienced this. In fact, you’re probably reading this rant for entertainment, not education. I hope you enjoyed the show, and don’t forget that sharing cat videos and JavaScript rants is caring!

But let’s say you’re a lone front-end developer experienced in both CSS and JavaScript. You’re building something which you’d like to eventually pay the bills, and scaling sounds like a problem you’d like to have. Part of scaling is that your code will at some point be handled by other people. And even if you don’t find anything in this article scary, everyone else certainly will.

But CSS still has problems too!

You’re absolutely correct. The thing is, there are better ways of solving these problems than using Inline Style. I’ve already alluded to a few of these solutions:

Using LESS to avoid repetitive style definitions

Using React to transform your CSS classes into namespaced CSS classes

Using Webpack to modularise your CSS

Not sure how to accomplish these? You could learn them the hard way: with Google and trial and error. Or, you could learn them the easy way: Join my Newsletter, then read the guides I’ll be sending out over the next couple weeks on namespacing and modularising CSS.

And to sweeten the deal, in return for your e-mail you’ll immediately receive three print-optimised PDF cheatsheets. One on React (see preview), another for ES6 and yet another for JavaScript promises. All for free!

I will send you useful articles, cheatsheets and code. I won't send you useless inbox filler. No spam, ever. Thanks! Please check your email for the link to your cheatsheets.

One more thing – I love hearing your opinions, questions, and offers of money. If you have something to say, leave a comment or send me an e-mail at james@jamesknelson.com. I’m looking forward to hearing from you!

Read More

Related Projects