Template Strings vs. Objects in CSSinJS

As the “semicolon vs. no-semicolon” discussion slowly faded out from the twitter stream, the 2017 question now, that seems to divide the CSSinJS community, is:

Should I use template string literals or JavaScript objects for my CSSinJS notation?

Let me help you with that.

Why are template strings such a popular choice?

1. The habit

After many years of writing CSS, your eye is trained on detecting typos. The regular CSS format differs from objects notation at the first glance just by lower cased characters, quotes and semicolons. What seems to be mostly about form, is a big change for your eye. It requires some practice to get used to the new look in order to get comfortable with it and become efficient again. A question you have to ask yourself is: are you ready to learn and adopt a different style?

2. Editor tools

Libraries using object notation and template strings struggled both for a long time to get supported by editors with highlighting, autosuggestions and abbreviations. Template strings are easier to support, because editors just need to identify the beginning and the end. To support objects, they have to additionally support camel cased property names and quoted values. Slowly this is changing and I am sure in the future it won’t be a problem anymore. Also I am hoping at some point Emmet will catch up as well.

3. Verbosity

Using CSS as a language has a huge benefit — you can use its primitives. What this means is that values like color: red; or float: right; don’t need to be surrounded by quotes to indicate a string.

Why object literals are a good choice as well?

1. A lot of similarities with CSS

Despite of all differences, objects still look very close to CSS:

2. Camel case

At the first glance, using camel cased notation seems unnatural. It has to do a lot with perception. What many don’t know is that CSSOM and DOM styles share the same CSSStyleDeclaration interface. Every CSS property has an equivalent DOM notation in camel case in the spec. So camel cased CSS properties are just as much part of the browser as the ‘regular’ CSS syntax is.

3. The amount of interpolations is the key

Lets compare some code using two libraries: styled-components and styled-jss.

Most of the time we see code examples like this, which looks nice with template literals. Here is an example using styled-components:

Let’s convert the exact same code to object literals using styled-jss:

You might think that this has a lot more visual noise compared to the first example, mostly caused by the quotes, right?

Lets make it more realistic. In real projects, spacing should be generalized and centralized, colors palette should come from a theme.


Which one has more visual noise now? From pure characters amount, styled-components scored 367 characters and styled-jss 357, though I don’t think that more characters is generally bad. I think visual noise is when more characters are in the wrong place, where they are not helpful. Template literals introduce a lot more noise around their interpolation due to their notation ${}, while JS’ primitives automatically have the upper hand.


The more interpolations you use, the more object notation tends to win over template strings in terms of readability.

We need to support both!

With JSS we don’t want to force you to make a choice or settle on only one notation. We will thus allow you to use either. Depending on how much interpolations you need, you can switch between template literals and objects, as you go. Also it might be handy for copy and pasting from the dev tools.

Use the best tools for the job, be efficient and don’t forget to clap and retweet.❤️