CSS Blocks vs styled-components: What are the differences?
Developers describe CSS Blocks as "A component-oriented CSS authoring system by LinkedIn". 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. On the other hand, styled-components is detailed as "Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress". Visual primitives for the component age. Use the best bits of ES6 and CSS to style your apps without stress 💅.
CSS Blocks and styled-components are both open source tools. It seems that styled-components with 24.7K GitHub stars and 1.46K forks on GitHub has more adoption than CSS Blocks with 6.07K GitHub stars and 141 GitHub forks.
What is CSS Blocks?
What is styled-components?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose CSS Blocks?
What are the cons of using CSS Blocks?
What are the cons of using styled-components?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
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.
<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.
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:
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.
For styling components, styled-components work great (really!)
You don’t have to use it for everything. You can still use good old CSS classes along with your styled components.
What I do generally is to separate the “layout”, “typography”, “vertical rhythm”, and “reset” to good old CSS, and style the rest of the app with styled components.