NotificationsYou must be signed in to change notification settings
Fork24
Star860

A thorough analysis of all the current CSS-in-JS solutions with SSR & TypeScript support for Next.js

860 stars 24 forks Branches Tags Activity

You must be signed in to change notification settings

Folders and files

Name		Name	Last commit message	Last commit date
Latest commit History 337 Commits
.yarn/releases		.yarn/releases
components/demo		components/demo
pages		pages
public		public
styles		styles
.gitattributes		.gitattributes
.gitignore		.gitignore
.yarnrc		.yarnrc
README.md		README.md
next-env.d.ts		next-env.d.ts
package.json		package.json
tsconfig.json		tsconfig.json
yarn.lock		yarn.lock

Repository files navigation

A thorough analysis of CSS-in-TS

This document contains an in-depth analysis of all the currentCSS-in-JS solutions, that supportServer Side Rendering andTypeScript.

The baseline reference we'll use for comparison is aCSS Modules approach.
We're usingNext.js as a SSR framework for building resources.
Last important aspect is type-safety with fullTypeScript support.

🗓Last update:Aug 2021

🗞 To get a shorter overview, you can checkout thearticle on CSS Tricks:
https://css-tricks.com/a-thorough-analysis-of-css-in-js/

📽 If you prefer a video instead, you can checkout mytalk from ngPartyCZ:
https://www.youtube.com/watch?v=c7uWGhrAx9A

✋ Please checkout ourgoals &disclaimer before jumping to conclusions.

Motivation

TheCSS language andCSS Modules have some limitations, especially if we want to have type-safe code. Some of these limitations have alterative solutions, others are just beingannoying orless than ideal:

Styles cannot be co-located with components
This can be frustrating when authoring many small components, but it's not a deal breaker. However, the experience of moving back-and-forth between thecomponent.js file and thecomponent.css file, searching for a given class name, and not being able to easily"go to style definition", is an important productivity drawback.
Styling pseudos and media queries requires selector duplication
Another frustrating fact is the need to duplicate our CSS classes when definingpseudo classes and elements, ormedia queries. We can overcome these limitations using a CSS preprocessor likeSASS, LESS or Stylus, that supports the& parent selector, enablingcontextual styling.
```
.button {}/* duplicated selector declaration for pseudo classes/elements */.button:hover {}.button::after {}@media (min-width:640px) {/* duplicated selector declaration inside media queries */  .button {}}
```
Styles usage is disconnected from their definition
We get no IntelliSense with CSS Modules, of what CSS classes are defined in thecomponent.css file, makingcopy-paste a required tool, lowering the DX. It also makesrefactoring very cumbersome, because of the lack of safety.
Using type-safe design tokens in CSS is non-trivial
Anydesign tokens defined in JS/TS (to benefit from type-safety) cannot be directly used in CSS.
There are at least 2 workarounds for this issue, neither of them being elegant:
- We could inject them asCSS Custom Properties / Variables, but we still don't get any IntelliSense or type-safety when using them in.module.css.
- We could useinline styles, which is less performant, and it also introduces a different way to write styles (camelCase vs. kebab-case), while also splitting the styling in 2 different places: the component file and the.css file.
- We could use CSS (or SASS) as the source of truth for design tokens, by storing them as CSS Custom Properties and read them from JS using DOM queries, but we'd still need to manually update both the CSS and JS code when we perform any change, because we don't have type-safety when dealing with CSS;

Goals

There are specific goals we're looking for with this analysis:

🥇 SSR support and easy integration with Next.js
🥇 full TypeScript support
🥇 great DX with code completion & syntax highlight
🥈 light-weight
🥈 comprehensive documentation
🥉 intuitive API and low learning curve

Getting even more specific, we wanted to experience the usage of various CSS-in-JS solutions regarding:

definingglobal styles
usingmedia queries &pseudo classes
dynamic styles based on componentprops (aka. component variants), or from user input
bundle size impact

Disclaimer

This analysis is intended to beobjective andunopinionated:

I have not built my own CSS-in-JS library.
I don't work on any of the libraries reviewed here.
I haveno intention or motivation forpromoting ortrashing either of them.
I haveno prior experience with any CSS-in-JS solution, so I'mnot biased towards any of them.
I haveequally used all the solutions analyzed here, which also means I haveno extensive experience with any of them. So, you can safely sayI'm a jack of all~~trades~~ CSS-in-JS libraries, but master of none.

👎What you WON'T FIND here?

which solution is"the best", as I'll not add any grading, which would also be highly subjective;
which solution is"the fastest", as I'm not concearned about rendering performance metrics (you can checkoutNecholas's benchmarks for this);

👍What you WILL FIND here?

an overview of (almost) all CSS-in-JS solutions available at this date (seelast update on top) that we've tried to integrate into aNext.js v11 + TypeScript empty project, withminimal effort;
a limited set ofquantitative metrics that allowed us to evaluate these solutions, which might help you as well;
an additional list ofqualitative personal observations, which might be either minor details or deal-breakers when choosing a particular solution.

The libraries are not presented in any particular order. If you're interested in a briefhistory of CSS-in-JS, you should checkout thePast, Present, and Future of CSS-in-JS insightful talk by Max Stoiber.

Overview

	1. Co‑location	2. DX	3. tag` `	4. `{ }`	5. TS	6. `&` ctx	7. Nesting	8. Theme	9. `.css`	10. `<style>`	11. Atomic	12. `className`	13. `<Styled />`	14. `css` prop	15. Agnostic	16. Page size delta
CSS Modules	❌	✅	✅	❌	❌	❌	✅	❌	✅	❌	❌	✅	❌	❌	✅	-
Styled JSX	✅	🟠	✅	❌	🟠	❌	✅	❌	❌	✅	❌	✅	❌	❌	❌	`+2.8 kB / +12.0 kB`
Styled Components	✅	🟠	✅	✅	✅	✅	✅	✅	❌	✅	❌	❌	✅	✅	❌	`+13.4 kB / +39.0 kB`
Emotion	✅	✅	✅	✅	✅	✅	✅	✅	❌	✅	❌	✅	✅	✅	✅	`+6.5 kB / +20.0 kB`
TypeStyle	✅	✅	❌	✅	✅	✅	✅	🟠	❌	✅	❌	✅	❌	❌	✅	`+2.1 kB / +8.0 kB`
Fela	✅	🟠	🟠	✅	🟠	✅	✅	✅	❌	✅	✅	✅	❌	❌	✅	`+11.9 kB / +43.0 kB`
Stitches	✅	✅	❌	✅	✅	✅	✅	✅	❌	✅	❌	✅	✅	🟠	✅	`+5.3 kB / +17.0 kB`
JSS	✅	✅	🟠	✅	✅	✅	✅	✅	❌	✅	❌	✅	🟠	❌	✅	`+18.2 kB / +60.0 kB`
Goober	✅	✅	✅	✅	✅	✅	✅	✅	❌	✅	❌	✅	✅	🟠	✅	`+1.1 kB / +4.0 kB`
Compiled	✅	✅	✅	✅	✅	✅	✅	❌	❌	✅	✅	🟠	✅	✅	❌	`+3.5 kB / +9.0 kB`
Linaria	✅	✅	✅	❌	✅	✅	✅	✅	✅	❌	❌	✅	✅	❌	✅	`+2.7 kB / +6.0 kB`
vanilla-extract	❌	✅	❌	✅	✅	✅	❌	✅	✅	❌	🟠	✅	❌	❌	✅	`+0.0 kB / -2.0 kB`

