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.
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.
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.
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.
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.
- CSS is a purely declarative language; for that very reason it is so powerful. But CIJ tends to be imperative. We are losing here.
This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
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.
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.
If you optimize everything, you will always be unhappy.
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.