2020-02-28
1808
#react
Leonardo Maldonado
14912
Feb 28, 2020 ⋅ 6 min read

Why you shouldn’t use inline styling in production React apps

Leonardo Maldonado Fullstack developer. JavaScript, React, TypeScript, GraphQL.

Recent posts:

Apple Liquid Glass LogRocket

How to create Liquid Glass effects with CSS and SVG

This tutorial walks through recreating Apple’s Liquid Glass UI on the web using SVG filters, CSS, and React. You’ll learn how to build refraction and reflection effects with custom displacement and specular maps, and how to balance performance and accessibility when using advanced filter pipelines.

Rahul Chhodde
Dec 8, 2025 ⋅ 10 min read
tRPC vs ORPC: Which is better for your next TypeScript project, and why?

tRPC vs oRPC: Which is better for your next TypeScript project, and why?

tRPC solved type safety for full-stack TypeScript teams. oRPC borrowed the best parts and added interoperability. This article breaks down how both frameworks work and where each one fits best.

Temitope Oyedele
Dec 8, 2025 ⋅ 22 min read
gemini 3 and antigravity

A developer’s guide to Antigravity and Gemini 3

Check out Google’s latest AI releases, Gemini and the Antigravity AI IDE. Understand what’s new, how they work, and how they can reshape your development workflow.

Elijah Asaolu
Dec 4, 2025 ⋅ 6 min read
bun 1.3 javascript runtime what's new

Bun 1.3: Is it time for devs to rethink the Node stack?

Learn about Bun 1.3, which marks a shift from fast runtime to full JS toolchain—and see the impact of Anthropic’s acquisition of Bun.

Alex Merced
Dec 4, 2025 ⋅ 9 min read
View all posts

4 Replies to "Why you shouldn’t use inline styling in production React apps"

  1. 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

    );
    };
    “`

  2. 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.

  3. 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.

  4. 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.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

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 now