Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/andreipfeiffer/css-in-js below:

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

This document contains an in-depth analysis of all the current CSS-in-JS solutions, that support Server Side Rendering and TypeScript.

The baseline reference we'll use for comparison is a CSS Modules approach.
We're using Next.js as a SSR framework for building resources.
Last important aspect is type-safety with full TypeScript support.

🗓 Last update: Aug 2021

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

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

✋ Please checkout our goals & disclaimer before jumping to conclusions.

• Motivation
• Goals
• Disclaimer
• Overview
  • Legend
  • Overall observations
• Libraries review
  • CSS Modules
  • Styled JSX
  • Styled Components
  • Emotion
  • TypeStyle
  • Fela
  • Stitches
  • JSS
  • Goober
  • Compiled
  • Linaria
  • vanilla-extract
• Libraries not included
• Running the examples
• Feedback and Suggestions

The CSS language and CSS Modules have some limitations, especially if we want to have type-safe code. Some of these limitations have alterative solutions, others are just being annoying or less than ideal:

1. 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 the component.js file and the component.css file, searching for a given class name, and not being able to easily "go to style definition", is an important productivity drawback.

2. Styling pseudos and media queries requires selector duplication
   Another frustrating fact is the need to duplicate our CSS classes when defining pseudo classes and elements, or media queries. We can overcome these limitations using a CSS preprocessor like SASS, LESS or Stylus, that supports the & parent selector, enabling contextual styling.

   .button {}
   
   /* duplicated selector declaration for pseudo classes/elements */
   .button:hover {}
   .button::after {}
   
   @media (min-width: 640px) {
     /* duplicated selector declaration inside media queries */
     .button {}
   }

3. Styles usage is disconnected from their definition
   We get no IntelliSense with CSS Modules, of what CSS classes are defined in the component.css file, making copy-paste a required tool, lowering the DX. It also makes refactoring very cumbersome, because of the lack of safety.

4. Using type-safe design tokens in CSS is non-trivial
   Any design 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 as CSS Custom Properties / Variables, but we still don't get any IntelliSense or type-safety when using them in .module.css.
   • We could use inline 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;

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:

• defining global styles
• using media queries & pseudo classes
• dynamic styles based on component props (aka. component variants), or from user input
• bundle size impact

This analysis is intended to be objective and unopinionated:

• I have not built my own CSS-in-JS library.
• I don't work on any of the libraries reviewed here.
• I have no intention or motivation for promoting or trashing either of them.
• I have no prior experience with any CSS-in-JS solution, so I'm not biased towards any of them.
• I have equally used all the solutions analyzed here, which also means I have no extensive experience with any of them. So, you can safely say I'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 checkout Necholas's benchmarks for this);

👍 What you WILL FIND here?

• an overview of (almost) all CSS-in-JS solutions available at this date (see last update on top) that we've tried to integrate into a Next.js v11 + TypeScript empty project, with minimal effort;
• a limited set of quantitative metrics that allowed us to evaluate these solutions, which might help you as well;
• an additional list of qualitative 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 brief history of CSS-in-JS, you should checkout the Past, Present, and Future of CSS-in-JS insightful talk by Max Stoiber.

• ✅ - 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

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

Refers to the Developer 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

Support for defining styles as strings, using ES Tagged Templates:

• uses kebab-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) for syntax highlight and code completion, otherwise our code would look like a plain string;
• 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

Support for defining styles as objects, using plain JavaScript objects:

• uses camelCase for property names, like we would do in React 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

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

Support for contextual styles allowing us to easily define pseudo classes & elements and media 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

Support for arbitrary 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

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

⬆️ to overview

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 approach affects FCP/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

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 during hydration;
• more suited for highly dynamic and interactive (single page) applications;

⬆️ to overview

The ability to generate atomic 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;
• theoretically atomic 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

The library API returns a string 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

The API creates a wrapper (or Styled) component which includes the generated className(s):

• this technique was first introduced and popularized by Styled 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 like StyledButton or StyledList instead of constants like button_styles or list_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 with Vue;

⬆️ to overview

Allows passing styles using a special css 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 by Emotion v10;
• it's seems to be available only for React/JSX-based syntax

⬆️ to overview

Allows usage without, or with any framework. Some libraries are built specifically for React only.
NOTE: some libraries like Stitches or Emotion document only React usage, although they have a core that's framework agnostic.

⬆️ to overview

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

• keep in mind that this includes an almost empty 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.js 11.1.0 and the values are taken from Chrome Devtools Network tab, Transferred over network vs Resource size.

⬆️ to overview

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

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.

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 is planned

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

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

• vanilla-extract is the only library that requires manual setup

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 a hashing algorithm, requiring more computing, but resulting in idempotent names (for example: .heading style from Card component will always have the .Card_heading_h7Ys5 hash);
• other libraries use counting, 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);

