No KISS for CSS-in-JS

Ivn Cote
Ivn Cote
Jun 24, 2017 · 7 min read

Disclaimer: This article is very opinionated. Please use whatever you want. I highly advise you to employ different techniques for different applications, so you can compare them on real use cases regarding your projects. All the following points are about the “mathematical point of view”, i.e. I’m just trying to describe the perfect world of web development.

photo by Mitch Dobrowner

Not so far ago, the use of React triggered a broad discussion of CIJ in component-based development. This topic is still very hot. Two presentations out of 11 at the last CSS conference in Berlin were devoted to this subject. I’m not even speaking about numerous articles and projects which are trying to compete for the developer audience.

Joey Tribbiani smiles as Santa is talking about CIJ

But CSS-in-JS is not about developer experience only; it also tries to solve the UX problem and push component-based development forward. On top of that, CIJ tangles and confuses the many aspects of frontend development, thus contradicting the KISS principle and the UNIX design principle of making single purpose tools (programs). I’ll go into the details later, let me first emphasise why the aforementioned principles are useful. Different generations of developers start with different languages/frameworks (and market situation of course) so they can’t just set the rules for the next developers. It’s life. It is still crucial to distil one’s experience and propagate it further, though: UNIX principles are part of such precise and laconic knowledge for smooth development. We can follow them and be happy.

Knowledge transfer

What’s wrong with CIJ? The brief answer will be that it positions itself as a substitution for CSS. Even more: despite the fact that CIJ is only a subset/superset of CSS, CIJ advocates like Mark Dalgleish tell us that the approach will solve problems across platforms, not only in web. Let’s discuss the appearance of these new libraries in web development. Before CIJ, we had projects for inline style management inside React components. They solve the problem of scoped CSS selectors by using the highest CSS specificity. So a developer could be sure that the component would have a certain presentation on the web page. For mature developers, it was no silver bullet, of course; they used preprocessors for code management and naming convention for maintainability. Then CSS modules emerged with a solution for scoping CSS. People mainly started using it for its simplicity. I’d say that Shadow DOM styling is much more promising, but Web Components never received so much hype. So CSS modules set meaningless class names for the DOM elements just in order to solve the scoping problem. CIJ combines this concept with inline style paradigm of putting all the CSS rules along with their logic right into javascript file. Defenders of CIJ contend that this isn’t the inline style approach anymore and that we can solve many problems at once. It’s a strong statement. But please, do not try to solve all the problems at the same time! Especially no need to reimplement the CSS specification in javascript in order to support the same set of rules on different platforms (I’m talking about flex implementation for react-native particularly).

At this point, I’d like to be more concrete and give you more examples. Having followed the CIJ topic for several last months and read some pro and contra articles, I can recommend you several authors. They will give you a variety of reasons why setting up CSS in JS is generally not a good idea.
http://keithjgrant.com/posts/2015/05/against-css-in-js/
http://jamesknelson.com/why-you-shouldnt-style-with-javascript/
https://medium.com/@gajus/stop-using-css-in-javascript-for-web-development-fa32fb873dcc

These guys are really good in terms of their impact on the community, I mean, they are not just talking and complaining like myself. You can trust them ) Some of the CIJ problems mentioned in the articles are worth repeating here.

  • CIJ does not mean you don’t have to learn CSS. Anyway, as a frontend developer you should know about the CSS box model, the specificity of selectors, and many other aspects. Some prefer to restrict themselves by using a pre-defined set of rules for building UI. It could be flexbox usage only or sticking to a specific grid system like Bootstrap. Nevertheless, knowing all CSS possibilities gives you flexibility and freedom.
  • CIJ is an additional layer of abstraction in your project. It sounds like a usual thing in engineering. I mean, we always put different layers together for a perfect result. But in the case of CJS, the layer is not necessary and potentially costly. Once there is a problem in a CSS code, it will be hard to define which layer contains the issue. It is still the early days of CIJ, and the debugging process (as well as wide support in IDEs) is far from perfect.
  • CIJ does not help to communicate inside the team. There should be a common language for a such communication. Many designers can understand and write CSS files. And there are people who are professionally engaged in markup creating only. How do you see them communicating with the CIJ world? Do you want them to understand a component system written in javascript? I don’t think so.
  • CIJ approach makes your code even more tangled. Some developers like to place CSS rules right into a javascript file, but it explicitly violates the separation of concerns principle. CSS was created for visual representation. It is a powerful concept in terms that once we want to change this representation, we could modify the CSS file only. Well-designed components don’t require markup modification in such cases.
  • CSS is a purely declarative language; for that very reason it is so powerful. But CIJ tends to be imperative. We are losing here.

Doug McIlroy

Let’s continue with a StyledComponent apology. At the last CSS conference in Berlin, Glen Maddern gave some reasons why he had written this library. He said there was no need to use additional libraries like PostCSS in order to bundle styles. Instead you can use the usual JS modules. He argued that file transformations are not so transparent compared to a set of programmatic rules. Seems to be good so far. Then he mentioned that the syntax of the library was SASS inspired. Let’s stop here. If they have changed the syntax, it is not classical CSS anymore, right? It is a superset or a subset, same difference. But combining a building tool like PostCSS and syntax sugar like SASS you mess with separation of concerns. I’d compare such an approach with a very unexpected situation when a chef starts making a sweet cake with meat inside offering it as a substitution for the ordinary lunch of a main dish and a dessert. The same thing has happened to the author of JSS Oleg Slobodskoy, who tangles together very different JSS targets. Some of these features are specifically performance-oriented, others are about code maintenance. So now everybody loses the purpose of the tool and its main use case.

Joey Tribbiani enjoys eating custard, jam, and meat

Besides, the performance arguments are especially speculative. I was involved in web optimization topic for a while, and since then I believe it is really a separate part of the development process. When Glen tells us that the critical CSS issue is magically solved by CIJ, I start thinking that this specific problem is only a small piece of the huge puzzle called web performance. And when good guys compare different CIJ libraries looking for the most effecient bundle size, I’m really concerned that it could have no relation to my SPA project, because the big bundle problem should be solved in another dimension.

Just to be clear, please start from the beginning: the user. Yes, performance is a user-centered metric, and we have a very good methodology to apply here called RAIL model developed by Google. It helps you understand the criteria, and then you can use the Lighthouse tool to improve the performance for your particular application. CIJ could not be a performance tool because it already has another purpose: code maintenance. And just to be consistent, some of the good examples of CSS infrastructure tools are CSSO and Autoprefixer.

Let’s imagine what could happen in the future. It seems like we have not so many options for CIJ. Some people believe that it will substitute CSS. But I doubt it. CSS is actively developing, you just need to pay attention to the right sources. Especially important is the Houdini project. Of course, CIJ could be a substitution for CSS on non-web platforms, but it underlines mainly the problem of these specific systems. Maybe I’m very wrong about the purpose of numerous CIJ libraries, and they are preliminary solutions before a brand new standard on the web. Nevertheless the current CIJ status is unclear for me what makes me being very skeptical about its bright future.

Ivn Cote

Written by

Ivn Cote

Ivan Kotov, Web Software Enthusiast. "Liberté, Courage, Générosité"