LEGEND:

✅ - full & out-of-the-box support
🟠 - partial or limited support, less than ideal, or requiring some additional manual work for full support
❌ - lack of support

1. Co-location

The ability to define styles within the same file as the component. Note that we can also extract the styles into a separate file and import them, in case we prefer it.

⬆️ to overview

2. DX

Refers to theDeveloper eXperience which includes 2 main aspects:

syntax highlighting for styles definition;
code-completion/suggestions for supported CSS Properties and available values (we're evaluating only the suggestion feature, not type-safety);

⬆️ to overview

3.tag` ` (Tagged Templates)

Support for definingstyles as strings, using ES Tagged Templates:

useskebab-case for property names, just like plain CSS syntax;
enables easier migration from plain CSS to CSS-in-JS, because we don't have to completely re-write the styles;
requires installing additional code editor plugin(s) forsyntax highlight and code completion, otherwise our code would look like a plainstring;
requires an additional step to parse the string and convert it to JS, which can be done either at built time (slower builds), or at runtime (slightly larger payload);

⬆️ to overview

4.`{ }` (Object Styles)

Support for definingstyles as objects, using plain JavaScript objects:

usescamelCase for property names, like we would do inReact Native;
migrating existing CSS requires a complete rewrite (don't know how we could automate this);
we don't need additional tooling for syntax highlighting, as we get it out-of-the-box, by writting JS objects;
without proper TS definitions shipped with the library, we won't get code completion (☝️ we're only interested in TS, not Flow);

⬆️ to overview

5. TS

TypeScript support, either built-in, or via@types package, which should include:

typings for the library API;
Style Object typings (in case the library supports the object syntax);
Props generics, where applicable (get type-safe access to component props types when defining dynamic styles);

⬆️ to overview

6.`&` ctx (Contextual Styles)

Support forcontextual styles allowing us to easily definepseudo classes & elements andmedia queries without the need to repeat the selector, as required in plain CSS:

can either support the SASS/LESS/Stylus& parent selector;
or provide any specific API or syntax to achieve the same result;

⬆️ to overview

7. Nesting

Support forarbitrary nested selectors:

this feature allows for great flexibility, which might be useful, or required in some specific use-cases;
to keep in mind that it also introduces too many ways of defining styles, which might cause chaos if we want to enforce good-practices, scalability and maintainability;

⬆️ to overview

8. Theming

Built-in support for Theming or managing tokens for a design system.
Wehaven't tested out this feature, so we're only taking notes which libraries express their support in their docs.

⬆️ to overview

9.`.css` (Static CSS extraction)

Defined styles are extracted as static.css files:

it reduces the total bundle/page size, because we don't need additional runtime library, for injecting and evaluating the styles;
this approachaffectsFCP/FMP metrics negatively when users have an empty cache, and positively when having full cache;
dynamic styling could potentially increase the generated file, because all style combinations must be pre-generated at built time;
more suitable for less interactive solutions, where we serve a lot of different pages and we want to take advantage of cached styles (ie: e-commerce, blogs);

⬆️ to overview

10.`<style>` tag

Defined styles are injected inside<style> tags in the document's<head>:

makes dynamic styling super easy;
incurs larger payload, because we're also shipping a runtime library to handle dynamic styles;
when using SSR, styles required for the initial render are shipped twice to the client: once during SSR, and again duringhydration;
more suited for highly dynamic and interactive (single page) applications;

⬆️ to overview

11. Atomic CSS

The ability to generateatomic css classes, thus increasing style reusability, and reducing duplication:

this generates a separate CSS class for each CSS property;
we'll get larger HTML files, because each element will contain a larger number of CSS classes applied;
theoreticallyatomic CSS-in-JS reduces the scaling factor of our styles,Facebook is doing it as well;
it's debatable if the CSS total size reduction, is greater than the HTML size increase (what is the final delta)
theoretically, if the class names are shorter than the CSS property definition, the delta is positive so we're shipping less bytes (also depends a lot on compression, so not easy to draw a definite conclusion);
however, we're basically moving part of bytes from CSS to HTML, which might be harder to cache if we have dynamic SSRed pages;
also, depends a lot on what changes more frequently: the styles? or the markup?

⬆️ to overview

12.`className`

The library API returns astring which we have to add to our component or element;

this is similar how we would normally style React components, so it's easy to adopt because we don't have to learn a new way of dealing with styles;
to combine styles we have to use string concatenation;

⬆️ to overview

13.`<Styled />`

The API creates a wrapper (orStyled) component which includes the generatedclassName(s):

this technique was first introduced and popularized byStyled Components, hence the name;
we'll have to learn a new way to define styles, because we're not applying styles to elements, instead we're creating new components that include the styled elements;
this also introduces a bit of indiretion when figuring out what native elements gets rendered inside a larger component;
we end up creating components likeStyledButton orStyledList instead of constants likebutton_styles orlist_styles, so regarding naming it's pretty much the same thing;
since the styles/class names are not re-used (we re-use the entire component), it makes sense to encapsulate the styles within the component and not think about 2 different aspects of the same entity;
it's not React specific, can also be used withVue;

⬆️ to overview

14.`css` prop

Allows passing styles using a specialcss prop, similar how we would define inline styles, but the library generates a unique CSS class name behind the scenes:

it's a convenient and ergonomic API;
this technique was popularized byEmotion v10;
it's seems to be available only for React/JSX-based syntax

⬆️ to overview

15. Framework agnostic

Allows usage without, or with any framework. Some libraries are built specifically for React only.
NOTE: some libraries likeStitches orEmotion document only React usage, although they have acore that's framework agnostic.

⬆️ to overview

16. Page size delta

The total page size difference in kB (transferred gzipped & minified / uncompressed & minified) compared toCSS Modules, for the entire index page production build using Next.js:

keep in mind that this includes an almostempty page, with only a couple of components;
this is great for evaluating the minimal overhead, but does NOT offer any insight on the scaling factor: logarithmic, linear, or exponential;

NOTE: all builds were done with Next.js11.1.0 and the values are taken from Chrome Devtools Network tab,Transferred over network vs Resource size.

⬆️ to overview

Overall observations

The following observations apply for all solutions (with minor pointed exceptions).

✅ Code splitting

Components used only in a specific route will only be bundled for that route. This is something that Next.js performs out-of-the-box.

✅ Global styles

All solutions offer a way to define global styles, some with a dedicated API.

Compiled is the only library that doesn't have a dedicated API for global styles at the moment, but it isplanned

✅ SSR

All solutions offer Server-Side Rendering support and are easy to integrate with Next.js.

✅ Vendor prefixes

All solutions automatically add vendor specific prefixes out-of-the-box.

vanilla-extract is the only library that requiresmanual setup

✅ Unique class names

All solutions generate unique class names, like CSS Modules do. The algorithm used to generate these names varies a lot between libraries:

some libraries use ahashing algorithm, requiring more computing, but resulting in idempotent names (for example:.heading style fromCard component will always have the.Card_heading_h7Ys5 hash);
other libraries usecounting, basically incrementing either a number (.heading-0-2-1,.input-0-2-2), or the alphabet letters (a, b, c, ... aa, ab, ac, etc), making this approach more performant, but resulting in non-idempotent class names (can't figure out if this has any potential drawbacks or not);

✅ No inline styles

None of the solutions generate inline styles, which is an older approach, used by Radium & Glamor. The approach isless performant than CSS classes, and it'snot recommended as a primary method for defining styles. It also implies using JS event handlers to trigger pseudo classes, as inline styles do not support them. Apparently, all modern solutions nowadays moved away from this approach.

✅ Full CSS support

All solutions support most CSS properties that you would need:pseudo classes & elements,media queries andkeyframes are the ones that we've tested.

✅ Critical CSS extraction

Most solutions market themselves as being able to"extract critical CSS" during SSR. Please note that this doesNOT refer toabove-the-fold critical CSS extraction, as we initially thought.

What they actually do:

during SSR, they only generate styles for thevisible elements of the static rendered page;
they don't inject CSS for elements that are dynamically rendered, or lazy loaded;

With 100% static CSS, there would be actually no benefit. With dynamic pages that render very few elements on the server, and most components are rendered dynamically on the client, the benefit increases.

EXCEPTION: libraries that usestatic CSS extraction.

🟠 Performance Metrics

Understanding how these features affectCore Web Vitals andPerformance Metrics in general is an extremely important factor to consider, and the way styles are delivered to the client has probably the biggest impact, so let's analyse this in detail.

Also, there are 2 different scenarios we need to consider:

📭Empty cache: the user visits our page for the first time, or a returning user visits our page after the cache was invalidated (a new version was released);
📬Full cache: a returning user visits our page, and has all static resources cached (.js,.css, media, etc);

1.`.css` file extraction

Solutions that generate.css static files, which you normally would include as<link> tag(s) in the<head> of your page, are basicallyrendering-blocking resources. This highly affectsFCP,LCP and any other metric that follows.

📭Empty cache
If the user has an empty cache, the following needs to happen,negatively impactingFCP andLCP:

the browser needs to make an additional request, which implies a fullRTT (Round Trip Time) to our server;
transfer all CSS file content;
parse it and build the CSSOM;
these will delay any rendering of the<body>, even if the entire HTML is already loaded, and it may even be eagerly parsed, and some resources already fetched in advance;

It's true that you can fetch inparallel other<head> resources (additional.css or.js files), but this is generally a bad practice;

📬Full cache
However, on subsequent visits, the entire.css resource would be cached, soFCP andLCP would be positively impacted.

💡Key points
This solution appears to be better suited when:

we have many Server Side Rendered pages that our users visit, maybe even containing a common.css file that can be cached when visiting other pages;
we don't update the styles frequently, so they can be cached for longer periods of time;
we want to optimize for returning visitors, affecting first-time visits instead;

2.`<style>` tag injected styles

DuringSSR, styles will be added as<style> tag(s) in the<head> of the page. Keep in mind that these usually do NOT include all styles needed for the page, because most libraries performCritical CSS extraction, so thesestyles should be usually smaller than the entire.css static file discussed previously.

📭Empty cache
Because we're shipping less CSS bytes, and they are inlined inside the.html file, this would result in fasterFCP andLCP:

we don't need additional requests for.css files, so the browser is not blocked;
if we move all other.js files requests to the end of the document,<head> won't do any requests, so rendering will occur super fast;
however, eventually we would ship additional bytes, that were not needed with static.css extraction:
- the runtime library (between 1.6kB - 20kB);
- the styles required for the page, bundled in.js files along with the components, duringhydration (this includes all the critical CSS already shipped inside the<style> tag + others);
all these files are required to be fetched, parsed and executed to get afully interactive page;

📬Full cache
When the user's cache is full, the additional.js files won't require fetching, as they are already cached.
However, if the page isSSRed, the inlined critical CSS rendered in the<style> tag of the document will be downloaded again, unless we deal with static HTML that can be cached as well, or we deal with HTML caching on our infrastructure.

But, by default, we will ship extra bytes on every page HTTP request, regardless if it's cached or not.

💡Key points
This solution appears to be better suited when:

we deal with SPA (Single Page Applications), where we have one (or few) SSR pages;
we update the styles frequently, so even if they could be cached, it won't have a positive impact;
we want to optimize for first-time visitors, affecting returning visitors instead;

🟠 Dead code removal

Most solutions say theyremove unused code/styles. This is onlyhalf-true.

Unused code is indeed more difficult to accumulate, especially if you compare it to plain.css files as we used to writea decade ago. But when compared to CSS Modules, the differencies are not that big. Any solution that offers the option to definearbitrary selectors ornested styles will bundle them, regardless if they are used or not inside our component. We've managed to ship unused SSR styles with all the tested solutions.

True & full unused code removal is difficult to implement, as the CSS syntax is not type-checked, nor statically analyzable. Also, the dynamic nature of components make it practically impossible in certain scenarios, especially when the markup is dynamically rendered:

& span: descendant elements;
&:nth-child(): certain pseudo selectors;
& .bg-${color}: dynamic selectors;
.parent &: parent selectors;

Basically, what we get is code removal when we delete the component, or we don't import it anymore. That's implicit behaviour, because the styles are a direct dependency of the component. When the component is gone, so are its styles.

🟠 Debugging / Inspecting

There are 2 methods to inject CSS into the DOM & update it from #"auto">

1. Using`<style>` tag(s)

This approach implies adding one or more<style> tag(s) in the DOM (either in the<head> or somewhere in the<body>), using.appendChild() to add the<style> Node(s), in addition with either.textContent,.innerHTML to update the<style> tag(s).

using this approach, we can easilysee what styles get added to the DOM, because we can inspect the DOM from our DevTools, like any other DOM Node;
using only one<style> tag and updating its whole content, could be slow to update the entire DOM when we actually changed only a tiny set of CSS rule(s);
most libraries use this solution inDEVELOPMENT mode, because it provides a better debugging experience;
- TypeStyle uses this inPRODUCTION also;

2. Using`CSSStyleSheet` API

First used byJSS, this method usesCSSStyleSheet.insertRule() to inject CSS rules directly into theCSSOM.

using this approach it's a bit more difficult tosee what styles get injected into the CSSOM, because even if you see the CSS applied on the elements (thanks toCSS-in-JS support in Chrome) it will point to an empty<style> tag;
- to see all the injected styles, you'll have to select the<style> tag;
- get access to it via$0 in Chrome DevTools (or get a reference to it in any other way, using the DOM API);
- access.sheet.cssRules on the<style> tag to see the Array of CSS rules that it contains;
this method is apparently more performant than the previous one, during dynamic styles update, so most libraries use this method inPRODUCTION;
- performance gains apply only when adding new CSS rules, or updating existing ones (ie: dynamic styles update at runtime);
- JSS andStitches use it inDEVELOPMENT mode as well;

❌ No component deduping

If the same component is imported by 2 different routes, it will be send twice to the client. This is surely a limitation of the bundler/build system, in our case Next.js, andnot related to the CSS-in-JS solution.

In Next.js, code-splitting works at the route level, bundling all components required for a specific route, but according to theirofficial blog andweb.dev if a component is used inmore than 50% of the pages, it should be included in thecommons bundle. However, in our example, we have 2 pages, each of them importing theButton component, and it's included in each page bundle, not in thecommons bundle. Since the code required for styling is bundled with the component, this limitation will impact the styles as well, so it's worth keeping this in mind.

CSS Modules

This is a well established, mature and solid approach. Without a doubt, it's a great improvement over BEM, SMACCS, OOCSS, or any other scalable CSS methodology to structure and organize our CSS, especially in component-based applications.

Launched in2015 |Back to Overview

✅Context-aware code completion
✅Framework agnostic
❌No Styles/Component co-location
❌No TypeScript support
❌No Atomic CSS
❌No Theming support
Styles definition method(s)
- ✅ plain CSS
- ❌ Style Objects
Styles nesting
- ❌ Contextual styles:(requires SASS, LESS or Stylus)
- ✅ Abitrary nesting
Styles apply method(s)
- ✅className
- ❌styled component
- ❌css prop
Styles output
- ✅.css file extraction
- ❌<style> tag injection

This is the baseline we'll consider when comparing all the followingCSS-in-JS solutions. Checkout themotivation to better understand the limitations of this approach that we're trying to fill.

	Transferred / gzipped	Uncompressed
Index page size	76.7 kB	233 kB

Page                                Size     First Load JS┌ ○ /                               2.19 kB        68.7 kB├   └ css/1d1f8eb014b85b65feee.css  450 B├   /_app                           0 B            66.5 kB├ ○ /404                            194 B          66.7 kB└ ○ /other                          744 B          67.2 kB    └ css/1c8bc5a96764df6b92b4.css  481 B+ First Load JS shared by all       66.5 kB  ├ chunks/framework.895f06.js      42 kB  ├ chunks/main.b2b078.js           23.1 kB  ├ chunks/pages/_app.40892d.js     555 B  ├ chunks/webpack.ddd010.js        822 B  └ css/a92bf2d3acbab964f6ac.css    319 B

Styled JSX

Very simple solution, doesn't have a dedicated website for documentation, everything is on Github. It's not popular, but it is the built-in solution in Next.js.

Version:4.0 | Maintained byVercel | Launched in2017 |View Docs | ... back to Overview

✅Styles/Component co-location
🟠Context-aware code completion: to get syntax highlighting & code completion, an editor extension is required
🟠TypeScript support:@types can be additionaly installed, but the API is too minimal to require TS
❌No Atomic CSS
❌No Theming support
❌Not Framework agnostic
Styles definition method(s)
- ✅ Tagged Templates
- ❌ Style Objects
Styles nesting
- ❌ Contextual styles
- ✅ Abitrary nesting
Styles apply method(s)
- ✅className
- ❌styled component
- ❌css prop
Styles output
- ❌.css file extraction
- ✅<style> tag injection

Other benefits

😌 out-of-the-box support with Next.js
👍 for user input styles, it generates a new class name for each change, but it removes the old one

Worth mentioning observations

😏 unlike CSS modules, we can target HTMLelements also, and it generates unique class names for them (not sure if it's a good practice, though)
🤓 we'll need to optimize our styles bysplitting static & dynamic styles, to avoid rendering duplicated styles
🤨 unique class names are added to elements, even if we don't target them in our style definition, resulting in un-needed slight html pollution (optimizing this is cumbersome, and it'sa lot of work for little benefit)
😕 it will bundle any defined styles, regardless if they are used or not, just like plain CSS
😢 there's no support forcontextual styles, so definingpseudo classes ormedia queries has the same downsides as plain CSS, requiring selectors/class names duplication (aSASS plugin is required to get this feature)

Conclusions

Overall, we felt like writting plain CSS, with the added benefit of being able to define the styles along with the component, so wedon't need an additional.css file. Indeed, this is the philosophy of the library: supporting CSS syntax inside the component file. We canuse any JS/TS constants of functions with string interpolation. Working withdynamic styles is pretty easy because it's plain JavaScript in the end. We get all these benefits at a very low price, with a prettysmall bundle overhead.

The downsides are the overall experience of writting plain CSS.Without nesting support pseudo classes/elements and media queries getting pretty cumbersome to manage.

	Transferred / gzipped	Uncompressed
Index page size	79.5 kB	245 kB
vs. CSS Modules	+2.8 kB	+12 kB

Page                             Size     First Load JS┌ ○ /                            2.65 kB        72.6 kB├   /_app                        0 B              70 kB├ ○ /404                         194 B          70.2 kB└ ○ /other                       1.18 kB        71.2 kB+ First Load JS shared by all    70 kB  ├ chunks/framework.895f06.js   42 kB  ├ chunks/main.b2b078.js        23.1 kB  ├ chunks/pages/_app.a4b061.js  4.12 kB  └ chunks/webpack.61f1b6.js     778 B

Styled Components

For sure one of the most popular and mature solutions, with good documentation. It uses Tagged Templates to defines styles by default, but can use objects as well. It also popularized thestyled components approach, which creates a new component along with the defined styles.

Version:5.3 | Maintained byMax Stoiber &others | Launched in2016 |View Docs | ... back to Overview

✅Styles/Component co-location
✅TypeScript support:@types must be additionaly installed, via DefinitelyTyped
✅Built-in Theming support
✅Framework agnostic
🟠Context-aware code completion: requires an editor extension/plugin
❌No Atomic CSS
Styles definition method(s)
- ✅ Tagged Templates
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Abitrary nesting
Styles apply method(s)
- ❌className
- ✅styled component
- ✅css prop
Styles output
- ❌.css file extraction
- ✅<style> tag injection

Worth mentioning observations

🤓 we need to split static & dynamic styles, otherwise it will render duplicate output
😕 bundles nested styles even if they are not used in component
😵 we can mix Tagged Templates with Styled Objects, which could lead to convoluted and different syntax for each approach (kebab vs camel, EOL character, quotes, interpolation, etc)
🥴 some more complex syntax appears to be a bit cumbersome to get right (mixing animations with Styled Objects, dynamic styles based onProps variations, etc)
🤫 for user input styles, it generates a new class name for each update, but it does NOT remove the old ones, appending indefinitely to the DOM

Conclusions

Styled components offers a novel approach to styling components using thestyled method which creates a new component including the defined styles. We don't feel like writting CSS, so coming from CSS Modules we'll have to learn a new, more programatic way, to define styles. Because it allows bothstring andobject syntax, it's a pretty flexibile solution both for migrating our existing styles, and for starting a project from scratch. Also, the maintainers did a pretty good job keeping up with most of the innovations in this field.

However before adopting it, we must be aware that it comes with a certain cost for our bundle size.

	Transferred / gzipped	Uncompressed
Index page size	90.1 kB	272 kB
vs. CSS Modules	+13.4 kB	+39 kB

Page                             Size     First Load JS┌ ○ /                            2.52 kB        83.1 kB├   /_app                        0 B            80.6 kB├ ○ /404                         194 B          80.8 kB└ ○ /other                       1.06 kB        81.7 kB+ First Load JS shared by all    80.6 kB  ├ chunks/framework.895f06.js   42 kB  ├ chunks/main.b2b078.js        23.1 kB  ├ chunks/pages/_app.731ace.js  14.7 kB  └ chunks/webpack.ddd010.js     822 B

Emotion

Probably the most comprehensive, complete and sofisticated solution. Detailed documentation, fully built with TypeScript, looks very mature, rich in features and well maintained.

Version:11.4 | Maintained byMitchell Hamilton &others | Launched in2017 |View Docs | ... back to Overview

✅Styles/Component co-location
✅TypeScript support
✅Built-in Theming support
✅Context-aware code completion: for using thestyled components approach, an additional editor plugin is required
✅Framework agnostic
❌No Atomic CSS
Styles definition method(s)
- ✅ Tagged Templates
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Abitrary nesting
Styles apply method(s)
- ✅className(using@emotion/css)
- ✅styled component
- ✅css prop
Styles output
- ❌.css file extraction
- ✅<style> tag injection

Other benefits

😎 thecss prop offers great ergonomics during development, however it seems to be a newer approach, based onReact 17 newjsx transform, andconfiguring it is not trivial, differs on your setup, and implies some boilerplate (which should change soon and become easier)

Worth mentioning observations

😕 bundles nested styles even if they are not used in component
🤫 for user input styles, it generates a new class name for each update, but it does NOT remove the old ones, appending indefinitely to the DOM
😑 usingstyled approach will add3 kB to our bundle, because it's imported from a separate package
🤔 don't know how to split static and dynamic styles, resulting in highly polluted duplicated styles for component variants, specifically problematic for SSR (same applies tocss prop &styled components)

Conclusions

Overall Emotion looks to be a very solid and flexible approach. The novelcss prop approach offers great ergonomics for developers. Working with dynamic styles and TypeScript is pretty easy and intuitive. Supporting bothstrings andobjects when defining styles, it can be easily used both when migrating from plain CSS, or starting from scratch. The bundle overhead is not negligible, but definitely much smaller than other solutions, especially if you consider the rich set of features that it offers.

It seems it doesn't have a dedicated focus on performance, but more on Developer eXperience. It looks like a perfect "well-rounded" solution.

	Transferred / gzipped	Uncompressed
Index page size	83.2 kB	253 kB
vs. CSS Modules	+6.5 kB	+20 kB

Page                             Size     First Load JS┌ ○ /                            2.5 kB         76.4 kB├   /_app                        0 B            73.9 kB├ ○ /404                         194 B          74.1 kB└ ○ /other                       1.07 kB        74.9 kB+ First Load JS shared by all    73.9 kB  ├ chunks/framework.895f06.js   42 kB  ├ chunks/main.6cb893.js        23.3 kB  ├ chunks/pages/_app.b6d380.js  7.68 kB  └ chunks/webpack.ddd010.js     822 B

TypeStyle

Minimal library, focused only on type-checking. It is framework agnostic, that's why it doesn't have a special API for handling dynamic styles. There are React wrappers available, but the typings feels a bit convoluted.

Version:2.1 | Maintained byBasarat | Launched in2017 |View Docs | ... back to Overview

✅Styles/Component co-location
✅TypeScript support
✅Context-aware code completion
✅Framework agnostic
🟠Built-in Theming support: uses TSnamespaces to define theming, which isnot a recommended TS feature even by the author himself, or by TS core team memberOrta Therox.
❌No Atomic CSS
Styles definition method(s)
- ❌ Tagged Templates
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Abitrary nesting
Styles apply method(s)
- ✅className
- ❌styled component
- ❌css prop
Styles output
- ❌.css file extraction
- ✅<style> tag injection

Worth mentioning observations

😕 bundles nested styles even if they are not used in component
😕 it doesn't handle dynamic styles, so we have to use regular JS functions to compute styles
🤨 when composing styles, we'll have to manually add some internal typings
🤔 don't know how to split dynamic and static styles, so it's very easy to create duplicated generated code with dynamic styles, specifically problematic with SSR
😱 it creates a single<style> tag with all the styles, and replaces it on update, and apparently it doesn't useinsertRule(), not even in production builds, which might be an important performance drawback in large & highly dynamic UIs

Conclusions

Overall TypeStyle seems a minimal library, relatively easy to adopt because we don't have to rewrite our components, thanks to the classicclassName approach. However we do have to rewrite our styles, because of the Style Object syntax. We didn't feel like writting CSS, so there is a learning curve we need to climb.

With Next.js or React in general we don't get much value out-of-the-box, so we still need to perform a lot of manual work. The externalreact-typestyle binding doesn't support hooks, it seems to be an abandoned project and the typings are too convoluted to be considered an elegant solution.

	Transferred / gzipped	Uncompressed
Index page size	78.8 kB	241 kB
vs. CSS Modules	+2.1 kB	+8 kB

Page                             Size     First Load JS┌ ○ /                            2.44 kB        72.1 kB├   /_app                        0 B            69.7 kB├ ○ /404                         194 B          69.9 kB└ ○ /other                       975 B          70.7 kB+ First Load JS shared by all    69.7 kB  ├ chunks/framework.895f06.js   42 kB  ├ chunks/main.b2b078.js        23.1 kB  ├ chunks/pages/_app.5b0422.js  3.81 kB  └ chunks/webpack.61f1b6.js     778 B

Fela

It appears to be a mature solution, with quite a number of users. The API is intuitive and very easy to use, great integration for React using hooks.

Version:11.6 | Maintained byRobin Weser | Launched in2016 |View Docs | ... back to Overview

✅Styles/Component co-location
✅Built-in Theming support
✅Atomic CSS
✅Framework agnostic
🟠TypeScript support: it exposes Flow types, which work ok, from our (limited) experience
🟠Context-aware code completion: styles defined outside the component requireexplicit typing to get code completion
Styles definition method(s)
- 🟠 Tagged Templates
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Abitrary nesting
Styles apply method(s)
- ✅className
- ❌styled component
- ❌css prop
Styles output
- ❌.css file extraction
- ✅<style> tag injection

Other benefits

😌 easy and simple to use API, very intuitive
🥳 creates very short and atomic class names (likea,b, ...)
😎 it has a lot of plugins that can add many additional features (but will also increase bundle size)

Worth mentioning observations

😕 bundles nested styles even if they are not used in component
🤨 when defining styles outside the component, we have to explicitly add some internal typings to get code completion
🥺 there's no actual TS support and the maintainer considers it alow priority
🤕 without TS support, we cannot get fully type-safe integration into Next.js + TS (there aremissing types from the definition file)
🤔 the docs say it supports string based styles, but they are a second-class citizen and they seem to work only for global styles
😵 some information in the docs is spread on various pages, sometimes hard to find without a search feature, and the examples and use cases are not comprehensive

Conclusions

Fela looks to be a mature solution, with active development. It introduces 2 great features which we enjoyed a lot. The first one is the basic principle that"Style as a Function of State" which makes working with dynamic styles feel super natural and integrates perfectly with React's mindset. The second is atomic CSS class names, which should potentially scale great when used in large applications.

The lack of TS support however is a bummer, considering we're looking for a fully type-safe solution. Also, the scaling benefits of atomic CSS should be measured against the library bundle size.

	Transferred / gzipped	Uncompressed
Index page size	88.6 kB	276 kB
vs. CSS Modules	+11.9 kB	+43 kB

Page                             Size     First Load JS┌ ○ /                            2.84 kB        81.7 kB├   /_app                        0 B            78.9 kB├ ○ /404                         194 B            79 kB└ ○ /other                       1.43 kB        80.3 kB+ First Load JS shared by all    78.9 kB  ├ chunks/framework.2191d1.js   42.4 kB  ├ chunks/main.b2b078.js        23.1 kB  ├ chunks/pages/_app.32bc1d.js  12.6 kB  └ chunks/webpack.ddd010.js     822 B

Stitches

Very young library, solid, modern and well-thought-out solution. The overall experience is just great, full TS support, a lot of other useful features baked in the lib.

Version:0.2.5 (beta) | Maintained byModulz | Launched in2020 |View Docs | ... back to Overview

✅Styles/Component co-location
✅TypeScript support
✅Context-aware code completion
✅Built-in Theming support
✅Framework agnostic:(available with@stitches/core)
❌Atomic CSS
Styles definition method(s)
- ❌ Tagged Templates
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Abitrary nesting
Styles apply method(s)
- ✅className
- ✅styled component
- 🟠css prop(used only to overridestyled components)
Styles output
- ❌.css file extraction
- ✅<style> tag injection

Other benefits

😌 easy and simple to use API, a pleasure to work with
😎 great design tokens management and usage
🥰 documentation is exactly what we'd expect: no more, no less

Worth mentioning observations

😕 bundles nested styles even if they are not used in component
🤔 dynamic styles can be defined either using built-invariants (for predefined styles), or styles created inside the component to get access to theprops
🧐 would help a lot to get the search feature inside the docs

Conclusions

Stitches is probably the most modern solution to this date, with full out-of-the-box support for TS. Without a doubt, they took some of the best features from other solutions and put them together for an awesome development experience. The first thing that impressed us was definitely the documentation. The second, is the API they expose which is close to top-notch. The features they provide are not huge in quantity, but are very well-thought-out.

However, we cannot ignore the fact that it's still in beta. Also, the authors identify it as"near-zero runtime", but at+9 kB gzipped it's debatable.

	Transferred / gzipped	Uncompressed
Index page size	82.0 kB	250 kB
vs. CSS Modules	+5.3 kB	+17 kB

Page                             Size     First Load JS┌ ○ /                            2.43 kB        75.2 kB├   /_app                        0 B            72.8 kB├ ○ /404                         194 B            73 kB└ ○ /other                       984 B          73.8 kB+ First Load JS shared by all    72.8 kB  ├ chunks/framework.895f06.js   42 kB  ├ chunks/main.b2b078.js        23.1 kB  ├ chunks/pages/_app.ff82f0.js  6.93 kB  └ chunks/webpack.61f1b6.js     778 B

JSS

Probably the grandaddy around here, JSS is a very mature solution being the first of them, and still being maintained. The API is intuitive and very easy to use, great integration for React using hooks.

Version:10.7 | Maintained byOleg Isonen andothers | Launched in2014 |View Docs | ... back to Overview

✅Styles/Component co-location
✅Built-in Theming support
✅Framework agnostic
✅TypeScript support
✅Context-aware code completion
❌No Atomic CSS
Styles definition method(s)
- 🟠 Tagged Templates:(available with additionalplugin, with limited features)
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Abitrary nesting
Styles apply method(s)
- ✅className
- 🟠styled component(available with additionalplugin)
- ❌css prop
Styles output
- ❌.css file extraction
- ✅<style> tag injection

Other benefits

😌 easy and simple to use API, very intuitive
😎 it has a lot of plugins that can add many additional features (but will also increase bundle size)

Worth mentioning observations

😕 bundles nested styles even if they are not used in component
😳 keep in mind thatreact-jss package, which is used with React/Next.js, depends onjss-preset-default, which includes manyplugins by default, so you don't need to manually add some of the plugins;
🤔react-jss uses className by default. There's alsostyled-jss that usesStyled Components approach, but it has no types, and couldn't make it work on top ofreact-jss;
😤 global styles were frustrating to setup, we've finally managed to used them thanks toStackOverFlow, because the docs have no mention ofinjectSheet API (or we couldn't find it anywhere);
😖 the docs are generally difficult to follow, and finding the information you need is a cumbersome process:
- there is no search;
- there are a lot of plugins, so you don't know where to look for a particular feature;
- some plugins influence other plugins, or other docs pages, and they sometimes don't contain all the combinations of features, so the docs are not comprehensive (ie: we had to figure out on our own how to usecontextual styles withmedia queries).

Conclusions

The API is similar in many ways to React Native StyleSheets, while the hooks helper allows for easy dynamic styles definition. There are many plugins that can add a lot of features to the core functionality, but attention must be payed to the total bundle size, which is significant even with the bare minimum only.

Also, being the first CSS-in-JS solution built, it lacks many of the modern features that focuses on developer experience.

	Transferred / gzipped	Uncompressed
Index page size	94.9 kB	293 kB
vs. CSS Modules	+18.2 kB	+60 kB

Page                             Size     First Load JS┌ ○ /                            2.45 kB          88 kB├   /_app                        0 B            85.6 kB├ ○ /404                         194 B          85.8 kB└ ○ /other                       992 B          86.6 kB+ First Load JS shared by all    85.6 kB  ├ chunks/framework.2191d1.js   42.4 kB  ├ chunks/main.b2b078.js        23.1 kB  ├ chunks/pages/_app.5f0007.js  19.2 kB  └ chunks/webpack.9c89cc.js     956 B

Goober

A very light-weight solution, with a loads of features.

Version:2.0 | Maintained byCristian Bote | Launched in2019 |View Docs | ... back to Overview

✅Styles/Component co-location
✅Built-in Theming support
✅TypeScript support
✅Context-aware code completion
✅Framework agnostic
❌No Atomic CSS
Styles definition method(s)
- ✅ Tagged Templates
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Abitrary nesting
Styles apply method(s)
- ✅className
- ✅styled component (see details below)
- 🟠css prop (is supported, but requires a separate babel plugin)
Styles output
- ❌.css file extraction
- ✅<style> tag injection

Other benefits

🤏 really tiny
😎 it supports a very wide range of defining styles, so it's pretty versatile and full featured in this regard (however, I fear that having all these options, a large team could mix various ways of defining styles, so it's more difficult toenforce consistency)

