141–150 of 185 posts
Earlier quoted context omitted.
Easier just to quote the reason he gives: “With inline styles, there are no constraints on what values you choose... Utilities force you to choose... You can't just pick any value want; you have to choose from a curated list. Instead of 380 text colors, you end up with 10 or 12.”
in what way is that consistent tho?
It's 2018, does CSS supported by modern browsers still lack the basic building blocks of reuse? Why am I being asked to choose between class="resources" (and having to know how to center a div in that resources class) and class="t:center t:wide-margins t:light-bg" (which is basically reintroducing all the harm of style tags). Why can't I, in 2018 and with vanilla CSS, say: .resources { @include .centered @include .wi…
In 2018 with postcss, you can have the following: .resources { @apply centered wide-margins light-bg; } And that's exactly what Tailwind is about, btw! Sadly, as you point, it's not vanilla. It works, though.
:root {
--toolbar-theme: {
background-color: rebeccapurple;
color: white;
border: 1px solid green;
};
}
.Toolbar {
@apply --toolbar-theme;
}
Earlier quoted context omitted.
Nothing when everything's a one-off and you only have one supported theme. But if CSS is your component model (e.g. a card is always just a div but with a special style) then you'll have "centered wide-margins light-bg dropshadow" on every one of those divs, rather than just class="card". Similarly if you want to have two different themes with the same DOM, you can't do so easily.
Nobody who uses Tailwind would suggest copying the same classes over and over again in the example you’re talking about. You would either still create a card component (Tailwind does have the concept of components), or if you were using a framework like Laravel you could create a card blade component that held the tailwind card classes in one place.
Everytime I see Tailwind/Tachyons/Functional CSS at the top of HN I die a little inside. I've said it before and I'll say it again: if you actually like this kind of CSS, you probably don't work on large websites. And when you do, the reason people hate it so much will become abundantly clear to you. Functional CSS makes for an unscaleable, inconsistent, unmaintainable dumpster fire of styles that is objectively wors…
Earlier quoted context omitted.
The benefits absolutely do not outweigh the cons. For starters, your CSS can never compile down to a smaller size than component CSS - ever. Because of the nature of compositional classes the plateau of problems expands out almost infinitely, and the resultant inconsistencies necessitate new overrides, more code, more complexity, more misdirection. What size site do you work on? How often do you have to completely ch…
Co-author of Tailwind CSS here. Prior to building Tailwind, I followed more traditional approaches to writing CSS, like BEM. In fact, I remember when BEM first came out, and people hated it too. I've worked on small projects, and very large projects. I recently rebuilt a large web app using Tailwind, and my resulting CSS was TINY. I use Tailwind in conjunction with Purge CSS. The resulting filesize was 8.1kb gzipped…
We accomplish this in our web app (over 500 kloc) by simply giving each component’s top-level element a unique, formulaic, memorable CSS class (which is very easy to do with SASS/SCSS). And each component gets its own CSS (or .scss) file, HTML file, JS file(s), and I18n directory. The app loads each component’s CSS when that component is loaded at run time (which could be during startup or later). I just don’t see how one could get more straightforward than this for a large app.
We do have some classes that are included in the base-level stylesheets and shared among components, but we only use those when it would result in less code than not, or when necessary for themeing.
It may take a lot of effort to build this kind of architecture, but once you’re there it’s a breeze to create, compose, and maintain UI components.
Earlier quoted context omitted.
> Because you'll have 29 different margins, 67 different left paddings, etc all over the place. That's not really the case since SCSS became a thing. If SCSS doesn't help you, Tailwind won't, you can ignore their classes just as you could ignore preset constants. Honestly, to me it seems like people are just starting "fresh" with a benefit of some experience, and ascribing the benefits of experience to the tool.
I've used SASS for years, and yet switching to tailwind felt reaaally nice. have you tried it for yourself, or are you just assuming that you understand the practical differences?
Earlier quoted context omitted.
I'd love it if you expanded on that last comment - my instinct is that functional CSS is a footgun, but I'm not nearly good enough at CSS to really be able to unpack that into concrete problems it causes.
Sure thing. Due to an NDA, I can’t get into granular detail about the site, but I’m more than happy to expand on the problem. When I started here, I sort of “inherited” a large stylesheet written in the classic BEM/Tachyon style of CSS. I can see why the author chose this method, because at the time the website was small and functional classes seem like a really good thing, as they help you get up and running quickly…
Earlier quoted context omitted.
In 2018 with postcss, you can have the following: .resources { @apply centered wide-margins light-bg; } And that's exactly what Tailwind is about, btw! Sadly, as you point, it's not vanilla. It works, though.
If i'm looking at the right thing ( https://github.com/pascalduez/postcss-apply ), it looks like you can only @apply property sets in name variables, like so :root { --toolbar-theme: { background-color: rebeccapurple; color: white; border: 1px solid green; }; } .Toolbar { @apply --toolbar-theme; } Rather than arbitrary CSS classes?
Tailwind comes with its own @apply: https://tailwindcss.com/docs/functions-and-directives/#apply
This is not for me. I am very good at, and very comfortable writing CSS since I've been doing it since the CSS Zen Garden days. But I understand the pains this is trying to solve and I think that this is the wrong approach and also the wrong abstraction. - If you don't like CSS, this will not help you write less CSS, it will only make you write it inline and using a weird syntax. - If you want to do the sensible thin…