None of the solutions generate inline styles, which is an older approach, used by Radium & Glamor. The approach is less performant than CSS classes, and it's not 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.

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

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

What they actually do:

• during SSR, they only generate styles for the visible 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 use static CSS extraction.

Understanding how these features affect Core Web Vitals and Performance 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);

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

📭 Empty cache
If the user has an empty cache, the following needs to happen, negatively impacting FCP and LCP:

• the browser needs to make an additional request, which implies a full RTT (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 in parallel 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, so FCP and LCP 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;

During SSR, 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 perform Critical CSS extraction, so these styles 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 faster FCP and LCP:

• 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, during hydration (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 a fully 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 is SSRed, 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;

Most solutions say they remove unused code/styles. This is only half-true.

Unused code is indeed more difficult to accumulate, especially if you compare it to plain .css files as we used to write a decade ago. But when compared to CSS Modules, the differencies are not that big. Any solution that offers the option to define arbitrary selectors or nested 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.

There are 2 methods to inject CSS into the DOM & update it from JavaScript:

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 easily see 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 in DEVELOPMENT mode, because it provides a better debugging experience;
  • TypeStyle uses this in PRODUCTION also;

First used by JSS, this method uses CSSStyleSheet.insertRule() to inject CSS rules directly into the CSSOM.

• using this approach it's a bit more difficult to see what styles get injected into the CSSOM, because even if you see the CSS applied on the elements (thanks to CSS-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 in PRODUCTION;
  • performance gains apply only when adding new CSS rules, or updating existing ones (ie: dynamic styles update at runtime);
  • JSS and Stitches use it in DEVELOPMENT mode as well;

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, and not 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 their official blog and web.dev if a component is used in more than 50% of the pages, it should be included in the commons bundle. However, in our example, we have 2 pages, each of them importing the Button component, and it's included in each page bundle, not in the commons 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.

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 in 2015 | 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 following CSS-in-JS solutions. Checkout the motivation to better understand the limitations of this approach that we're trying to fill.

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

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 by Vercel | Launched in 2017 | 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

• 😌 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

• 😏 unlike CSS modules, we can target HTML elements 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 by splitting 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's a 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 for contextual styles, so defining pseudo classes or media queries has the same downsides as plain CSS, requiring selectors/class names duplication (a SASS plugin is required to get this feature)

Overall, we felt like writting plain CSS, with the added benefit of being able to define the styles along with the component, so we don't need an additional .css file. Indeed, this is the philosophy of the library: supporting CSS syntax inside the component file. We can use any JS/TS constants of functions with string interpolation. Working with dynamic styles is pretty easy because it's plain JavaScript in the end. We get all these benefits at a very low price, with a pretty small 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.

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

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 the styled components approach, which creates a new component along with the defined styles.

Version: 5.3 | Maintained by Max Stoiber & others | Launched in 2016 | 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

• 🤓 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 on Props 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

Styled components offers a novel approach to styling components using the styled 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 both string and object 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.

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

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 by Mitchell Hamilton & others | Launched in 2017 | View Docs | ... back to Overview

• ✅ Styles/Component co-location

• ✅ TypeScript support

• ✅ Built-in Theming support

• ✅ Context-aware code completion: for using the styled 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

• 😎 the css prop offers great ergonomics during development, however it seems to be a newer approach, based on React 17 new jsx transform, and configuring it is not trivial, differs on your setup, and implies some boilerplate (which should change soon and become easier)

• 😕 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
• 😑 using styled approach will add 3 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 to css prop & styled components)

Overall Emotion looks to be a very solid and flexible approach. The novel css prop approach offers great ergonomics for developers. Working with dynamic styles and TypeScript is pretty easy and intuitive. Supporting both strings and objects 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.

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

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 by Basarat | Launched in 2017 | View Docs | ... back to Overview

• ✅ Styles/Component co-location

• ✅ TypeScript support

• ✅ Context-aware code completion

• ✅ Framework agnostic

• 🟠 Built-in Theming support: uses TS namespaces to define theming, which is not a recommended TS feature even by the author himself, or by TS core team member Orta 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

• 😕 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 use insertRule(), not even in production builds, which might be an important performance drawback in large & highly dynamic UIs

Overall TypeStyle seems a minimal library, relatively easy to adopt because we don't have to rewrite our components, thanks to the classic className 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 external react-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.

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

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 by Robin Weser | Launched in 2016 | 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 require explicit 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

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

• 😕 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 a low priority
• 🤕 without TS support, we cannot get fully type-safe integration into Next.js + TS (there are missing 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

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.

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

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 by Modulz | Launched in 2020 | 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 override styled components)

• Styles output

  • ❌ .css file extraction
  • ✅ <style> tag injection

• 😌 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

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

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.

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

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 by Oleg Isonen and others | Launched in 2014 | 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 additional plugin, with limited features)
  • ✅ Style Objects

• Styles nesting

  • ✅ Contextual styles
  • ✅ Abitrary nesting

• Styles apply method(s)

  • ✅ className
  • 🟠 styled component (available with additional plugin)
  • ❌ css prop

• Styles output

  • ❌ .css file extraction
  • ✅ <style> tag injection

• 😌 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)

• 😕 bundles nested styles even if they are not used in component
• 😳 keep in mind that react-jss package, which is used with React/Next.js, depends on jss-preset-default, which includes many plugins by default, so you don't need to manually add some of the plugins;
• 🤔 react-jss uses className by default. There's also styled-jss that uses Styled Components approach, but it has no types, and couldn't make it work on top of react-jss;
• 😤 global styles were frustrating to setup, we've finally managed to used them thanks to StackOverFlow, because the docs have no mention of injectSheet 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 use contextual styles with media queries).

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.

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

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

Version: 2.0 | Maintained by Cristian Bote | Launched in 2019 | 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

• 🤏 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 to enforce consistency)

• 😕 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 use insertRule(), not even in production builds, which might be an important performance drawback in large & highly dynamic UIs

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.

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

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 by Atlassian | Launched in 2020 | 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 is planned)

• Styles definition method(s)

  • ✅ Tagged Templates
  • ✅ Style Objects

• Styles nesting

  • ✅ Contextual styles
  • ✅ Arbitrary nesting

• Styles apply method(s)

  • 🟠 className (only supported with a custom ClassNames component)
  • ✅ styled component
  • ✅ css prop

• Styles output

  • ❌ .css file extraction (currently under development, will be shipped in 2021)
  • ✅ <style> tag injection

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

• 🧐 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 is planned to be added
• 😳 ClassNames API, which enables us to apply styles as class name strings, is a bit convoluted and weird at first sight.

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 only style9 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.

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 is all about static CSS extraction and avoiding any runtime overhead.

Version: 3.0 (beta) | Maintained by Callstack | Launched in 2018 | 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

• 😎 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)

• 😕 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

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 the React/Native geeks at Callstack.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 to Daniil Petrov for his PR with the Next.js integration

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

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 of Treat, also be called "Treat v3", is developed and maintained by the same authors.

Version: 1.2 | Maintained by Seek OSS | Launched in 2021 | View Docs | ... back to Overview

• ✅ TypeScript support

• ✅ Built-in Theming support

• ✅ Context-aware code completion

• ✅ Framework agnostic

• 🟠 Atomic CSS: can be achieved with Sprinkles

• ❌ 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

• 👮 forbids nested arbitrary selectors (ie: & > span), which might be seen as a downside, but it actually discourages bad-practices like specificity wars, which should be avoided when scaling CSS (however, this is impossible to be statically type-checked without pattern 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

• 😌 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-in variants based on predefined types, or inline styles for user-defined styles

We felt a lot like using CSS Modules: we need an external file for styles, we place the styles on the elements using className, we handle dynamic styles with inline 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 any copy-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 that Mark 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.

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

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 for React, support for SSR, an easy integration with Next.js, good documentation and a sense of ongoing support and maintenance. Please checkout our goals.

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

1. the library itself is replaced by vanilla-extract
2. Next.js integration is not supported with v2
3. 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 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 as Enum or POJO, only constant primitives are supported, which is a big deal breaker;
• dynamic styles are not trivial:
  • it supports styles toggling, similar to classNames lib, but not dynamically/computed/expression based;
  • for user styles, so we have to use inline styles;
  • there is an experimental addon style9-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, with style9-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.

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 our goals:

• it doesn't provide TS support, or type-safety
  • we cannot use out own design tokens from .ts files to include them in tailwind.config (cannot import any file, cannot require .ts)
  • using tailwind.config directly offers no type-safety when importing it, or using resolveConfig
  • there is a PR 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 of purging 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 like xwind 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 in tailwind.config
  • exception: keyframe animations (spin, ping, etc)
  • beware of purging

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

It's not a popular solution, the approach is similar to React 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.

I got it started with Next.js, but it feels fragile. The Glamor official example throws an error regarding rehydrate. 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.

Didn't manage to start it with Next.js + TypeScript. The official 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.

Didn't manage to start it with Next.js + TypeScript. There was an official 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.

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

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.

The project was put in Maintenance Mode. They recommend other solutions.

The project was discontinued in favor of Emotion.

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

# install dependencies
yarn

# for development
yarn dev

# for production
yarn build
yarn start

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)

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4