Worth mentioning observations

😕 bundles nested styles even if they are not used in component
🤫 for user input styles, it generates a new class name for each update, but it does NOT remove the old ones, appending indefinitely to the DOM
🤔 don't know how to split static and dynamic styles, resulting in highly polluted duplicated styles for component variants, specifically problematic for SSR
😱 it creates a single<style> tag with all the styles, and appends to it on update, and apparently it doesn't useinsertRule(), not even in production builds, which might be an important performance drawback in large & highly dynamic UIs

Conclusions

Looking at Goober you cannot ask yourself what kind of magic did Cristian Bote do to fit all the features inside this tiny library. It is really mind blowing. It is marketed as being"less than 1KB", which is not entirely accurate, but still... it's the smallest library we've tested.

	Transferred / gzipped	Uncompressed
Index page size	77.8 kB	237 kB
vs. CSS Modules	+1.1 kB	+4 kB

Page                             Size     First Load JS┌ ○ /                            2.77 kB        71.1 kB├   /_app                        0 B            68.3 kB├ ○ /404                         194 B          68.5 kB└ ○ /other                       2.39 kB        70.7 kB+ First Load JS shared by all    68.3 kB  ├ chunks/framework.895f06.js   42 kB  ├ chunks/main.b2b078.js        23.1 kB  ├ chunks/pages/_app.5ee014.js  2.42 kB  └ chunks/webpack.61f1b6.js     778 B

