Do tell, please? Or is this more about how LiveView cannot do some of the things that Hologram can?
dimitarvp
derek-zhou
I used to use Tailwind. Now I prefer to hand write all my CSS. To me, the value of Tailwind is not worth the technical debt it would bring.
8
garrison
It’s too much of a digression to get into here. I’ll be posting about my apps very soon (for real this time unironically, the database has been slayed) and I can discuss it there with specific examples.
But tldr nothing I haven’t posted about before, specifically with regard to component composability. The only difference is I now know how to properly design a reactive framework (literally React-ive) and I can see where the problems actually lie in LV’s engine. These are things that could be fixed but it would be nontrivial. The (heroic) work by Jose and Steffen to diff :key properly was a big step in the right direction.
2
dimitarvp
Can I read more about this somewhere, please?
Your point about a longer answer being a digression is well-received, thank you.
1
sreyansjain
woylie
We’re using SCSS. The setup is based on Barker, with variations. Design tokens are defined with Style Dictionary, which supports different output formats and also allows to define custom output formats. This allows us to separate the canonical design token definition from the actual implementation. You might need the same tokens in a different format for a native app, for example.
Barker includes a couple of SASS functions for accessing the exported design tokens / variables (although you can also use the exported SASS variables directly; SASS variables and functions map to CSS custom properties, not values, making it theme-able), and generates a couple of utility classes based on them for one-off styles. Most styles are defined on a component level, though. Styles are separated between components (what is the thing, e.g. a card) and layouts (how is the thing arranged, e.g. a card grid) as much as possible. We also use some of the layouts as described in the already mentioned Every Layout.
As for why I don’t like Tailwind: I don’t think it solves the problems it claims to solve. It introduces new problems. It drags you away from standard CSS. Vendor lock-in (ever tried removing Tailwind from an existing project?). There are plenty of articles pointing out the issues in more detail, for example:
5
CharlesO
garrison
This PR was the bulk of it, I think. There was some other related activity if you look for PRs around that time.
The first version of the :key optimization (which is itself a very important addition) essentially expected global keys (because LiveComponents use global keys) which is a massive footgun. Somebody (me) complained that it wasn’t composable and apparently created multiple weeks of work for poor Jose and Steffen (sorry). They pulled it off, though!
Reading through that PR and the new engine code is on my todo list because I still don’t actually know what dark magic they invoked to get it to work 
2
sodapopcan
What have you experienced in this regard? I have not used Tailwind on a massive project before, but one thing I like better about Tailwind is that I find it much easier to determined what is actually being used. In my experience, projects using vanilla CSS have a tendency to accumulate pointless rules that no one is 100% if they are required or not.
4
derek-zhou
I don’t have a massive project either. I agree that dead code accumulation is a potential issue with hand written CSS; however, I am not going to write that much CSS to cause real pain.
2