css in js Download - css in js Download de código -fonte

Uma análise completa do CSS-in-TS

Este documento contém uma análise aprofundada de todas as soluções atuais do CSS-In-JS , que suportam a renderização e a digitalização do servidor.

A referência de linha de base que usaremos para comparação é uma abordagem de módulos CSS .
Estamos usando o Next.js como uma estrutura SSR para a construção de recursos.
O último aspecto importante é a segurança do tipo com o suporte completo do texto datilografado .

? Última atualização: agosto de 2021

? Para obter uma visão geral mais curta, você pode verificar o artigo sobre truques CSS :
https://css-tricks.com/a-thorough-analysis-of-css-in-js/

? Se você preferir um vídeo, pode verificar minha palestra de ngpartycz :
https://www.youtube.com/watch?v=c7uwghrax9a

Confira nossos objetivos e isenção de responsabilidade antes de tirar conclusões.

Índice

Motivação
Metas
Isenção de responsabilidade
Visão geral
- Lenda
- Observações gerais
Revisão das bibliotecas
- Módulos CSS
- JSX denominado
- Componentes estilizados
- Emoção
- Typestyle
- Fela
- Pontos
- JSS
- Goober
- Compilado
- Linaria
- baunilha-extrato
Bibliotecas não incluídas
Executando os exemplos
Feedback e sugestões

Motivação

Os módulos CSS Language e CSS têm algumas limitações, especialmente se quisermos ter código seguro. Algumas dessas limitações têm soluções alterativas, outras estão sendo irritantes ou menos do que o ideal :

Os estilos não podem ser co-localizados com componentes
Isso pode ser frustrante ao criar muitos pequenos componentes, mas não é um quebra de negócio. No entanto, a experiência de mover-se e partir para o arquivo component.js e o arquivo component.css , pesquisar um determinado nome de classe e não ser capaz de "ir para a definição de estilo" facilmente é uma importante desvantagem da produtividade.
Pseudos de estilo e consultas de mídia requer duplicação seletora
Outro fato frustrante é a necessidade de duplicar nossas classes CSS ao definir aulas e elementos de pseudo -elementos , ou consultas de mídia . Podemos superar essas limitações usando um pré -processador de CSS como SASS, Menos ou Stylus , que suporta o seletor & dos pais, permitindo o estilo contextual .
```
. button {}

/* duplicated selector declaration for pseudo classes/elements */
. button : hover {}
. button :: after {}

@media ( min-width : 640 px ) {
  /* duplicated selector declaration inside media queries */
  . button {}
}
```
O uso de estilos está desconectado de sua definição
Não temos o IntelliSense com os módulos CSS, do que as classes CSS são definidas no arquivo component.css , tornando a cópia uma ferramenta necessária, diminuindo o DX. Também torna a refatoração muito pesada , devido à falta de segurança.
Usar tokens de design segura
Quaisquer tokens de design definidos em JS/TS (para se beneficiar da segurança do tipo) não podem ser usados diretamente no CSS.
Existem pelo menos 2 soluções alternativas para esta questão, nenhum deles sendo elegante:
- Poderíamos injetá-los como propriedades / variáveis personalizadas do CSS, mas ainda não temos nenhum intellisense ou segurança do tipo ao usá-las no .module.css .
- Poderíamos usar estilos embutidos , que são menos executivos, e também introduz uma maneira diferente de escrever estilos (CamelCase vs. Kebab Case), além de dividir o estilo em 2 locais diferentes: o arquivo de componente e o arquivo .css .
- Poderíamos usar o CSS (ou SASS) como fonte de verdade para os tokens de design, armazenando-os como propriedades personalizadas do CSS e lê-las no JS usando consultas DOM, mas ainda precisamos atualizar manualmente o código CSS e JS quando executamos qualquer alteração, porque não temos segurança no tipo que lidamos com o CSS;

Metas

Existem objetivos específicos que estamos procurando com esta análise:

? Suporte SSR e fácil integração com o Next.js
? Suporte completo de texto datilografado
? Ótimo DX com conclusão de código e destaque da sintaxe
? leve
? documentação abrangente
? API intuitiva e baixa curva de aprendizado

Ficando ainda mais específico, queríamos experimentar o uso de várias soluções CSS-In-JS sobre:

Definindo estilos globais
Usando consultas de mídia e aulas de pseudo
Estilos dinâmicos baseados em props de componentes (também conhecidos como variantes de componentes) ou da entrada do usuário
Impacto do tamanho do pacote

Isenção de responsabilidade

Esta análise pretende ser objetiva e poucopinionada :

Não construí minha própria biblioteca CSS-in-JS.
Não trabalho em nenhuma das bibliotecas revisadas aqui.
Não tenho intenção ou motivação para promover ou destruir nenhum deles.
Não tenho experiência anterior com nenhuma solução CSS-in-JS, por isso não sou tendenciosa em relação a nenhum deles.
Eu usei igualmente todas as soluções analisadas aqui, o que também significa que não tenho nenhuma experiência extensa com nenhuma delas. Então, você pode dizer com segurança que sou um macaco de todas as bibliotecas CSS-in-JS, mas mestre de nenhuma .

