Revolution vs. Evolution: CSS in JS
This is going to be a rather short article with some thoughts about the controversy around CSS in JS. Mark Dalgleish did a great job writing about this topic a couple of days ago: A Unified Styling Language. If you haven’t read the article yet, go ahead and read it, it’s a great roundup of the pros and cons (mostly the pros) of writing CSS inside your JavaScript code.
My concerns with CSS in JS
Mark Dalgleish did a great job highlighting the many upsides of using a CSS in JS approach so I take the chance to express my biggest concern with this methodology.
Many (competing) libraries
The trend of baking your CSS styles into your JavaScript modules is quite new and still there are already a multitude of competing libraries which you can use to write CSS inside your JavaScript more comfortable. Mark Dalgleish lists seven such libraries in his article and I’m quite sure this are just the most noteworthy from his perspective so there might already be at least a dozen commonly used CSS in JS libraries — and we’re just getting started.
Competition is usually not a bad thing but because all of those libraries are using their own approach and most of them are not interoperable, it will not be possible to share bits of styles as NPM packages which just work for all of the available libraries. Frameworks like Bootstrap would have to provide a dozen variants for every major CSS in JS library commonly used.
I’m a big believer in writing reusable, shareable small components and moving away from huge monolithic frameworks like Bootstrap. Most of my open source work (node-sass-magic-importer and avalanche) is focused at working on ideas of how we can solve this problem with the tools we already have or how we can improve the tools we currently have to make this possible. But with the current state of CSS in JS libraries we’re moving further away from achieving this goal — without a solid standard, code sharing will not be feasible in a sustainable way. We already have a solid standard, which is just good old CSS (and Sass as a superset of CSS).
The best solutions come from gradually improving existing systems instead of radically replacing old with new. Hence the success of the familiar SCSS syntax of Sass (over the more radical Sass syntax) or the fast adoption of ES6 compared to more extreme approaches like CoffeeScript or Dart.
Final thoughts
Humans evolved from unicellular organisms over a time span of billions of years. Western democracies where improved by taking the best bits and pieces of revolutionary ideas like socialism and, in more recent years, the green movement — whereas many of the states formed by radical revolutions were doomed to fail almost as spectacular as they were created (although there might be situations where a revolution is needed).
CSS in JS is a revolution which is currently going on. If we’re smart, we can learn a lot from it and gradually improve our existing systems to implement the best ideas and solutions provided by popular CSS in JS libraries.
Evolution is boring, democracy is boring and standards (and even more the process of defining and improving them) are very boring. But in the long run those boring and slow processes will win. And it might be that CSS in JS will win, but it will be a very boring and unspectacular version of CSS in JS, defined by some very boring standards and after an even more boring process of defining those standards.