Compiled

A rather new library, having the huge Atlassian platform supporting and probably using it. Many existing features, even more in development, or planned for development.

Version:0.6 | Maintained byAtlassian | Launched in2020 |View Docs | ... back to Overview

✅Styles/Component co-location
✅TypeScript support
✅Context-aware code completion
✅Atomic CSS
❌Not Framework agnostic
❌No Built-in Theming support(at least at the moment, but it isplanned)
Styles definition method(s)
- ✅ Tagged Templates
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Arbitrary nesting
Styles apply method(s)
- 🟠className(only supported with a customClassNames component)
- ✅styled component
- ✅css prop
Styles output
- ❌.css file extraction(currently under development, will be shipped in 2021)
- ✅<style> tag injection

Other benefits

😌 using thecss prop is seamless and trivial, not requiring any special setup (unlike Emotion)

Worth mentioning observations

🧐 styles are not placed in the<head> during SSR - instead they are placed right before the element using them in the<body>, which could potentially provide slightly faster Paint metrics, such as FCP, or LCP, because the browser can start rendering the body faster and incrementally, not waiting for the entire block of styles to be parsed
😕 bundles nested styles even if they are not used in component
😔 currently has no API for global styles, but it isplanned to be added
😳ClassNames API, which enables us to apply styles as class name strings, is a bit convoluted and weird at first sight.