? O que você não encontrará aqui?

Qual solução é "o melhor" , pois não adicionarei nenhuma classificação, o que também seria altamente subjetivo;
Qual solução é "a mais rápida" , pois não sou conceitual sobre a renderização de métricas de desempenho (você pode verificar os benchmarks de Necholas para isso);

? O que você encontrará aqui?

uma visão geral de (quase) todas as soluções CSS-in-JS disponíveis nesta data (consulte a última atualização por cima) que tentamos integrar em um projeto vazio do próximo.js v11 + , com um esforço mínimo ;
um conjunto limitado de métricas quantitativas que nos permitiram avaliar essas soluções, o que também pode ajudá -lo;
Uma lista adicional de observações pessoais qualitativas , que podem ser detalhes menores ou quebradores de negócios ao escolher uma solução específica.

As bibliotecas não são apresentadas em nenhuma ordem específica. Se você estiver interessado em uma breve história do CSS-In-JS , deve verificar o passado, o presente e o futuro da conversa perspicaz do CSS-In-JS de Max Stoiber.

Visão geral

	1. Co -localização	2. DX	3. tag` `	4. `{ }`	5. TS	6. `&` CTX	7. Ninho	8. Tema	`.css`	10. `<style>`	11. Atomic	12. `className`	13. `<Styled />`	14. `css` Prop	15. AGNOSTIC	16. Tamanho da página Delta
Módulos CSS		✅	✅				✅		✅			✅			✅	-
JSX denominado	✅	?	✅		?		✅			✅		✅				`+2.8 kB / +12.0 kB`
Componentes estilizados	✅	?	✅	✅	✅	✅	✅	✅		✅			✅	✅		`+13.4 kB / +39.0 kB`
Emoção	✅	✅	✅	✅	✅	✅	✅	✅		✅		✅	✅	✅	✅	`+6.5 kB / +20.0 kB`
Typestyle	✅	✅		✅	✅	✅	✅	?		✅		✅			✅	`+2.1 kB / +8.0 kB`
Fela	✅	?	?	✅	?	✅	✅	✅		✅	✅	✅			✅	`+11.9 kB / +43.0 kB`
Pontos	✅	✅		✅	✅	✅	✅	✅		✅		✅	✅	?	✅	`+5.3 kB / +17.0 kB`
JSS	✅	✅	?	✅	✅	✅	✅	✅		✅		✅	?		✅	`+18.2 kB / +60.0 kB`
Goober	✅	✅	✅	✅	✅	✅	✅	✅		✅		✅	✅	?	✅	`+1.1 kB / +4.0 kB`
Compilado	✅	✅	✅	✅	✅	✅	✅			✅	✅	?	✅	✅		`+3.5 kB / +9.0 kB`
Linaria	✅	✅	✅		✅	✅	✅	✅	✅			✅	✅		✅	`+2.7 kB / +6.0 kB`
baunilha-extrato		✅		✅	✅	✅		✅	✅		?	✅			✅	`+0.0 kB / -2.0 kB`

LENDA:

✅-Suporte completo e fora da caixa
? - Suporte parcial ou limitado, menos do que o ideal, ou exigindo algum trabalho manual adicional para suporte total
- Falta de apoio

1. Co-localização

A capacidade de definir estilos dentro do mesmo arquivo que o componente. Observe que também podemos extrair os estilos para um arquivo separado e importá -los, caso prefira.

⬆️ para a visão geral

2. DX

Refere -se à experiência do desenvolvedor , que inclui 2 aspectos principais:

Sintaxe Destaque para definição de estilos;
Concluir/sugestões de código para propriedades CSS suportadas e valores disponíveis (estamos avaliando apenas o recurso de sugestão, não o tipo de segurança);

⬆️ para a visão geral

3. tag` ` (modelos marcados)

Suporte para definir estilos como strings , usando modelos de etiquetas ES:

usa kebab-case para nomes de propriedades, assim como a sintaxe CSS simples;
Permite a migração mais fácil de CSS simples para o CSS-in-JS, porque não precisamos reescrever completamente os estilos;
Requer a instalação do (s) plug -in adicional do editor de código (s) para destaque da sintaxe e a conclusão do código, caso contrário, nosso código pareceria uma string simples;
requer uma etapa adicional para analisar a corda e convertê -la em JS, que pode ser feita no horário de construção (construções mais lentas) ou em tempo de execução (carga útil um pouco maior);

⬆️ para a visão geral

4. `{ }` (Estilos de objeto)

Suporte para definir estilos como objetos , usando objetos JavaScript simples:

usa camelCase para nomes de propriedades, como faríamos no React Native;
Migrar o CSS existente requer uma reescrita completa (não sei como poderíamos automatizar isso);
Não precisamos de ferramentas adicionais para destaque da sintaxe, à medida que o obtemos fora da caixa, escrevendo objetos JS;
Sem as definições TS apropriadas enviadas com a biblioteca, não obteremos a conclusão do código (☝️ Estamos interessados apenas em TS, não fluem);

⬆️ para a visão geral

5. TS

Suporte TypeScript, embutido ou via pacote @types , que deve incluir:

Tipula para a API da biblioteca;
Tipações de objetos de estilo (no caso de a biblioteca suportar a sintaxe do objeto);
Props genéricos, quando aplicável (obtenha acesso à segurança do tipo aos tipos de adereços componentes ao definir estilos dinâmicos);

⬆️ para a visão geral

6. `&` CTX (estilos contextuais)

Suporte para estilos contextuais, permitindo -nos definir facilmente as classes e elementos e consultas de mídia sem a necessidade de repetir o seletor, conforme necessário no CSS simples:

pode suportar o seletor SASS/LESS/STYLUS & PAI;
ou fornecer qualquer API ou sintaxe específica para obter o mesmo resultado;

⬆️ para a visão geral

7. Ninho

Suporte a seletores aninhados arbitrários :

Esse recurso permite grande flexibilidade, que pode ser útil ou necessária em alguns casos de uso específicos;
Lembre-se de que também apresenta muitas maneiras de definir estilos, o que pode causar caos se queremos aplicar boas práticas, escalabilidade e manutenção;

⬆️ para a visão geral

8. Tempo

Suporte interno para temas ou gerenciamento de tokens para um sistema de design.
Não testamos esse recurso , por isso estamos apenas fazendo anotações quais bibliotecas expressam seu apoio em seus documentos.

⬆️ para a visão geral

`.css` (extração estática de CSS)

Os estilos definidos são extraídos como arquivos .css estáticos:

Reduz o tamanho total do pacote/página, porque não precisamos de biblioteca de tempo de execução adicional, para injetar e avaliar os estilos;
Essa abordagem afeta negativamente negativamente negativamente as métricas FCP/FMP quando os usuários têm um cache vazio e positivamente quando têm cache completo;
O estilo dinâmico pode potencialmente aumentar o arquivo gerado, porque todas as combinações de estilo devem ser pré-geradas no horário construído;
mais adequado para soluções menos interativas, onde servimos muitas páginas diferentes e queremos aproveitar os estilos em cache (ou seja: comércio eletrônico, blogs);

⬆️ para a visão geral

10. `<style>` tag

Os estilos definidos são injetados dentro das tags <style> no <head> do documento:

Torna o estilo dinâmico super fácil;
incorre em uma carga útil maior, porque também estamos enviando uma biblioteca de tempo de execução para lidar com estilos dinâmicos;
Ao usar o SSR, os estilos necessários para a renderização inicial são enviados duas vezes para o cliente: uma vez durante o SSR e novamente durante a hidratação;
mais adequado para aplicativos altamente dinâmicos e interativos (página única);

⬆️ para a visão geral

11. CSS atômico

A capacidade de gerar classes atômicas de CSS , aumentando a reutilização de estilo e reduzindo a duplicação:

Isso gera uma classe CSS separada para cada propriedade CSS;
Teremos arquivos HTML maiores, porque cada elemento conterá um número maior de classes CSS aplicadas;
Teoricamente atômico CSS-in-JS reduz o fator de escala de nossos estilos, o Facebook também está fazendo isso;
É discutível se a redução do tamanho total do CSS for maior que o aumento do tamanho do HTML (qual é o delta final)
Teoricamente, se os nomes das classes forem mais curtos que a definição da propriedade CSS, o delta é positivo, por isso estamos enviando menos bytes (também depende muito da compactação, portanto, não é fácil tirar uma conclusão definitiva);
No entanto, basicamente estamos movendo parte dos bytes do CSS para o HTML, o que pode ser mais difícil de armazenar em cache se tivermos páginas dinâmicas do SSRAD;
Além disso, depende muito do que muda com mais frequência: os estilos? ou a marcação?

⬆️ para a visão geral

12. `className`

A API da biblioteca retorna uma string que devemos adicionar ao nosso componente ou elemento;

Isso é semelhante, como normalmente reagiríamos componentes, por isso é fácil de adotar, porque não precisamos aprender uma nova maneira de lidar com estilos;
Para combinar estilos, precisamos usar concatenação de string;

⬆️ para a visão geral

13. `<Styled />`

A API cria um componente de invólucro (ou Styled ) que inclui o (s) className gerado:

Essa técnica foi introduzida e popularizada pela primeira vez por componentes estilizados, daí o nome;
Teremos que aprender uma nova maneira de definir estilos, porque não estamos aplicando estilos a elementos, em vez disso, estamos criando novos componentes que incluem os elementos estilizados;
Isso também apresenta um pouco de indireção ao descobrir quais elementos nativos são renderizados dentro de um componente maior;
Acabamos criando componentes como StyledButton ou StyledList em vez de constantes como button_styles ou list_styles , portanto, sobre nomear é praticamente a mesma coisa;
Como os estilos/nomes de classe não são reutilizados (reutilizamos todo o componente), faz sentido encapsular os estilos dentro do componente e não pensar em dois aspectos diferentes da mesma entidade;
Não é específico do React, também pode ser usado com o VUE;

⬆️ para a visão geral

14. `css` Prop

Permite a passagem de estilos usando um suporte css especial, semelhante a definir estilos embutidos, mas a biblioteca gera um nome de classe CSS exclusivo nos bastidores:

É uma API conveniente e ergonômica;
Esta técnica foi popularizada pela Emotion V10;
Parece estar disponível apenas para a sintaxe baseada em React/JSX

⬆️ para a visão geral

15. Estrutura agnóstica

Permite o uso sem ou com qualquer estrutura. Algumas bibliotecas são construídas especificamente apenas para reação.
NOTA : Algumas bibliotecas como pontos ou documentos de emoção reagem apenas o uso, embora tenham um núcleo que seja a estrutura agnóstica.

⬆️ para a visão geral

16. Tamanho da página Delta

A diferença de tamanho total da página em KB (transferido Gzipped & Minified / não compactado e minificado) em comparação com os módulos CSS , para toda a construção da produção de página de índice usando o Next.js:

Lembre -se de que isso inclui uma página quase vazia , com apenas alguns componentes;
Isso é ótimo para avaliar a sobrecarga mínima, mas não oferece nenhuma visão do fator de escala: logarítmico, linear ou exponencial;

NOTA: Todas as compilações foram feitas com o próximo.js 11.1.0 e os valores são retirados da guia Chrome Devtools, transferidos por rede de rede versus tamanho de recurso.

⬆️ para a visão geral

Observações gerais

As seguintes observações se aplicam a todas as soluções (com pequenas exceções pontiagudas).

✅ Divisão de código

Os componentes usados apenas em uma rota específica serão incluídos apenas para essa rota. Isso é algo que o Next.js executa fora da caixa.

✅ Estilos globais

Todas as soluções oferecem uma maneira de definir estilos globais, alguns com uma API dedicada.

Compilado é a única biblioteca que não possui uma API dedicada para estilos globais no momento, mas é planejado

✅ SSR

Todas as soluções oferecem suporte para renderização do lado do servidor e são fáceis de integrar com o Next.JS.

✅ Prefixos de fornecedores

Todas as soluções adicionam automaticamente prefixos específicos do fornecedor.

A baunilha-extrato é a única biblioteca que requer configuração manual

✅ Nomes de classe exclusivos

Todas as soluções geram nomes de classe exclusivos, como os módulos CSS. O algoritmo usado para gerar esses nomes varia muito entre as bibliotecas:

.heading bibliotecas usam Card algoritmo de hash , exigindo mais computação, mas resultando em nomes idempotentes (por .Card_heading_h7Ys5 :.
Outras bibliotecas usam a contagem , basicamente incrementando um número ( .heading-0-2-1 , .input-0-2-2 ) ou as letras do alfabeto ( a, b, c, ... aa, ab, ac , etc.), tornando essa abordagem mais performante, mas resultando em nomes de classe não idepóticos (não conseguem descobrir se isso possui nenhum dolares em potencial ou não);

✅ Sem estilos embutidos

Nenhuma das soluções gera estilos embutidos, que é uma abordagem mais antiga, usada pelo Radium & Glamour. A abordagem é menos executada que as classes CSS e não é recomendada como método primário para definir estilos. Também implica o uso de manipuladores de eventos JS para acionar as classes de pseudo, pois os estilos embutidos não os suportam. Aparentemente, todas as soluções modernas hoje em dia se afastaram dessa abordagem.

✅ Suporte completo de CSS

Todas as soluções suportam a maioria das propriedades do CSS que você precisaria: Pseudo -Classes & Elements , Media Consultes e Keyframes são as que testamos.

✅ Extração crítica de CSS

A maioria das soluções se comercializa como capaz de "extrair CSS críticos" durante a SSR. Observe que isso não se refere à extração crítica do CSS acima da dobra, como pensamos inicialmente.

O que eles realmente fazem:

Durante a SSR, eles geram apenas estilos para os elementos visíveis da página estática renderizada;
Eles não injetam CSS para elementos que são renderizados dinamicamente ou carregados preguiçosos;

Com CSS 100% estático, na verdade não haveria benefício. Com páginas dinâmicas que renderizam muito poucos elementos no servidor, e a maioria dos componentes é renderizada dinamicamente no cliente, o benefício aumenta.

Exceção : bibliotecas que usam extração estática CSS.

? Métricas de desempenho

Compreender como esses recursos afetam os principais vitais da Web e as métricas de desempenho em geral é um fator extremamente importante a ser considerado, e a maneira como os estilos são entregues ao cliente provavelmente tem o maior impacto, então vamos analisar isso em detalhes.

Além disso, existem 2 cenários diferentes que precisamos considerar:

? Cache vazio : o usuário visita nossa página pela primeira vez, ou um usuário que retorna visita nossa página depois que o cache foi invalidado (uma nova versão foi lançada);
? Cache completo : um usuário que retorna visita nossa página e possui todos os recursos estáticos em cache ( .js , .css , mídia, etc);

1. `.css` Extração de arquivos

As soluções que geram arquivos estáticos .css , que você normalmente incluiria como tag (s) <link> na (s) <head> da sua página, estão basicamente renderizando recursos de bloqueio. Isso afeta muito o FCP , LCP e qualquer outra métrica que se segue.

? Cache vazio
Se o usuário tiver um cache vazio, o seguinte precisará acontecer, impactando negativamente o FCP e o LCP :

O navegador precisa fazer uma solicitação adicional, o que implica uma RTT completa (tempo de ida e volta) ao nosso servidor;
transferir todo o conteúdo do arquivo CSS;
analise -o e construa o cssom;
Isso atrasará qualquer renderização do <body> , mesmo que todo o HTML já esteja carregado, e pode até ser analisado ansiosamente, e alguns recursos já obtidos com antecedência;

É verdade que você pode buscar em paralelo outros recursos <head> (arquivos .css ou .js adicionais), mas essa geralmente é uma prática ruim;

? Cache completo
No entanto, nas visitas subsequentes, todo o recurso .css seria armazenado em cache, para que o FCP e o LCP fossem impactados positivamente.

Pontos -chave
Esta solução parece ser mais adequada quando:

Temos muitas páginas renderizadas do lado do servidor que nossos usuários visitam, talvez até contendo um arquivo .css comum que pode ser armazenado em cache ao visitar outras páginas;
Não atualizamos os estilos com frequência, para que eles possam ser armazenados em cache por períodos mais longos;
Queremos otimizar para os visitantes retornados, afetando as visitas iniciantes;

2. `<style>` estilos injetados da tag

Durante a SSR , os estilos serão adicionados como tags <style> na (s) <head> da página. Lembre -se de que estes geralmente não incluem todos os estilos necessários para a página, porque a maioria das bibliotecas executa a extração crítica do CSS; portanto, esses styles geralmente devem ser menores do que o arquivo estático .css inteiro discutido anteriormente.

? Cache vazio
Como estamos enviando menos bytes de CSS e eles estão inlinados dentro do arquivo .html , isso resultaria em FCP e LCP mais rápido:

Não precisamos de solicitações adicionais para arquivos .css , para que o navegador não esteja bloqueado;
Se movermos todas as outras solicitações de arquivos .js para o final do documento, <head> não fará nenhuma solicitação, portanto, a renderização ocorrerá super rapidamente;
No entanto, eventualmente enviaríamos bytes adicionais, que não eram necessários com extração estática .css :
- a biblioteca de tempo de execução (entre 1,6kb - 20kb);
- Os estilos necessários para a página, agrupados em arquivos .js junto com os componentes, durante a hidratação (isso inclui todos os CSs críticos já enviados dentro da tag <style> tag + outros);
Todos esses arquivos devem ser buscados, analisados e executados para obter uma página totalmente interativa ;

? Cache completo
Quando o cache do usuário está cheio, os arquivos .js adicionais não exigirão buscar, pois já estão em cache.
No entanto, se a página for ssred , o CSS crítico inlinado renderizado na tag <style> do documento será baixado novamente, a menos que lidemos com HTML estático que também possa ser armazenado em cache ou lidamos com o cache HTML em nossa infraestrutura.

Mas, por padrão, enviaremos bytes extras em todas as solicitações HTTP de página, independentemente de ser em cache ou não.

Pontos -chave
Esta solução parece ser mais adequada quando:

Lidamos com SPA (Aplicativos de página única), onde temos uma (ou poucas) páginas SSR;
Atualizamos os estilos com frequência; portanto, mesmo que eles possam ser armazenados em cache, isso não terá um impacto positivo;
Queremos otimizar os visitantes iniciantes, afetando os visitantes que retornam;

? Remoção de código morto

A maioria das soluções diz que remove o código/estilos não utilizados . Isso é apenas meio verdadeiro .

O código não utilizado é realmente mais difícil de acumular, especialmente se você o comparar com os arquivos .css simples, como costumávamos escrever há uma década . Mas quando comparados aos módulos CSS, as diferenças não são tão grandes. Qualquer solução que ofereça a opção de definir seletores arbitrários ou estilos aninhados os agrupará, independentemente de serem usados ou não dentro do nosso componente. Conseguimos enviar estilos SSR não utilizados com todas as soluções testadas.

A remoção de código verdadeira e completa não utilizada é difícil de implementar, pois a sintaxe do CSS não é verificada pelo tipo nem analisável estaticamente. Além disso, a natureza dinâmica dos componentes torna praticamente impossível em certos cenários, especialmente quando a marcação é dinamicamente renderizada:

& span : elementos descendentes;
&:nth-child() : certos seletores de pseudo;
& .bg-${color} : seletores dinâmicos;
.parent & : Seletores de pais;

Basicamente, o que obtemos é a remoção de código quando excluímos o componente, ou não o importamos mais. Esse é um comportamento implícito, porque os estilos são uma dependência direta do componente. Quando o componente se foi, seus estilos também.

? Depuração / inspeção

Existem 2 métodos para injetar CSS no DOM & atualizá -lo do JavaScript:

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

Essa abordagem implica adicionar uma ou mais tag (s) <style> no (s) Dom (no <head> ou em algum lugar do <body> ), usando .appendchild () para adicionar o <style> nó (s), além de .TextContent, .innerHtml Atualizar as tags <style> ).

