At CB Insights, we adopt a traditional CSS approach. Here's why.
It’s 2019, and there are a ton of great declarative libraries and frameworks that can be used to create interfaces. React, Vue, native web components, LitElement, Svelt — the list goes on and on. Just like cookies can’t be great without milk, a great interface can’t be great without styling.
So, which one do you choose?
It’s 2019, so our assumption is that the development community surely would have already rallied around a single solution for styling interfaces, similar to how the community has rallied around React & Redux — right?
The truth is that these days there are more options for styling than we’ve ever had, and the right choice is more ambiguous than ever.
We can make 2 general classifications of the multitude of approaches for creating styles for the web:
- Traditional CSS development (creation of normal CSS files, with some augmentation sprinkled on top).
- CSS-in-JS, the new kid on the block. You create your styling that can exist inside your Javascript code.
CSS-in-JS has its own unique advantages, but also has its shortcomings. We believe CSS with some small libraries / methodologies sprinkled on top (CSS Modules, PostCSS, Functional CSS), is a vastly superior approach. Traditional CSS is battle tested and works better at scale.
Our philosophies and choices make sense for our business case. Always be wary of anyone selling you a silver bullet, especially as it relates to software development. Just because it makes sense for Google or Facebook, doesn’t mean it’s the absolute right choice for everyone.
Our rationale for choosing traditional CSS will perhaps resonate with you, or hopefully spark some thoughts and conversations with your teams. So with that, let’s dive into the reasons.
Don’t lock yourself into a framework
Here at CB Insights, we work heavily with React — but there are also plenty of other frameworks, and we’d like the ability to pivot if we find something that works better for us.
As much as we’re fans of React, native web components are coming. We want to make sure that what we’re building now can be adapted to native web components later.
- Preact is a great performant alternative to React.
- Vue adoption increases all the time and staves off complexity because it separates templating and logic.
- Blazing fast server rendered apps (Phoenix / Elixir) are coming back in vogue, and these are also great ways to create an application. CSS-in-JS does not support these whatsoever.
- Legacy features — every company has them. Choosing a system that does not support legacy features like CSS-in-JS can lead to fragmented development teams either rushing conversions of legacy features (been there) or just choosing to not maintain these features at all (done that).
It’s worth mentioning that the most popular CSS-in-JS library, Styled Components, only supports React & Preact.
Super fast and cacheable
Among several characteristics, CSS-in-JS:
- Doesn’t load as fast as normal CSS
- Is not cacheable separately from your javascript (not only for a specific page, but across pages, which is what you can do with traditional CSS)
- Prefers that you server render your React application to optimize performance (SSR). This may not be the right choice for your application, or you may not be able to support it.
Avoids complexity of Javascript
- Many times, Javascript best practices mistakenly get prescribed to CSS-in-JS.
- You run into complexity / bugs you may not run into with CSS, that either difficult to address, or are bugs that have not been addressed for quite some time. Be prepared to run into problems like these, especially when using add-ons & integrations.
- For Typescript users, styled-components becomes more complicated than they needs to be, and developers end up spending more time perfecting their types rather than optimizing CSS display.
- Javascript is not fault-tolerant. Native CSS is inherently tolerant to errors: If a browser does not recognize a CSS rule, the rule is ignored.
While Styled Components is a great CSS-in-JS library, you create the opportunity to add unnecessary complexity, or introduce complex discussions around CSS (again, imagine big teams). You can sidestep this completely and gain a lot of the encapsulation CSS-in-JS provides you by using CSS Modules.
Developer on-boarding / training
There is a learning curve with CSS-in-JS. Sure, you can get started fairly quickly, but when you have a large codebase with 20+ developers of varying experience contributing, modifying, and generalizing for broader use, it can get tricky. You don’t want your code to look like one specific engineer authored it. When working with CSS-in-JS, this becomes a huge challenge.
Let’s use Styled Components for instance:
- Should this element be coupled to a span? a div? Sure we can use as=’element’ to overwrite this, but what should the default element be? This is going to be a huge cause of bike-shedding in code reviews and waste valuable time.
- Should we use attr? Does it make sense to couple attributes with this style? This can quickly become a source of unnecessary debate in my experience.
- Because we need to optimize for performance, should we allow styled-components to inject styles via CSSOM api, but then sacrifice ability in production to debug our css?
- Back in v2: should we use .extend? Or should we wrap the component with styled()? (Hint: this requires us to know if it’s a styled component, or a react component).
We love traditional CSS combined with modern approaches, and there’s actually a lot more rising favor around ideas like these (Enduring CSS, Functional CSS, etc).
I think as developers, we can be drawn to the newer, shinier tool. Given the current landscape of front end development, there is no shortage of cool new things to learn. But often enough, those who adopt a traditional CSS approach can actually spend more of their time working on interesting and cool problems rather than spend time in code review debating Styled Components interfaces (which often come dangerously close to bike-shedding).
The promise of CSS-in-JS mostly has been the promise of encapsulation, namespacing, and co-location of component and styles. These are all admirable goals; however, with traditional CSS and libraries like CSS Modules, we can have our metaphorical cake (achieve encapsulation, namespacing, co-location), and eat it too — a legacy-compatible and future proof CSS system, in a familiar format for developers, without the added complexity. That leaves us more time to discover more problems to work on.
If you liked this article, stay tuned — as we have a lot more on the topic of frontend development!
If any of these ideas interest and intrigue you, we’d love to hear from you! We’re building a world class team at CB Insights, and we’re looking for talented people. Please email us at careers@cbinsights.com.