Published on 2025년 3월 18일 by Evan Jacobs 2025년 3월 18일 에반 제이콥스에 의해 발행됨
First and foremost, thank you to everyone who has contributed to styled-components over the years. Open Source is hard work, and many of the larger feature and/or refactoring drives probably would never have shipped without your support! 무엇보다도, 수년 동안 스타일드 컴포넌트에 기여해 주신 모든 분들께 감사드립니다. 오픈 소스는 힘든 작업이며, 많은 큰 기능 및/또는 리팩토링 작업은 아마도 여러분의 지원 없이는 출시되지 않았을 것입니다!
As I write this in 2025, styled-components as a project is in "maintenance mode". There are a number of reasons for this: 2025년에 이 글을 쓰면서, styled-components 프로젝트는 "유지 관리 모드"에 있습니다. 이에 대한 여러 가지 이유가 있습니다:
The React core team has decided to defacto-deprecate certain APIs like the Context API (not available in RSC with no migration path.) React 핵심 팀은 Context API와 같은 특정 API를 사실상 사용 중단하기로 결정했습니다(마이그레이션 경로 없이 RSC에서 사용할 수 없음).
The ecosystem in general has largely moved on from css-in-js as a concept while other technologies like tailwind have absolutely exploded in popularity. 생태계 전반이 css-in-js 개념에서 크게 벗어나고 있으며, tailwind와 같은 다른 기술들이 폭발적으로 인기를 끌고 있습니다.
quantizor (me, the core maintainer for styled-components since ~2018) no longer has active production deployments of styled-components in larger applications, so context of usage in real products will continue to wane and eventually cease altogether. quantizor(2018년부터 styled-components의 핵심 유지 관리자로 활동 중인 저)는 더 큰 애플리케이션에서 styled-components의 활성 프로덕션 배포를 더 이상 가지고 있지 않으므로, 실제 제품에서의 사용 맥락은 계속 줄어들고 결국에는 완전히 사라질 것입니다.
There are many ways to do OSS, and I made a decision early-on that the library would not fundamentally change its API or capabilities. When you adopt a library, one of the most annoying things a maintainer can do is change everything and cause a massive migration burden. Accordingly, styled-components will not remove APIs like use of React Context and will continue to be available with occasional bugfixes and misc improvements to support the existing user base. OSS를 수행하는 방법은 여러 가지가 있으며, 저는 라이브러리가 기본적으로 API나 기능을 변경하지 않겠다는 결정을 일찍이 내렸습니다. 라이브러리를 채택할 때, 유지 관리자가 할 수 있는 가장 성가신 일 중 하나는 모든 것을 변경하여 대규모 마이그레이션 부담을 초래하는 것입니다. 따라서 styled-components는 React Context의 사용과 같은 API를 제거하지 않으며, 기존 사용자 기반을 지원하기 위해 가끔 버그 수정 및 기타 개선 사항과 함께 계속 제공될 것입니다.
For new projects, I would not recommend adopting styled-components or most other css-in-js solutions. Given the current ecosystem dynamics, I don't feel comfortable continuing to collect donations for this project. Existing subscription tiers have been removed as of today and any recurring donations cancelled. We have a small war chest that will fund ongoing maintenance work as-needed and bug bounties may be issued from time to time for particular issues. 새로운 프로젝트에 대해서는 styled-components나 대부분의 다른 css-in-js 솔루션을 채택하는 것을 추천하지 않습니다. 현재 생태계의 역학을 고려할 때, 이 프로젝트에 대한 기부를 계속 받는 것이 편안하지 않습니다. 기존 구독 계층은 오늘부로 제거되었으며, 모든 정기 기부는 취소되었습니다. 우리는 필요에 따라 지속적인 유지 관리 작업을 지원할 수 있는 소규모 전쟁 자금을 보유하고 있으며, 특정 문제에 대해 가끔 버그 보상이 제공될 수 있습니다.
Thank you for your understanding, 이해해 주셔서 감사합니다, quantizor and the styled-components team quantizor와 styled-components 팀
Oh! For me styled-components is the natural way to create web apps... It has been for years. I tried tailwind several times though... Should I learn all those classes to write css? And convince our designers to remake their mockups to fit tailwind styles? Okay, I will try... 오! 나에게 styled-components는 웹 앱을 만드는 자연스러운 방법이다... 수년간 그랬다. 하지만 tailwind를 여러 번 시도해봤다... CSS를 작성하기 위해 모든 클래스를 배워야 할까? 그리고 우리 디자이너들이 tailwind 스타일에 맞게 목업을 다시 만들도록 설득해야 할까? 알겠어, 시도해볼게...
tailwind exploded in trends mainly because people have to google utility classes every time they need to write styles ;) But in general I agree that it's insanely popular now. I switched to it recently too, because it allows to write adaptive styles much faster. tailwind는 사람들이 스타일을 작성할 때마다 유틸리티 클래스를 구글링해야 하기 때문에 트렌드에서 폭발적으로 인기를 끌었다 ;) 하지만 일반적으로 지금은 정말 인기가 많다는 데 동의한다. 나도 최근에 그것으로 전환했는데, 훨씬 더 빠르게 적응형 스타일을 작성할 수 있기 때문이다.
With styled-components I really enjoyed ability to write native css rules in a clean way, and it was very smooth learning curve compared to tailwind. I think styled-components might still be a good choice for critical, reusable UI parts, like UI Kit elements. Tailwind has some issues with extensibility, that's why projects like tw-merge exist, but it has it's downsides and limitations too. 스타일드 컴포넌트를 사용하면서 깔끔한 방식으로 네이티브 CSS 규칙을 작성할 수 있는 능력을 정말 즐겼고, Tailwind에 비해 학습 곡선이 매우 부드러웠습니다. 스타일드 컴포넌트는 UI 키트 요소와 같은 중요한 재사용 가능한 UI 부분에 여전히 좋은 선택이 될 수 있다고 생각합니다. Tailwind는 확장성에 몇 가지 문제가 있어 tw-merge와 같은 프로젝트가 존재하지만, 그것에도 단점과 한계가 있습니다.
wow, I'm glad I've not overlooked the email in my inbox with this post. 와우, 이 게시물과 함께 내 받은 편지함에서 이메일을 간과하지 않은 것에 기쁩니다. What can I say. CSS-in-JS made a massive change in React's world and FE development overall. And `styled-components` played a significant role in that change. 제가 뭐라고 말할 수 있을까요. CSS-in-JS는 React의 세계와 프론트엔드 개발 전반에 걸쳐 엄청난 변화를 가져왔습니다. 그리고 `styled-components`는 그 변화에서 중요한 역할을 했습니다.
Thank you for all your efforts and absolute transparency regarding path forward. 앞으로 나아갈 길에 대한 모든 노력과 완전한 투명성에 감사드립니다.
I like CSS-in-JS and your library. I even wrote my own implementation of styled-components inspired by your API https://github.com/atellmer/dark/tree/master/packages/styled 저는 CSS-in-JS와 당신의 라이브러리를 좋아합니다. 저는 당신의 API에서 영감을 받아 styled-components의 자체 구현을 작성하기도 했습니다 https://github.com/atellmer/dark/tree/master/packages/styled I wish you good luck. 행운을 빕니다.
We at digitec galaxus are still embracing CSS-in-JS - and we heavily used styled-components since the beginning of our new frontend stack ~7 years ago. Now we have developed our own open source solution called "next-yak", which can act almost as a drop-in replacement for styled-components: https://yak.js.org/
Oh! For me styled-components is the natural way to create web apps... It has been for years. I tried tailwind several times though... Should I learn all those classes to write css? And convince our designers to remake their mockups to fit tailwind styles? Okay, I will try... 오! 나에게 styled-components는 웹 앱을 만드는 자연스러운 방법이다... 수년간 그랬다. 하지만 tailwind를 여러 번 시도해봤다... CSS를 작성하기 위해 모든 클래스를 배워야 할까? 그리고 우리 디자이너들이 tailwind 스타일에 맞게 목업을 다시 만들도록 설득해야 할까? 알겠어, 시도해볼게...
My opinion from implementing and maintaining a design system for the last 3 years or so: I think it would be ideal for developers to not have to worry about styling at all. It was a goal of ours to enable developers to write frontend code without writing CSS. A design system (or a collection of components akin to a design system) would abstract this away from them. The components you build for the design system can use whatever styling solution you want. In my new project I opted for css-hooks which has been neat. 내가 지난 3년 동안 디자인 시스템을 구현하고 유지하면서 얻은 의견: 개발자들이 스타일링에 대해 전혀 걱정하지 않아도 되는 것이 이상적이라고 생각합니다. 우리는 개발자들이 CSS를 작성하지 않고도 프론트엔드 코드를 작성할 수 있도록 하는 것을 목표로 했습니다. 디자인 시스템(또는 디자인 시스템과 유사한 구성 요소 모음)은 이를 그들로부터 추상화할 것입니다. 디자인 시스템을 위해 구축하는 구성 요소는 원하는 스타일링 솔루션을 사용할 수 있습니다. 내 새로운 프로젝트에서는 css-hooks를 선택했는데, 매우 깔끔했습니다.
Regarding your point of "learning all the classes to write CSS", I don't think you need to learn them ahead of time, you can simply look up the docs when you need to find the Tailwind equivalent. (This is a downside of using Tailwind as opposed to css-hooks or something similar.) I believe there are IDE extensions for autocompleting Tailwind classes too. CSS 작성을 위해 모든 클래스를 배우는 것에 대한 귀하의 의견에 대해, 미리 배울 필요는 없다고 생각합니다. 필요할 때 Tailwind에 해당하는 내용을 찾기 위해 문서를 간단히 찾아보면 됩니다. (이것은 css-hooks나 유사한 것을 사용하는 것에 비해 Tailwind의 단점입니다.) Tailwind 클래스를 자동 완성하는 IDE 확장도 있다고 믿습니다.
Lastly regarding your point of "designers making mockups fit tailwind styles", I do not know why that would be at all the approach to take. Designers should make their mockups as they do (e.g. in Figma) and you figure out the Tailwind classes necessary to support it. If you are regularly writing custom CSS every time a new design comes through then you probably don't have a set of standardized components so there's not much of a time loss. You can customize Tailwind pretty extensively. 마지막으로 '디자이너가 Tailwind 스타일에 맞게 목업을 만드는 것'에 대한 귀하의 의견에 대해, 왜 그렇게 접근해야 하는지 모르겠습니다. 디자이너는 Figma와 같은 도구에서 목업을 만들고, 필요한 Tailwind 클래스를 찾아내야 합니다. 새로운 디자인이 들어올 때마다 매번 사용자 정의 CSS를 작성하고 있다면, 아마도 표준화된 구성 요소 세트가 없기 때문에 시간 손실이 크지 않을 것입니다. Tailwind는 상당히 광범위하게 사용자 정의할 수 있습니다.
In the product I am working on, we wrap our React application into Custom HTML Elements. We went all in with Styled-components because it's the only option out there that supports scoping the styles to our shadow roots properly. 제가 작업하고 있는 제품에서는 React 애플리케이션을 사용자 정의 HTML 요소로 감싸고 있습니다. 우리는 스타일을 그림자 루트에 적절하게 범위 지정할 수 있는 유일한 옵션인 Styled-components에 전적으로 의존했습니다. So sad this has to go. Styled-components was my favorite option out there. Tailwind like options don't work properly in my context. Any suggestion of alternative? 이렇게 가야 한다니 너무 슬픕니다. Styled-components는 제가 좋아하는 옵션이었습니다. Tailwind와 같은 옵션은 제 상황에서 제대로 작동하지 않습니다. 대안에 대한 제안이 있나요?
Yes, @sebastien-belzile we have the alternative - also open source: https://yak.js.org/ 네, @sebastien-belzile 우리는 대안이 있습니다 - 또한 오픈 소스: https://yak.js.org/ Would be great to see more people trying it out, it is basically styled-components but in build-time and on steroids (it's done with SWC and Rust) 더 많은 사람들이 시도해보는 것을 보는 것이 좋습니다. 기본적으로 스타일드 컴포넌트와 비슷하지만 빌드 타임에 스테로이드가 추가된 것입니다 (SWC와 Rust로 만들어졌습니다)
I just started using https://www.restyle.dev. Love it! It's only 5kb, and very similar API to styled-components... Afaik doesn't use React Context either, and works very smoothly for SSR. 저는 https://www.restyle.dev를 사용하기 시작했습니다. 정말 마음에 들어요! 크기가 5kb에 불과하고 styled-components와 매우 유사한 API를 가지고 있습니다... 제가 아는 한 React Context를 사용하지도 않고, SSR에 대해 매우 부드럽게 작동합니다.
I think it needs to be heard around, thus I share here. 이 이야기가 널리 퍼져야 한다고 생각해서 여기 공유합니다.
I really enjoyed how styled-component made abstract projects for me and too pity it’s discontinued. I think alternative approaches make sense for developers. styled-component가 저를 위해 추상 프로젝트를 만들어 준 것이 정말 즐거웠고, 중단된 것이 너무 아쉽습니다. 대안적인 접근 방식이 개발자에게 의미가 있다고 생각합니다.
What is your news source for this item? Would this change also effect a CSS-in-JS solution like Emotion? 이 항목에 대한 뉴스 출처는 무엇인가요? 이 변경이 Emotion과 같은 CSS-in-JS 솔루션에도 영향을 미칠까요? > The React core team has decided to defacto-deprecate certain APIs like the Context API (not available in RSC with no migration path.) > 리액트 핵심 팀은 Context API와 같은 특정 API를 사실상 사용 중단하기로 결정했습니다(마이그레이션 경로가 없는 RSC에서는 사용할 수 없습니다.)