Conclusions

Compiled is a very promising library. Considering that it offers both atomic CSS, and it plans to support static.css extraction, with excellent TypeScript support and style co-location, it would be quite unique (having onlystyle9 as a direct competitor).

Also, we cannot ignore that is has Atlassian supporting its development, which puts a (slightly) bigger weight on the confidence level.

The total bundle overhead is pretty small, the runtime library being quite light-weight. With static.css file extraction, this could potentially become even smaller.

	Transferred / gzipped	Uncompressed
Index page size	80.2 kB	242 kB
vs. CSS Modules	+3.5 kB	+9 kB

Page                              Size     First Load JS┌ ○ /                             2.11 kB        71.8 kB├   /_app                         0 B            66.5 kB├ ○ /404                          194 B          66.7 kB└ ○ /other                        888 B          70.6 kB+ First Load JS shared by all     66.5 kB  ├ chunks/framework.895f06.js    42 kB  ├ chunks/main.b2b078.js         23.1 kB  ├ chunks/pages/_app.ebe095.js   576 B  ├ chunks/webpack.ddd010.js      822 B  └ css/a92bf2d3acbab964f6ac.css  319 B

Linaria

Linaria is all about static CSS extraction and avoiding any runtime overhead.

Version:3.0 (beta) | Maintained byCallstack | Launched in2018 |View Docs | ... back to Overview

