Please, Please Don’t Use “CSS in JS”
Update (August 2020): I wrote this 4 years ago when the React/component community were still in a relatively immature state. The (poorly articulated) higher level theme in this piece was something like “think critically about whether you need tools created by MegaCorps for MegaCorps with unique mega scale problems”, and when I wrote this, CSS in JS felt like a symptom of that more fundamental problem.
However, now we live in a React-centric component world and the CSS in JS tooling has evolved and matured significantly.
So, while I no longer endorse Don’t Use CSS in JS, I do still believe that you should consider technology decisions critically, especially if they involve technology invented to solve problems at mega scale companies, and you don’t work at one. Cheers.
CSS in JS is one member of a family of front end methodologies recently invented by a small group of developers at Facebook. It is in the same “family” as React and Flux. The best place for an introduction to CSS in JS is in this slide deck.
CSS in JS, in a nutshell, is a Node-JS-based CSS build tool, wherein you write your CSS in a Javascript-like representation of CSS, and the resulting CSS can be output to a stylesheet, or can be inlined for easy use with React components. The most obvious use-case for this technology is for use with React, a JS component rendering library for building “isomorphic” javascript components, with multiple possible outputs (web, native mobile via React Native, web canvas, etc).
But it’s not worth going much deeper into the details of this tool here. What matters can be found on slide 2 of the deck linked above:
Do you see why the developers at Facebook invented this rather extreme approach to web development, wherein they tossed out browser-based CSS, one of the simplest and most well-known parts of the web development stack, and even extended the language itself? Like so many things at Facebook, the adoption of this tool seems to have been driven, at least in some part, due to scale. Really massive scale.
When I’m saying at scale, it means in a codebase with hundreds of developers that are committing code everyday and where most of them are not front-end developers.
Do you have this problem at your company? Are several hundred people committing CSS to the same project every day. Unless you work at Facebook, Google, or one of literally less than 10 other companies in the world, you probably don’t have this problem.
The enumerated list on that slide is an excellent summary of the core problems with CSS. But all languages have problems. One could argue that the problems of languages are like constants in a sea of variables, constants that we learn to live with. And unless you introduce some new variable, one that significantly compounds the effects of the other variables, the problems presented by those constants are livable and workable, a set of problems around which teams can specialize, rather than reinvent.
But, several hundred people committing to a single project is fucking bananas. It’s a complete game-changer, where it might make sense to re-think how CSS is written and developed in a web project.
One can imagine the reasoning for creating this particular tool to be some combination of:
- Hundreds of people write CSS at Facebook, and these problems affect productivity in a real way. Something better is needed.
- React is core to the Facebook business, because it powers nearly all of Facebook web and native mobile. How should styling be done in a unified way on web and mobile?
- The existing solutions feel old and busted.
Just because CSS in JS works for Facebook, and they happened to open source it, it doesn’t mean you should use it. Back in the day, General Electric “open-sourced” six-sigma, but you probably shouldn’t use that either.
Still, just because this particular solution is a good one for Facebook doesn’t necessarily mean it’s a bad one for your 20 person startup. On principle, that’s true.
To quote one of the creators of JSS:
CSS hasn’t been designed to fit into components based architecture.
Are you writing your entire app in components? Does your startup have such a broad scope in it’s product that you need to? Think for a moment on the vast landscape of functionality that Facebook entails: newsfeed, groups, chat/messenger, advertising, news articles, blogging (facebook notes), events, photos, pages, and more! All of it available on desktop web, mobile, ios and android, powered by the same set of technologies! Amazing! You can start to see why they might need to re-invent how web applications are built.
CSS in JS represents a fundamental change in how web apps get written — it throws away CSS in favor of a complex Javascript-based build chain that you’d be forced to use to implement CSS in JS. Worse yet, it actually extends the language. It has vendor lock-in built-in! Joy!
Is it worth replacing something that is simple, and that virtually everyone either knows how to do, or can learn in a couple of days (CSS), with something that is highly complex, relies on a compiler maintained by a small group of people (really just one person), and requires re-training yourself, your entire team, and everyone in the future who joins your team? If you’re a consultant, it worth doing this to your clients? Are the benefits that great?
Do you have several hundred people feeling the pain of CSS development as part of their everyday workflow, and a nearly 300 billion dollar business that relies on the software this technology powers? If the answer is no, think hard before you add this dependency into your app.
