Só usei ele em projetos pessoais, então não lidei com o problema de escala.
Considero-o um "css inline" gourmet (sem conotação negativa). Dito isso, eu gosto dele.
Só usei ele em projetos pessoais, então não lidei com o problema de escala.
Considero-o um "css inline" gourmet (sem conotação negativa). Dito isso, eu gosto dele.
CSS inline gourmet é uma das melhores definições que já vi. Captura exatamente o que Tailwind é: inline com sistema por baixo. Em projetos pessoais a escala não aparece e você fica só com os benefícios de velocidade. O problema real começa quando você tem um designer com opiniões fortes ou um design system que diverge dos defaults do Tailwind. Aí o gourmet vira briga. Nos projetos pessoais que você usou, chegou a usar algum plugin para customizar os tokens, ou ficou só com o padrão?
Fiquei no padrão (com formulários), mas cheguei a usar o de aspect ratio uma vez.
E, como alguém da época das tabelas, confesso que acabo sempre tendo meus arquivos scss para quando fica muito chato escrever dentro do framework.
Mas voltando para o artigo, concordo demais com a máxima que a componentização resolve esse problema. Até porque componentização resolve quase qualquer problema, né haha
O escape para SCSS quando fica chato é honesto e provavelmente é o comportamento certo. Forçar tudo dentro do Tailwind vira custo maior do que o benefício. A combinação dos dois faz sentido: Tailwind para o sistema base, SCSS para os casos que fogem. Quem vem de tabelas tem uma perspectiva boa sobre o que CSS resolve de verdade versus o que é abstração em cima de abstração. Componentização resolve a maioria dos problemas sim, mas só se você componentiza na hora certa. Você tem algum critério pra decidir quando um trecho de Tailwind virou complexo o suficiente para extrair?