Usando essa abordagem, podemos ver facilmente quais estilos são adicionados ao DOM, porque podemos inspecionar o DOM a partir de nossos devtools, como qualquer outro nó DOM;
Usando apenas uma tag <style> e atualizando todo o seu conteúdo, pode demorar a atualizar todo o DOM quando realmente alteramos apenas um pequeno conjunto de regras CSS;
A maioria das bibliotecas usa essa solução no modo DEVELOPMENT , porque oferece uma melhor experiência de depuração;
- Typestyle também usa isso na PRODUCTION ;

2. Usando a API `CSSStyleSheet`

Utilizado pela primeira vez pelo JSS , esse método usa CSSStyleSheet.insertRule() para injetar regras CSS diretamente no CSSOM .

Usando essa abordagem, é um pouco mais difícil ver quais estilos são injetados no CSSOM, porque mesmo que você veja o CSS aplicado nos elementos (graças ao suporte do CSS-in-JS no Chrome), ele apontará para uma tag <style> vazia;
- Para ver todos os estilos injetados, você terá que selecionar a tag <style> ;
- Obtenha acesso a ele via $0 em Chrome Devtools (ou obtenha uma referência a ele de qualquer outra maneira, usando a API DOM);
- Access .sheet.cssRules na tag <style> para ver a matriz de regras CSS que ela contém;
Aparentemente, esse método é mais executado que o anterior, durante a atualização de estilos dinâmicos; portanto, a maioria das bibliotecas usa esse método na PRODUCTION ;
- Os ganhos de desempenho se aplicam apenas ao adicionar novas regras CSS ou atualizar as existentes (ou seja: atualização de estilos dinâmicos em tempo de execução);
- JSS e pontos também o usam no modo DEVELOPMENT ;

Sem dedução de componente

Se o mesmo componente for importado por 2 rotas diferentes, ele será enviado duas vezes para o cliente. Isso certamente é uma limitação do sistema de criação/construção, em nosso caso, a seguir, e não está relacionada à solução CSS-in-JS .

No Next.js, a divisão de código funciona no nível da rota, agrupando todos os componentes necessários para uma rota específica, mas de acordo com o blog oficial e o web.dev se um componente for usado em mais de 50% das páginas, ele deve ser incluído no pacote commons . No entanto, em nosso exemplo, temos 2 páginas, cada uma delas importando o componente Button , e está incluído em cada pacote de páginas, não no pacote do commons . Como o código necessário para o estilo é agrupado com o componente, essa limitação também afetará os estilos, por isso vale a pena ter isso em mente.

Módulos CSS

Esta é uma abordagem bem estabelecida, madura e sólida. Sem dúvida, é uma grande melhoria em relação ao BEM, SMACCS, OOCSS ou qualquer outra metodologia CSS escalável para estruturar e organizar nossos CSs, especialmente em aplicações baseadas em componentes.

Lançado em 2015 | De volta à visão geral

✅ Conclusão do código com reconhecimento de contexto
✅ Estrutura agnóstica
Sem estilos/co-localização de componentes
Sem suporte datilografado
Sem CSS atômico
Não há apoio de temas
Métodos de definição de estilos
- ✅ CSS simples
- Objetos de estilo
Estilos nidificações
- Estilos contextuais: (requer SASS, menos ou caneta)
- ✅ Ninho do anfitério
Estilos aplicam métodos (s) (s)
- ✅ className
- componente styled
- css Prop
Saída de estilos
- Extração de arquivos .css
- Injeção <style> tags

Esta é a linha de base que consideraremos ao comparar todas as seguintes soluções CSS-in-JS . Confira a motivação para entender melhor as limitações dessa abordagem que estamos tentando preencher.

	Transferido / gzipped	Não compactado
Tamanho da página do índice	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

JSX denominado

Solução muito simples, não possui um site dedicado para documentação, tudo está no GitHub. Não é popular, mas é a solução interna no Next.JS.

Versão: 4.0 | Mantido por Vercel | Lançado em 2017 | Ver docs | ... de volta à visão geral

✅ Estilos/co-localização de componentes
? Conclusão do código com reconhecimento de contexto : Para obter sintaxe Destaque e conclusão de código, é necessária uma extensão do editor
? Suporte ao TypeScript : @types pode ser instalado adicional, mas a API é mínima demais para exigir TS
Sem CSS atômico
Não há apoio de temas
Não estrutura agnóstica
Métodos de definição de estilos
- ✅ Modelos marcados
- Objetos de estilo
Estilos nidificações
- Estilos contextuais
- ✅ Ninho do anfitério
Estilos aplicam métodos (s) (s)
- ✅ className
- componente styled
- css Prop
Saída de estilos
- Extração de arquivos .css
- ✅ <style> injeção de tags

