Styled components V4: the good, the bad, and something completely different.

David Gilbertson
Ansarada Thinking
Published in
7 min readOct 21, 2018

--

I want to love styled-components, I really do.

In fact, I got so excited about the sexy new stuff in version 4 that I spent a rainy Saturday morning converting a project from Vanilla CSS to styled components, when I could have been jumping around in puddles.

It’s weird how small I look in this photo

My process: I renamed my CSS files to JS files, and replaced class names with exported constants.

The git diff from this change is quite interesting:

Now: JS. But earlier, CSS.

Even though the file type changes, the body of the CSS remains exactly the same.

(So people that freak out about ‘CSS in JS’ oughta calm down — it’s just a different mechanism for defining a relationship between CSS and DOM nodes.)

Having turned my CSS classes into ‘styled components’, I then incorporated them into my markup. Bye bye className.

That <Panel> was an interesting one. Previously, it was a component who’s only job was to make a div with a drop shadow and return the children. And I wanted to add a class to add a little extra margin at the bottom for this instance.

In the styled components world, I create a base styled component, like so:

And then, when I want to ‘extend’ that panel to create a variant:

(For the record, it took 12 minutes of refactoring for the backticks to stop looking weird to me.)

Another neat thing is that previously, I had to split some styling between my CSS and my JS (for example, when I wanted to position an element based on data).

Most of the things that affect the display
One more thing that affects the display

I can now just have a styled component called <Mark> and it handles all my styles. Note the left prop, right there between top and bottom where it belongs:

All of the styles in one place

I can get rid of those className and style props, leaving this super clean code:

My parent component no longer needs to know how to position the element — so no more CSS syntax in my JavaScript.

How interesting that this ‘CSS in JS’ library actually results in less CSS mixed in with my JS.

These changes might seem like small things, but they’re a win for both ‘separation of concerns’ and ‘declarative over imperative’.

And if you’re wondering, media queries look exactly like media queries should look:

So, it’s all pretty great.

I’d converted the whole app, taken a quick puddle break, and I was juuuust about to hit that merge button…

As I’ve said before, the easiest way to make a fast website is to not make a slow one. If you don’t add stuff that slows down your site, it won’t be slow.

So the question I must answer before I hit merge is: will styled components slow down my site?

Here’s how long it takes my app to switch from one page to another page (the page has ~2,000 DOM nodes).

I repeated the test five times each for Vanilla CSS and styled components:

Shit

That’s a pretty full-on 50% increase. There’s just no way I’m going to ship that to my users, no matter how much I like the developer experience.

What about the initial load time?

The styled-components package adds 13 KB to my 40 KB of assets, so this is probably not going to be pretty — if you’re reading this with young children nearby I’d suggest you ask them to look away.

Oof

Dammit, it’s a really clear NO for styled components.

This is I guess lesson number 482 about web performance: occasionally you’ll have to chuck out a whole lotta work in order to keep your site fast.

But there is hope.

Styled components version 2 was faster than version 1. Version 3, a bump up from that. Version 4 was faster again. Maybe one day styled components will be as fast as vanilla CSS, and on that day I’ll be all over it like seagulls on spilt chips.

And for those of you that aren’t me, perhaps performance isn’t such a big deal. If your website is taking 5 seconds to get going, an increase to 5.1 is not the end of the world. Or maybe you’re coding up an information portal for The Church of Scientology; it’s not like your users are going to say “OMG this site is so slow, I’m switching to Christianity”.

In these two cases — and possibly others — that sweet developer experience may outweigh the hit to performance.

In summary, I heart styled components, but my users probably wouldn’t.

This is the end of the part of the blog post that relates to the title of the blog post.

On a separate note, I would be the happiest kid at the party if you thought the type of chart used in this post was interesting. It’s my new side project.

I call it a ‘scatter bar’ and the idea is that it helps your brain properly ingest what the data has to say, without introducing artificial information like medians or averages.

(I’m quite sure I’m not the first to do this, but I googled it and couldn’t find them anywhere. Maybe someone will enlighten me in the comments. Maybe they’ll be nice about it.)

To demonstrate why this is necessary, below I have two data sets where the difference in the medians is 9%.

With the first, it’s fair to say that we can’t draw any conclusion from this data. It’s all over the shop.

A bar chart of the medians would show a 9% increase in ‘set 2’

Whatever was changed between ‘set 1’ and ‘set 2’ has no significant impact (in the plain English use of the word ‘significant’).

But check out this second example:

A bar chart of the medians would show a 9% increase in ‘set 2’

We could quite confidently say that whatever was changed in ‘set 2’ has had a reasonable impact.

But if we’d used bar charts showing a median, these two charts would have been identical.

One other thing: the lines are slightly blurry so if you have hundreds of values, information isn’t lost when two data points have the same value:

So, it seems crazy to boil data sets down to a median or an average and show it as a single bar, when it’s not so hard to just use the information-rich raw data.

(Even performing fancy pants manoeuvres like showing confidence intervals with error bars is still throwing away the informative raw data, replacing it with an aggregate, then layering some extra stuff on top.)

Anyhoo, this is really just a tool for me because I create charts like this quite a lot and want to know if some change actually makes a difference. But if you want to have a tinker and don’t mind that I’ll probably break it all the time, here’s the site and here’s the repo.

(Pro-tip: you can paste a range of Excel cells into the inputs if you’ve already got some data.)

OK so that was my very poorly structured blog post about styled components and then about a type of chart.

Before I go, I’d like to say well done to the folks who created styled components and say sorry I didn’t come to the conclusion that everyone should be using it. I really do think it’s great and look forward to it reaching Vanilla CSS speeds in the not-too-distant future.

Thanks for reading!

--

--