CSS hasn’t always been an important part of web development. Before CSS was popular, many companies had ugly and inaccessible sites. Throughout the years the web has evolved, new frameworks were created, JavaScript consolidated as the main programming language for the web, developers were improving their frontend skills. Now, we have a lot of concepts for styling the web.
A lot of developers will remember the time when we used to do a lot of work to work with HTML and CSS. We had to create a separate .css file, link our new CSS file by using the link tag in our HTML document, and after this, we had our CSS styling working fine.
Styling our applications using CSS was sometimes a challenging job. We didn’t have a lot of new CSS features and browsers didn’t support a lot of new features. Do you imagine yourself having to use float: left
and float: right
to position elements?
That was pretty hard for some developers to understand at first, but a lot of things changed in the last few years and CSS styling is one of them. React is the most used JavaScript library for modern applications, and has brought with it a lot of new ideas and concepts to style our applications.
In the React ecosystem, we have a lot of different libraries for different purposes, and in the styling part of the frontend it’s the same, we have a lot of libraries and concepts to style our React applications. Here is one of the most used ways to style a React application:
A few years back, a lot of developers were using and advocating for the use of the CSS modules styling in the React community. With CSS Modules, you have all your class names and animations scoped locally by default, it works pretty similarly to the old way of styling in HTML documents. Here is an example:
.container { width: 400px; height: 400px; background-color: blue; }
A module is just a simple .css file, and it renders into the HTML using a dynamic CSS class name, the whole idea of this concept is to avoid name collisions or affecting the styles of other components in our applications:
.container_4xks92k2kl { width: 400px; height: 400px; background-color: blue; }
The trending way to style React applications today is CSS-in-JS, we have a lot of famous libraries to do that such as styled-components, Emotion, Radium, etc. A thing that you should know about CSS-in-JS is that CSS-in-JS is not a specific library, it’s a concept that tries to solve the problem of styling in React applications.
Since React is all about components, why not use it to style our elements as well? That’s the idea that CSS-in-JS introduced to us, instead of passing a lot of class names attributes to our elements, let’s create specific styled-components and benefit from the idea of componentization that React introduced to us:
import styled from "styled-components"; const Button = styled.button` width: 200px; height: 40px; background-color: green; border-radius: 6px; `;
Now, let’s talk about the most used way to style React applications, why this concept is not a very good idea for your applications, and why you shouldn’t use it.
Inline styling is one of the most common ways of styling React applications, a lot of developers start to use this concept when they’re starting a new application because it’s very easy to understand at first and you can achieve the same final result that you would achieve in other concepts like CSS-in-JS and CSS modules. One of the reasons why the inline styling is very famous and used is because when a new developer is starting to learn React, they probably will start with the inline styling concept.
We can use the inline styling in plain HTML documents as well. If you want to test it, just create a plain HTML document, and create a style attribute in the element that you want to style. In plain HTML documents, this style attribute receives a string, and inside that string, we can pass our CSS properties, like this:
<button style="width: 200px; height: 50px;">My Button</button>
In a plain HTML document, the type that the style attribute expects is a string, a little bit different from React.
Inline styling in React is pretty simple, all you need to do is create an object, and inside that object, you pass the CSS properties that you want:
const styles = { width: 200, height: 50, backgroundColor: 'red' };
The properties in our styles object must be camelCase style, this is something related to the JavaScript language, we cannot have kebab-case because it does not work with the syntax rule.
Now, we can pass this styles
object to our element. Each element in React has a style attribute, similar to each HTML document, but in this case, the style attributes expect an object. This is how we can use inline styling in React.
import React from "react"; const styles = { width: 200, height: 50, backgroundColor: 'red' }; const Button = () => ( <button style={styles}>My Button</button )
When you’re using inline styling in React, you don’t need to pass a unit to a property in CSS, you can pass just a number and React automatically appends px to your numeric inline style property.
But, we have some problems with the inline styling in React, especially if you’re working in a big application and have a lot of reused components. Even if you’re not working in a big application yet you’ll eventually start to feel some of the disadvantages of inline styling in this post.
We know that inline styling works really well when we’re starting a new application, and we can apply it everywhere we want in our code. But if this concept works fine, why should we stop using it?
The inline styling concept might not help you to build the best React components in your app. If you’re planning to build a very performant, scalable, and rich application inline styling is not the right option for you.
One of the main reasons that inline styling is not a good choice for your application is because it does not support (or it has really poor support) for CSS features.
Every application nowadays might have to end up using some selectors such as :hover
, :active
, :focused
, etc. How can we achieve this same behavior with inline styling? Well, it’s trickier and sometimes you might end up with a lot of unnecessary code just to achieve a simple :hover
in your component.
Using a CSS-in-JS library, you can achieve it very easily like this:
const StyledButton = styled.button` width: 200px; height: 50px; background-color: red; &:hover { background-color: blue; } `; const App = () => { return ( <StyledButton backgroundColor="green"> My Button </StyledButton> ) };
If you’re not planning to use CSS-in-JS to do that you’ll end up having to write a lot of code, maybe even use the state to simulate the hover in the element. This is one of the most painful points about inline styling and this is a major reason why you should consider moving away from inline styling in your applications.
Sometimes when we’re building our React components, we want to achieve a nice level of component reusability, sometimes we’ll end up in some situations where we’ll need to change a specific property of our CSS element. Let’s imagine that we have a button, and the default backgroundColor
of this button is red:
const Button = () => { return ( <button style={{ width: 200, height: 50, backgroundColor: "red" }}> My Button </button> ); };
But, what if I want to use the same button, but in this case, I wanted to change the backgroundColor
to green? On a daily basis, we face these situations, and the inline styling here cannot help us create a good component.
We might have to end up using JavaScript ternary statements, which it’s not a good idea because it will leave our code heavier, hard to understand, and grow the component size.
const Button = ({ green }) => { return ( <button style={{ width: 200, height: 50, backgroundColor: green ? "green" : "red" }}> My Button </button> ); };
We can agree that this code it’s not looking good. We have to use a JavaScript ternary statement to change only one property of the button style, imagine if we had a complex component with 20 changeable properties? It would become a mess very quickly.
Otherwise, in CSS-in-JS libraries, all we have to do is pass property to our style, and it’ll change depending on the value of the prop, like this:
const StyledButton = styled.button` width: 200px; height: 50px; background-color: ${({ backgroundColor }) => backgroundColor}; `; const App = () => { return ( <StyledButton backgroundColor="green"> My Button </StyledButton> ) };
It’s a default behavior nowadays that applications support mobile devices, so you’ll have a lot of media queries in your application.
But, if you’re using inline styling, you can’t use media queries because it does not support it. Remember, you’re using a plain JavaScript object to pass to your element, how could you use media queries?
You can use it by creating some custom function to get the actual width window size, like this:
const minStyles = { width: 200, height: 50, backgroundColor: "red" }; const maxStyles = { width: 300, height: 50, backgroundColor: "blue" }; const App = () => { const renderStyles = () => { if (window.innerWidth <= 800) { return minStyles; } return maxStyles; }; return <button style={renderStyles()}>My Button</button>; };
But imagine it in the long-term, imagine if you need to support five different media queries, what your code would look like? It would be really messy and not easy to understand at all. And also, you would have to create a lot of styles
objects just to handle all media queries.
Imagine an app that has to reach millions of users every day. You’ll end up in an application with dozens of components, and the inline styling might slow you and your coworkers down a little bit to create new components or maintain those that already exist.
If you’re still with some inline styling components in your application, and if they’re working fine, for now, you can stick with this concept for a while. The intention here is to show you why your application will not be very performant and scalable in the long-term.
One of the jobs of developers is to try to find the most performant solution that won’t take a lot of time to implement and also help build a strong, resilient application in the long-term.
In this article, we learned about some ways to style React applications, we learned more about the inline styling concept in React, and why we shouldn’t be using this concept if we’re planning to have a scalable and productive application.
Install LogRocket via npm or script tag. LogRocket.init()
must be called client-side, not
server-side
$ npm i --save logrocket // Code: import LogRocket from 'logrocket'; LogRocket.init('app/id');
// Add to your HTML: <script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script> <script>window.LogRocket && window.LogRocket.init('app/id');</script>
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up nowIt’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Bypass anti-bot measures in Node.js with curl-impersonate. Learn how it mimics browsers to overcome bot detection for web scraping.
Handle frontend data discrepancies with eventual consistency using WebSockets, Docker Compose, and practical code examples.
4 Replies to "Why you shouldn’t use inline styling in production React apps"
Your argument against inline styles because of limitations with argument passing appears somewhat flawed; or am I misunderstanding something here?
“`
const Button = ({ backgroundColor }) => {
return (
My Button
);
};
“`
I don’t see inline styles not “looking good” because you used a ternary operator. Actually, you could do a small refactor it to be just as you did on your CSS-in-JS approach and you code will look the same.
I’d say you can use inline styling for minor changes on not-reusable components or for styles you don’t want be available to be changed, like giving div a flex property rather than create a React component or a CSS classes only to this end. If you need more complexity than you can move to a more featured place: CSS-in-JS or whatever, but it’s easier to start from basic and then evolve as soons as you need more power.
This is exactly what I was thinking… he also says that using the ternary “grows the component size” but it actually doesn’t result in any more lines of code. In fact it results in less lines of code. It also is very readable, I would argue that it’s more readable than the styled component version because it doesn’t need a special syntax unique to the styled component library, instead it is taking advantage of a feature native to the javascript language.
There are libraries that allow devs to access all of CSS features with inline styles, so that’s not a real concern. And you keep saying that inline styles aren’t “performant” but never offer a single reason as to why their performance is worse. You also don’t provide any reason as to why inline styles aren’t “scalable”. This is just a really low quality article, and it’s sad because it’s also the first search result in google.
“the inline styling might slow you and your coworkers down a little bit to create new components or maintain those that already exist.” Again, WHY? You make so many claims in this article and never even attempt to substantiate them in any way. It’s ridiculous.
“One of the jobs of developers is to try to find the most performant solution” This is just flat out wrong. As a developer you don’t need to find the “most performant” solution, in fact it’s often a huge waste of time. Why? Because users don’t care if your application takes 10 ms to run instead of 1 ms to run. Computers are very fast. What is important is implementing features quickly, not implementing quick features.