Outros benefícios

? Suporte para fora da caixa com o Next.js
? Para os estilos de entrada do usuário, ele gera um novo nome de classe para cada alteração, mas remove o antigo

Vale a pena mencionar observações

? Ao contrário dos módulos CSS, também podemos atingir elements HTML e gera nomes de classe exclusivos para eles (não tenho certeza se é uma boa prática, no entanto)
? Precisamos otimizar nossos estilos dividindo estilos estáticos e dinâmicos, para evitar renderizar estilos duplicados
? Os nomes de classe exclusivos são adicionados aos elementos, mesmo que não os alvoemos em nossa definição de estilo, resultando em uma leve poluição sem necessidade de HTML (otimizando isso é complicado, e é muito trabalho para pouco benefício )
? Ele agrupará estilos definidos, independentemente de serem usados ou não, assim como CSS simples
? Não há suporte para estilos contextuais ; portanto, definir pseudo -classes ou consultas de mídia tem as mesmas desvantagens que o CSS simples, exigindo a duplicação de seletores/nomes de classe (é necessário um plug -in Sass para obter esse recurso)

Conclusões

No geral, sentimos vontade de escrever CSS simples, com o benefício adicional de poder definir os estilos junto com o componente, para que não precisemos de um arquivo .css adicional . De fato, esta é a filosofia da biblioteca: suportando a sintaxe do CSS dentro do arquivo componente. Podemos usar quaisquer constantes JS/TS de funções com interpolação de string. Trabalhar com estilos dinâmicos é muito fácil porque é JavaScript simples no final. Temos todos esses benefícios a um preço muito baixo, com uma sobrecarga de pacote muito pequena .

As desvantagens são a experiência geral de escrever CSS simples. Sem o ninho, apoie as aulas/elementos de pseudo e consultas de mídia ficando bastante pesadas para gerenciar.

	Transferido / gzipped	Não compactado
Tamanho da página do índice	79,5 KB	245 kb
vs. módulos CSS	+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

Componentes estilizados

Com certeza uma das soluções mais populares e maduras, com boa documentação. Ele usa modelos marcados para definir estilos por padrão, mas também podem usar objetos. Ele também popularizou a abordagem de componentes styled , que cria um novo componente junto com os estilos definidos.

Versão: 5.3 | Mantido por Max Stoiber e outros | Lançado em 2016 | Ver docs | ... de volta à visão geral

✅ Estilos/co-localização de componentes
✅ Suporte ao TypeScript : @types deve ser instalado adicional, via definitivamente
✅ Suporte de tema embutido
✅ Estrutura agnóstica
? Conclusão do código com reconhecimento de contexto : requer uma extensão/plug-in do editor
Sem CSS atômico
Métodos de definição de estilos
- ✅ Modelos marcados
- ✅ Objetos de estilo
Estilos nidificações
- ✅ Estilos contextuais
- ✅ Ninho do anfitério
Estilos aplicam métodos (s) (s)
- className
- ✅ Componente styled
- ✅ css Prop
Saída de estilos
- Extração de arquivos .css
- ✅ <style> injeção de tags

Vale a pena mencionar observações

? Precisamos dividir estilos estáticos e dinâmicos, caso contrário, ele renderizará a saída duplicada
? Facos estilos aninhados, mesmo que não sejam usados no componente
? Podemos misturar modelos marcados com objetos estilizados, o que pode levar a uma sintaxe complicada e diferente para cada abordagem (kebab vs camel, personagem EOL, citações, interpolação, etc)
? Alguma sintaxe mais complexa parece ser um pouco pesada para acertar (misturando animações com objetos estilizados, estilos dinâmicos com base em variações Props , etc.)
? Para os estilos de entrada do usuário, ele gera um novo nome de classe para cada atualização, mas não remove os antigos, anexando indefinidamente ao DOM

Conclusões

Os componentes estilizados oferecem uma nova abordagem para modelar componentes usando o método styled , que cria um novo componente, incluindo os estilos definidos. Não sentimos vontade de escrever CSS; portanto, vindo dos módulos CSS, teremos que aprender uma maneira nova e mais programática, para definir estilos. Como permite a sintaxe string e object , é uma solução bastante flexível para migrar nossos estilos existentes e para iniciar um projeto do zero. Além disso, os mantenedores fizeram um bom trabalho acompanhando a maioria das inovações nesse campo.

No entanto, antes de adotá -lo, devemos estar cientes de que ele tem um certo custo para o tamanho do nosso pacote.

	Transferido / gzipped	Não compactado
Tamanho da página do índice	90,1 KB	272 KB
vs. módulos CSS	+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

Emoção

Provavelmente a solução mais abrangente, completa e sofisticada. A documentação detalhada, totalmente construída com o TypeScript, parece muito maduro, rico em recursos e bem conservado.

