Thanks for sharing — seems like a good effort to address component styling. It is just a beginning of my acquaintance with this library, but there are several things that it encourages that I think are bad for the code. React Imagine you have this Home Panel module: <!–– html ––><div class='home-panel'><div class='header'><div class='header-main'><h1>Here is a home panel</h1><p>Welcome to this example!</p></div><div class='header-aside'><button>Read more</button><span>Some help text</span></div></div><div class='content'><div class='content-section'><!–– some content ––></div><div class='content-section'><!–– some content ––></div></div><div class='footer'><!–– some content ––></div></div> , , , , and classes all have some kind of css that gives them positioning and perhaps color and border. header header-main header-aside content content-section footer Our Home Panel css code may be reusable, and smaller components like Main Button and Hint can also be reusable, but the other divs can’t be reused separately from their usage in Home Panel. Normally I would write this React component in the following way (just giving classes to everything): export default class HomePanel extends React.Component {render() {return (<div className='home-panel'><div className='header'><div className='header-main'><h1>Here is a home panel</h1><p>Welcome to this example!</p></div><div className='header-aside'><button className='main'>Read more</button><span className='hint'>Some help text</span></div></div><div className='content'><div className='content-section'>{ 'some content' }</div><div className='content-section'>{ 'some content' }</div></div><div className='footer'>{ 'some content' }</div></div>)}} Styled Components way is to create components. So, the above code can look like this: export default class HomePanel extends React.Component {render() {return (<HomePanel><HomePanelHeader><HomePanelHeaderMain><HomePanelTitle>Here is a home panel</HomePanelTitle><HomePanelSubtitle>Welcome to this example!</HomePanelSubtitle></HomePanelHeaderMain><HomePanelHeaderAside><MainButton>Read more</MainButton><Hint>Some help text</Hint></HomePanelHeaderAside></HomePanelHeader><HomePanelContent><HomePanelContentSection>{ 'some content' }</HomePanelContentSection><HomePanelContentSection>{ 'some content' }</HomePanelContentSection></HomePanelContent><HomePanelFooter>{ 'some content' }</HomePanelFooter></HomePanel>)}} It look like like that, but I get it that you probably won’t ‘componentize’ each div that has styling and will reserve Styled Components for smaller reusable things like inputs, buttons, etc. could If you did ‘componentize’ each div like the above, that would quickly become a huge overhead. Also, the inner divs are not separately reusable, so you don’t win much by extracting them in components. So, let’s say you make components where it makes sense, and use classes otherwise. What we end up with is code that contains both classes Styled Components. Which leads us to the first problem: and 1. Your css code is now in two places — css assets and javascript assets. What this means: Debugging CSS is harder Maintaining CSS is harder Second problem is the reason I cannot use this library at my company. It is common to use more than one front-end framework within an app. It is also common to have html templates and React code both used within one app: 2. Styled Components depend on React implementation. CSS defined there is not reusable outside of your React code. What this means: Adds coupling between styles and markup implementation Doesn’t make sense if React is just a part of your overall app But more importantly, it your css code to React. If 3 months from now, you want to launch a new page using an html template, you’ll have the overhead of re-implementing that you thought was already there. ties CSS Styled Components library certainly may have some good uses, and it is great to see a different approach, but it is bad for separation of concerns and increases potential maintenance overhead. is better than , but this is probably not the one I would recommend. A pattern no pattern is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories