What is styled-components and what are its top alternatives?
Top Alternatives to styled-components
Emotion
Emotion is a performant and flexible CSS-in-JS library. Building on many other CSS-in-JS libraries, it allows you to style apps quickly with string or object styles. It has predictable composition to avoid specificity issues with CSS. With source maps and labels, Emotion has a great developer experience and great performance with heavy caching in production. ...
CSS Modules
It is a CSS file in which all class names and animation names are scoped locally by default. The key words here are scoped locally. With this, your CSS class names become similar to local variables in JavaScript. It goes into the compiler, and CSS comes out the other side. ...
CSS Blocks
By combining an opinionated authoring system, build-time analysis and rewriting of templates, and a new type of CSS optimizer, css-blocks breathes new power and ease of use into the technologies and best practices that stylesheet developers already know and love. ...
Radium
Radium is a set of tools to manage inline styles on React elements. It gives you powerful styling capabilities without CSS. ...
Ant Design
An enterprise-class UI design language and React-based implementation. Graceful UI components out of the box, base on React Component. A npm + webpack + babel + dora + dva development framework. ...
Sass
Sass is an extension of CSS3, adding nested rules, variables, mixins, selector inheritance, and more. It's translated to well-formatted, standard CSS using the command line tool or a web-framework plugin. ...
Material-UI
It is a comprehensive guide for visual, motion, and interaction design across platforms and devices. ...
PostCSS
PostCSS is a tool for transforming CSS with JS plugins. These plugins can support variables and mixins, transpile future CSS syntax, inline images, and more. ...
styled-components alternatives & related posts
- Easy to use2
related Emotion posts
We are in the process of adopting Next.js as our React framework and using Storybook to help build our React components in isolation. This new part of our frontend is written in TypeScript, and we use Emotion for CSS/styling. For delivering data, we use GraphQL and Apollo. Jest, Percy, and Cypress are used for testing.
For Stack Decisions I needed to add Markdown in the decision composer to give our users access to some general styling when writing their decisions. We used React & GraphQL on the #Frontend and Ruby & GraphQL on the backend.
Instead of using Showdown or another tool, We decided to parse the Markdown on the backend so we had more control over what we wanted to render in Markdown because we didn't want to enable all Markdown options, we also wanted to limit any malicious code or images to be embedded into the decisions and Markdown was a fairly large to import into our component so it was going to add a lot of kilobytes that we didn't need.
We also needed to style how the markdown looked, we are currently using Glamorous so I used that but we are planning to update this to Emotion at some stage as it has a fairly easy upgrade path rather than switching over to styled-components or one of the other cssInJs alternatives.
Also we used React-Mentions for tagging tools and topics in the decisions. Typing @ will let you tag a tool, and typing # will allow you to tag a topic.
The Markdown options that we chose to support are tags: a, code, u, b, em, pre, ul, ol, li.
If there are anymore tags you'd love to see added in the composer leave me a comment below and we will look into adding them.
#StackDecisionsLaunch
CSS Modules
- Static rather than compiled at runtime1
related CSS Modules posts
related CSS Blocks posts
related Radium posts
- Lots of components30
- Polished and enterprisey look and feel24
- Easy to integrate15
- Es6 support14
- TypeScript14
- Beautiful and solid13
- Quick Release rhythm12
- Beautifully Animated Components9
- Great documentation9
- Typescript support9
- Short Code6
- Less12
- Large File Size6
- Close5
- Poor accessibility support1
related Ant Design posts
Hi there!
I just want to have a simple poll/vote...
If you guys need a UI/Component Library for React, Vue.js, or AngularJS, which type of library would you prefer between:
1 ) A single maintained cross-framework library that is 100% compatible and can be integrated with any popular framework like Vue, React, Angular 2, Svelte, etc.
2) A native framework-specific library developed to work only on target framework like ElementUI for Vue, Ant Design for React.
Your advice would help a lot! Thanks in advance :)
Hi, I start building an admin dashboard with next.js and looking for a frontend framework ( components ready ). So I end up with Ant Design and Material-UI, but I never built a project with these two.
Here is a list of my requirements.
- Good documentation.
- easy CRUD ( date picker and date range picker bundled )
- built-in multi-lang feature or Great 3rd library support
- Admin dashboard template
- well code maintenance
Which is better for the long run?
- Variables603
- Mixins586
- Nested rules464
- Maintainable411
- Functions296
- Modular flexible code148
- Open source140
- Selector inheritance110
- Dynamic106
- Better than cs95
- Used by Bootstrap3
- If and for function2
- Custom functions1
- Better than less1
related Sass posts
React
GraphQL
Apollo
JavaScript
TypeScript
Webpack
React Helmet
styled-components
Sass
Less
PostCSS
Bootstrap
Semantic UI
Foundation
React Router
KoaReactQL is a React + GraphQL front-end starter kit. #JSX is a natural way to think about building UI, and it renders to pure #HTML in the browser and on the server, making it trivial to build server-rendered Single Page Apps. GraphQL via Apollo was chosen for the data layer; #GraphQL makes it simple to request just the data your app needs, and #Apollo takes care of communicating with your API (written in any language; doesn't have to be JavaScript!), caching, and rendering to #React.
ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.
React Helmet was chosen to handle <head> content, because it works universally, making it easy to throw back the correct <title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.
styled-components, Sass, Less and PostCSS were added to give developers a choice of whether to build styles purely in React / JavaScript, or whether to defer to a #css #preprocessor. This is especially useful for interop with UI frameworks like Bootstrap, Semantic UI, Foundation, etc - ReactQL lets you mix and match #css and renders to both a static .css file during bundling as well as generates per-page <style> tags when using #StyledComponents.
React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.
Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.
Which #GridFramework to use? My team and I closed on Bootstrap !
On a related note and as far as stylesheets go, we had to chose between #CSS, #SCSS, #Sass , Less Finally opted for Sass
As syntactically awesome as the name announces it.
- React99
- Material Design67
- Ui components42
- CSS framework22
- Component16
- Looks great10
- LESS9
- Responsive9
- Open source6
- Good documentation6
- Code examples5
- Flexible5
- Ui component4
- JSS4
- Angular3
- Very accessible3
- Designed for Server Side Rendering2
- LADO2
- Supports old browsers out of the box2
- Fun2
- Interface1
- Asdasd1
- Easy to work with1
- 5550
- Hard to learn. Bad documentation22
- Hard to customize20
- Hard to understand Docs15
- For editable table component need to use material-table4
- Long Code4
- Bad performance4
- Extra library needed for date/time pickers4
related Material-UI posts
I picked up an idea to develop and it was no brainer I had to go with React for the frontend. I was faced with challenges when it came to what component framework to use. I had worked extensively with Material-UI but I needed something different that would offer me wider range of well customized components (I became pretty slow at styling). I brought in Evergreen after several sampling and reads online but again, after several prototype development against Evergreen鈥攕ince I was using TypeScript and I had to import custom Type, it felt exhaustive. After I validated Evergreen with the designs of the idea I was developing, I also noticed I might have to do a lot of styling. I later stumbled on Material Kit, the one specifically made for React . It was promising with beautifully crafted components, most of which fits into the designs pages I had on ground.
A major problem of Material Kit for me is it isn't written in TypeScript and there isn't any plans to support its TypeScript version. I rolled up my sleeve and started converting their components to TypeScript and if you'll ask me, I am still on it.
In summary, I used the Create React App with TypeScript support and I am spending some time converting Material Kit to TypeScript before I start developing against it. All of these components are going to be hosted on Bit.
If you feel I am crazy or I have gotten something wrong, I'll be willing to listen to your opinion. Also, if you want to have a share of whatever TypeScript version of Material Kit I end up coming up with, let me know.
Hi, I start building an admin dashboard with next.js and looking for a frontend framework ( components ready ). So I end up with Ant Design and Material-UI, but I never built a project with these two.
Here is a list of my requirements.
- Good documentation.
- easy CRUD ( date picker and date range picker bundled )
- built-in multi-lang feature or Great 3rd library support
- Admin dashboard template
- well code maintenance
Which is better for the long run?
- The "babel" of CSS20
- Customizable15
- Autoprefixer8
- Variables2
- PostCSS Flexbugs Fixes1
- 01
- Mixins1
- CSS MQPacker1
related PostCSS posts
ReactGraphQLApolloJavaScriptTypeScriptWebpackReact Helmetstyled-componentsSassLessPostCSSBootstrapSemantic UIFoundationReact RouterKoaReactQL is a React + GraphQL front-end starter kit. #JSX is a natural way to think about building UI, and it renders to pure #HTML in the browser and on the server, making it trivial to build server-rendered Single Page Apps. GraphQL via Apollo was chosen for the data layer; #GraphQL makes it simple to request just the data your app needs, and #Apollo takes care of communicating with your API (written in any language; doesn't have to be JavaScript!), caching, and rendering to #React.
ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.
React Helmet was chosen to handle <head> content, because it works universally, making it easy to throw back the correct <title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.
styled-components, Sass, Less and PostCSS were added to give developers a choice of whether to build styles purely in React / JavaScript, or whether to defer to a #css #preprocessor. This is especially useful for interop with UI frameworks like Bootstrap, Semantic UI, Foundation, etc - ReactQL lets you mix and match #css and renders to both a static .css file during bundling as well as generates per-page <style> tags when using #StyledComponents.
React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.
Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.
Originally, I was going to start using Sass with Parcel, but then I learned about Stylus, which looked interesting because it can get the property values of something directly instead of through variables, and PostCSS, which looked interesting because you can customize your Pre/Post-processing. Which tool would you recommend?