✅Styles/Component co-location
✅TypeScript support
✅Context-aware code completion
✅Framework agnostic
✅Built-in Theming support
❌No Atomic CSS
Styles definition method(s)
- ✅ Tagged Templates
- ❌ Style Objects
Styles nesting
- ✅ Contextual styles
- ✅ Arbitrary nesting
Styles apply method(s)
- ✅className
- ✅styled component
- ❌css prop
Styles output
- ✅.css file extraction
- ❌<style> tag injection

Other benefits

😎 it's the only existing library at the moment (with a stable release) that supports both co-location & static CSS extraction (Compiled could also support this soon)

Worth mentioning observations

😕 bundles nested styles even if they are not used in component
😔global styling is documented, but we didn't get to make them work with Next.js
😳 documentation is not top-notch, there isn't a dedicated website, no search feature and it feels like trial & error when trying to find a piece of information

Conclusions

Linaria is highly inspired from Astroturf, combining various features from other libraries.

Version 3 is currently in Beta, not sure what the changelog is compared to v2. It's still in development by theReact/Native geeks atCallstack.io, but we couldn't find which of the big players use it in production.

It seems to have a slightly larger overall page size (2.9 KB), but we didn't investigate where does this come from. Also, there's an open question if this overhead is fixed or if it scales.