Versão: 11.4 | Mantido por Mitchell Hamilton e outros | Lançado em 2017 | Ver docs | ... de volta à visão geral

✅ Estilos/co-localização de componentes
✅ Suporte ao TypeScript
✅ Suporte de tema embutido
✅ Conclusão do código com reconhecimento de contexto : Para usar a abordagem de componentes styled , é necessário um plug-in adicional do editor
✅ Estrutura agnóstica
Sem CSS atômico
Métodos de definição de estilos
- ✅ Modelos marcados
- ✅ Objetos de estilo
Estilos nidificações
- ✅ Estilos contextuais
- ✅ Ninho do anfitério
Estilos aplicam métodos (s) (s)
- ✅ className (usando @emoção/css)
- ✅ Componente styled
- ✅ css Prop
Saída de estilos
- Extração de arquivos .css
- ✅ <style> injeção de tags

Outros benefícios

? O suporte css oferece grande ergonomia durante o desenvolvimento, no entanto, parece ser uma abordagem mais recente, baseada no React 17 New jsx Transform, e configurá -la não é trivial, difere na sua configuração e implica alguma caldeira (o que deve mudar em breve e se tornar mais fácil)

Vale a pena mencionar observações

? Facos estilos aninhados, mesmo que não sejam usados no componente
? Para os estilos de entrada do usuário, ele gera um novo nome de classe para cada atualização, mas não remove os antigos, anexando indefinidamente ao DOM
? Usar a abordagem styled adicionará 3 kB ao nosso pacote, porque é importado de um pacote separado
? Não sei como dividir estilos estáticos e dinâmicos, resultando em estilos duplicados altamente poluídos para variantes de componentes, especificamente problemáticas para SSR (o mesmo se aplica ao css Prop & componentes styled )

Conclusões

A emoção geral parece ser uma abordagem muito sólida e flexível. A nova abordagem de suporte css oferece grande ergonomia para os desenvolvedores. Trabalhar com estilos dinâmicos e o TypeScript é bastante fácil e intuitivo. Suportando strings e objects ao definir estilos, ele pode ser facilmente usado tanto ao migrar de CSS simples quanto a partir do zero. A sobrecarga do pacote não é insignificante, mas definitivamente muito menor que outras soluções, especialmente se você considerar o rico conjunto de recursos que ele oferece.

Parece que não tem um foco dedicado no desempenho, mas mais na experiência do desenvolvedor. Parece uma solução perfeita "bem-arredondada".

	Transferido / gzipped	Não compactado
Tamanho da página do índice	83,2 kb	253 KB
vs. módulos CSS	+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 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

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 use insertRule() , 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 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.

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

Other benefits

? 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)

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

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

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

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

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 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 ).

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

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 to enforce 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 use insertRule() , 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 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

Other benefits

? using the css 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 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.

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

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

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

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

Other benefits

? 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

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-in variants based on predefined types, or inline 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 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.

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

Tratar

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

the library itself is replaced by vanilla-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 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.

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

Aphrodite

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.

Glamor

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.

Cxs

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.

Astroturf

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.

Otion

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.

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.

Rádio

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

Glamorous

The project was discontinued 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 dependencies
yarn

# for development
yarn dev

# for production
yarn build
yarn 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)

Expandir

css in js

Uma análise completa do CSS-in-TS

Índice

Motivação

Metas

Isenção de responsabilidade

Visão geral

LENDA:

1. Co-localização

2. DX

3. tag` ` (modelos marcados)

4. { } (Estilos de objeto)

5. TS

6. & CTX (estilos contextuais)

7. Ninho

8. Tempo

.css (extração estática de CSS)

10. <style> tag

11. CSS atômico

12. className

13. <Styled />

14. css Prop

15. Estrutura agnóstica

16. Tamanho da página Delta

Observações gerais

✅ Divisão de código

✅ Estilos globais

✅ SSR

✅ Prefixos de fornecedores

✅ Nomes de classe exclusivos

✅ Sem estilos embutidos

✅ Suporte completo de CSS

✅ Extração crítica de CSS

? Métricas de desempenho

1. .css Extração de arquivos

2. <style> estilos injetados da tag

? Remoção de código morto

? Depuração / inspeção

1. Usando tag (s) <style>

2. Usando a API CSSStyleSheet

Sem dedução de componente

Módulos CSS

JSX denominado

Outros benefícios

Vale a pena mencionar observações

Conclusões

Componentes estilizados

Vale a pena mencionar observações

Conclusões

Emoção

Outros benefícios

Vale a pena mencionar observações

Conclusões

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

Conclusions

Linaria

Other benefits

Worth mentioning observations

Conclusions

4. `{ }` (Estilos de objeto)

6. `&` CTX (estilos contextuais)

`.css` (extração estática de CSS)

10. `<style>` tag

12. `className`

13. `<Styled />`

14. `css` Prop

1. `.css` Extração de arquivos

2. `<style>` estilos injetados da tag

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

2. Usando a API `CSSStyleSheet`