Template Strings vs. Objects in CSSinJS
As the “semicolon vs. no-semicolon” discussion slowly faded out from the Twitter stream, the 2017 question that seems to divide the CSSinJS community is:
Should I use template string literals or JavaScript objects for my CSS-in-JS 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 lowercased 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. Editors support
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 simpler to support because editors need to identify the beginning and the end. To understand style objects, they have to add support camel-cased property names and quoted values, as well as some non-standard variations of a syntax. 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. Less 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 syntax
Despite all differences, objects still look very close to CSS:
2. Camel case notation is part of CSSOM
At first, using camel case notation seems unnatural. It has to do with 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 JS notation in the camel case in the spec. Camel case CSS properties are just as much part of the browser as the ‘regular’ CSS syntax is.
3. The amount of interpolations is the key
Let’s compare some code using two libraries: styled-components and styled-jss.
Most of the time, we see code examples like this, which look 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?
Let’s make it more realistic. In real projects, spacing should be generalized and centralized, colors should come from a theme.
vs.
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 are generally bad. Visual noise is created 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 is better for readability.
Why not 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.