PS: thanks toDaniil Petrov for his PR with the Next.js integration

	Transferred / gzipped	Uncompressed
Index page size	79.4 kB	239 kB
vs. CSS Modules	+2.7 kB	+6 kB

Page                                Size     First Load JS┌ ○ /                               4.99 kB        71.5 kB├   └ css/16f3e95ede28dcc048f2.css  423 B├   /_app                           0 B            66.5 kB├ ○ /404                            194 B          66.7 kB└ ○ /other                          3.59 kB        70.1 kB    └ css/3064299bff08067ec7dd.css  427 B+ First Load JS shared by all       66.5 kB  ├ chunks/framework.895f06.js      42 kB  ├ chunks/main.b2b078.js           23.1 kB  ├ chunks/pages/_app.98e8c3.js     598 B  ├ chunks/webpack.ddd010.js        822 B  └ css/7739287c04a618ea0c54.css    295 B

vanilla-extract

Modern solution with great TypeScript integration and no runtime overhead. It's pretty minimal in its features, straightforward and opinionated. Everything is processed at compile time, and it generates static CSS files. Successor ofTreat, also be called "Treat v3", is developed and maintained by the same authors.

Version:1.2 | Maintained bySeek OSS | Launched in2021 |View Docs | ... back to Overview

✅TypeScript support
✅Built-in Theming support
✅Context-aware code completion
✅Framework agnostic
🟠Atomic CSS: can be achieved withSprinkles
❌No Styles/Component co-location: styles must be placed in an external.css.ts file
Styles definition method(s)
- ❌ Tagged Templates
- ✅ Style Objects
Styles nesting
- ✅ Contextual styles
- ❌ Abitrary nesting
Styles apply method(s)
- ✅className
- ❌styled component
- ❌css prop
Styles output
- ✅.css file extraction
- ❌<style> tag injection

Other benefits

👮 forbidsnested arbitrary selectors (ie:& > span), which might be seen as a downside, but it actually discourages bad-practices likespecificity wars, which should be avoided when scaling CSS (however, this is impossible to be statically type-checked withoutpattern matching, so it will throw a runtime exception)
🥳 generates the same filename hash on build, if styles haven't changes, meaning that end-users benefit of CSS cache-ing even when deploying new versions with component updates only (logic, or content), without styles updates

Worth mentioning observations

😌 in contrast with Treat, it relies on CSS Variables support, which means: 1) it doesn't work on IE, 2) is simpler and easier to maintain, 3) it supports other bundlers besides webpack
😕 bundles all styles, exported or not, even if they are not used in component
😥 it doesn't handle dynamic styles: you can use built-invariants based on predefined types, orinline styles for user-defined styles

Conclusions

We felt a lot like using CSS Modules: we need an external file for styles, we place the styles on the elements usingclassName, we handle dynamic styles withinline styles, etc. However, we don't write CSS, and the overall experience with TypeScript support is magnificent, because everything is typed, so we don't do anycopy-paste. Error messages are very helpful in guiding us when we do something we're not supposed to do.

vanilla-extract is built with restrictions in mind, with a strong user-centric focus, balacing the developer experience with solid TypeScript support. It's also worth mentioning thatMark Dalgleish, co-author of CSS Modules, works at Seek and he's also a contributor.

The authors vision is to think of vanilla-extract as a low-level utility for building higher-level frameworks, which will probably happen in the future.

	Transferred / gzipped	Uncompressed
Index page size	76.7 kB	231 kB
vs. CSS Modules	+0.0 kB	-2 kB

Page                                Size     First Load JS┌ ○ /                               2.09 kB        68.5 kB├   └ css/37c023369f5e1762e423.css  370 B├   /_app                           0 B            66.4 kB├ ○ /404                            194 B          66.6 kB└ ○ /other                          611 B            67 kB    └ css/a56b9d05c6da35ff125f.css  386 B+ First Load JS shared by all       66.4 kB  ├ chunks/framework.895f06.js      42 kB  ├ chunks/main.700159.js           23.1 kB  ├ chunks/pages/_app.bfd136.js     565 B  ├ chunks/webpack.61f1b6.js        778 B  └ css/23b89d9ef0ca05e4b917.css    286 B

Libraries not included

We know there are a lot of other libraries out there, besides the ones covered above. We're only covered the ones that have support forReact, support forSSR, an easy integration withNext.js, gooddocumentation and a sense of ongoingsupport and maintenance. Please checkout ourgoals.

Treat

Treat was initially included in the analysis with v1.6, but removed for a few reasons:

the library itself is replaced byvanilla-extract
Next.js integration is not supported with v2
we couldn't upgrade to Next.js v11/webpack 5 even with v1

The main difference between vanilla-extract and Treat is that the latter supports IE and legacy browsers as well.

style9

Style9 is a new library, inspired by Facebook's own CSS-in-JS solution called stylex. Style9 is unique because it's the only open source library that supports both.css static extraction + atomic CSS, and/or styles co-location. It has TS support and easy to integrate with Next.js.

However, it has quite a few limitations (at least as of Feb 2021) that makes it practically unusable in a real production application that we would want to scale, both in code & team size:

cannot use design tokens defined asEnum orPOJO, only constant primitives are supported, which is abig deal breaker;
dynamic styles are not trivial:
- it supports styles toggling, similar toclassNames lib, but not dynamically/computed/expression based;
- for user styles, so we have to use inline styles;
- there is an experimental addonstyle9-components that tries to solve this;
no global styles support;
no theming support (not a deal breaker for us):
- there is some exploration in this regard, withstyle9-theme;
documentation is not comprehensive, it contains a lot of code comments, without code examples, making it even more difficult to follow & understand

Some upsides:

it's the first lib we've tested that actually doesn't bundle unused styles;
it doesn't allow arbitrary seletors / nesting, which is a good thing, because it enforces good practices and consistency;
it is framework agnostic;

As a conclusion, it wants to be a powerful solution with very interesting and unique set of features, but it's not mature yet. As far as we see, it's currently mostly designed towards more static solutions. Dynamic styling seems to be difficult to handle, at least for the moment.

Tailwind

Not an actual CSS-in-JS library, more like a replacement for traditional CSS styling. It uses atomic CSS classes (some of them having multiple properties) that we attach to html elements. We don't write CSS, instead we use a different DSL to specify styles, pseudo classes, media queries, etc.

The reason we didn't include it in our thorough review is because it doesn't fully meet ourgoals:

it doesn't provide TS support, or type-safety
- we cannot use out own design tokens from.ts files to include them intailwind.config (cannotimport any file, cannot require.ts)
- usingtailwind.config directly offers no type-safety when importing it, or usingresolveConfig
- there is aPR on Definitely Typed, but we're not sure if it will support the custom config, as well
- there might be workarounds, but these are just proofs that there isn't a clean way to achieve this
dynamic styles have some limitations: we have to be aware ofpurging to not get missing design tokens in production builds
we have to learn a new DSL: some style are similar and easy to deduce from their CSS counterparts, others are pretty different, and we have to learn (rounded,place-self/content,divide,ring)
some advanced CSS features, like::after pseudo elements are tricky
there are libraries likexwind which integrates Tailwind with CSS-in-JS solutions, which is supports our theory that Tawilwind is not a replacement for CSS-in-JS, not does it address the same problems

Some upsides:

we don't write CSS, which is indeed difficult to master
the entire team uses the same "styling system"
a shitton of predefined design tokens, plus the ability to customize them
successfully bundles only used styles, doesn't bundle all classes defined intailwind.config
- exception: keyframe animations (spin, ping, etc)
- beware of purging

Tailwind seems to be more than astyling tool, it also offers some out-of-the-box utils + a ready-made design system that you can use right away.

Aphrodite

It's not a popular solution, the approach is similar toReact Native StyleSheets way of styling components. Has built-in TypeScript support and a simple API.

global styles are a bit cumbersome to define
able to nest media queries & pseudo selectors, but cannot nest arbitrary rules/selectors
no dynamic out-of-the-box support, so we have to get around that, like inline styles I guess, or like in React Native
doesn't add any real value, except the ergonomics to colocate styles with the component.

Glamor

I got it started with Next.js, but it feels fragile. TheGlamor official example throws an error regardingrehydrate. When commenting it out, it works, but not sure what the consequences are.

it looks like an unmaintained or abandoned package
documentation is pretty minimal
lacks any TS support
has a lot of documented experimental features, marked as "buggy"
it feels like a side/internal project at FB, that is not used anymore.

Cxs

Didn't manage to start it with Next.js + TypeScript. Theofficial example uses version 3, while today we have version 6. The example doesn't work, because the API has changed.

The solution looked interesting, because it is supposed to be very light-weight.

Astroturf

Didn't manage to start it with Next.js + TypeScript. There was anofficial example that used an older version of Next.js, but the example if not there anymore.

The solution is not that popular, but it was the first to use.css extraction with collocated styles.

Otion

Looks promising, atomic css and light-weight. It has a workingNext.js example, but we didn't consider it because it lacks any documentation.

Styletron

It looks like a not so popular solution, which also lacks support for TypeScript. It looks like the maintainers work at Uber and they use it internally. It focused on generating unique atomic CSS classes, which could potentially deduplicate a lot of code.

Radium

The project was put inMaintenance Mode. They recommend other solutions.

Glamorous

The project wasdiscontinued in favor of Emotion.

Running the examples

Each implementation sits on their own branch, so we can have a clear separation at built time.

# install dependenciesyarn# for developmentyarn dev# for productionyarn buildyarn start

Feedback and Suggestions

To get in touch, my DMs are open@pfeiffer_andrei.

Special thanks and appreciations go to everyone that helped putting this document together, and making it more accurate:

Martin Hochel (@martin_hotell)
Oleg Isonen (@oleg008)

About

A thorough analysis of all the current CSS-in-JS solutions with SSR & TypeScript support for Next.js

Movatterモバイル変換

andreipfeiffer/css-in-js

Folders and files

Latest commit

History

Repository files navigation

A thorough analysis of CSS-in-TS

Table of contents

Motivation

Goals

Disclaimer

Overview

LEGEND:

1. Co-location

2. DX

3.tag` ` (Tagged Templates)

4.{ } (Object Styles)

5. TS

6.& ctx (Contextual Styles)

7. Nesting

8. Theming

9..css (Static CSS extraction)

10.<style> tag

11. Atomic CSS

12.className

13.<Styled />

14.css prop

15. Framework agnostic

16. Page size delta

Overall observations

✅ Code splitting

✅ Global styles

✅ SSR

✅ Vendor prefixes

✅ Unique class names

✅ No inline styles

✅ Full CSS support

✅ Critical CSS extraction

🟠 Performance Metrics

1..css file extraction

2.<style> tag injected styles

🟠 Dead code removal

🟠 Debugging / Inspecting

1. Using<style> tag(s)

2. UsingCSSStyleSheet API

❌ No component deduping

CSS Modules

Styled JSX

Other benefits

Worth mentioning observations

Conclusions

Styled Components

Worth mentioning observations

Conclusions

Emotion

Other benefits

Worth mentioning observations

Conclusions

TypeStyle

Worth mentioning observations

Conclusions

Fela

Other benefits

Worth mentioning observations

Conclusions

Stitches

Other benefits

Worth mentioning observations

Conclusions

JSS

Other benefits

Worth mentioning observations

Conclusions

Goober

Other benefits

Worth mentioning observations

Conclusions

Compiled

Other benefits

Worth mentioning observations

4.`{ }` (Object Styles)

6.`&` ctx (Contextual Styles)

9.`.css` (Static CSS extraction)

10.`<style>` tag

12.`className`

13.`<Styled />`

14.`css` prop

1.`.css` file extraction

2.`<style>` tag injected styles

1. Using`<style>` tag(s)

2. Using`CSSStyleSheet` API