There is similar project called Tacit — http://yegor256.github.io/tacit/
Tailwind: style your site without writing any CSS
161–170 of 185 posts
Re: Tailwind: style your site without writing any CSS
#162Earlier quoted context omitted.
> It bites you hard in the long run. How so? If what I need is (as the author describes) to occasionally make a quick relatively-usable site, and I want to do some styling on it, and then forget about frontend UX until I need to do another small site 4 months from now, how will this pattern bite me?
How can you achieve reuse (DRY) with this? Every time I have a button, if I want my buttons to be consistent and have a single place to change them, I have to like invoke a button partial that just outputs my with 20 classes on it? It's a lot easier to reuse a CSS class (an abstraction) than a template of a chunk of HTML (an indirection) -- especially across divides of languages/runtimes/client-vs-server if you have…
I think the article provided good insight on this: "I wonder if the reason this approach makes more sense now is that we’re doing more generation of HTML than we were in 2003. In my tiny example, this approach to CSS actually doesn’t introduce that much duplication into my site, because all of the HTML is generated by Hugo templates, so most styles only end up being specified once anyway."
So you write your button one time in a reusable button component, then reference the component and avoid writing the same 20 styles again. I think this has benefits as it keeps all the information for a single component in the same location, making it easy to understand and edit the component from a single location.
Re: Tailwind: style your site without writing any CSS
#163Earlier 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…
> container styles from earlier might look something like “container mt-5 mb-5 p-20” in one place and “container mb-30 mt-30” or “container bg-dark pt-5”
I've only used Tailwind briefly for some side project, but I thought the docs made it clear that whenever you have a situation where you feel you're repeating styles you should extract them into a new CSS class. There's a whole section dedicated to that in the docs:
https://tailwindcss.com/docs/extracting-components
How would this have been prevented if those same developers weren't using Tailwind and instead simply created .container1, .container2, and .container3?
> Now that we build with small, immutable, scoped components
What do you mean by the word component? Are you talking about a React or component? I don't really see how it's related. It seems like your team quickly iterated and didn't think forward about creating a common look for "containers" until a good amount of development was done. The common look could have been accomplished by extracting the common styles like the above link suggests or creating a common "Container" UI component with isolated styles. The mistake was not thinking ahead and seems unrelated to Tailwind IMHO.
Re: Tailwind: style your site without writing any CSS
#164Earlier quoted context omitted.
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…
> Now that we build with small, immutable, scoped components, its trivial to drop in a new component (or remove it) from anywhere without affecting anything else. Any suggestions for further reading on "small, immutable, scoped components" ? I'm half sure I know what you mean and entirely sure I don't understand it well enough to explain it to somebody else. (thanks for your already expansive reply)
There’s no magic. Remember that at the end of the day, no matter what approach you take to your CSS, we are all dealing in trade offs.
I like to say, that with components, you encounter “a new level of bugs.”
With Functional CSS, you deal mostly with incidental bugs. “This container has margin 10 and this one has 15!” or “This text-red is overriding all my text!” Individually, these are annoying, but together they can compound into unfuckable problems. Right now I’m working on rebuilding a header that was styled with this approach, and ultimatley wound up unable to remove certain classes without breaking other elements. Something as simple as moving the text from one side of the screen to the other involves building an understanding of how they work individually, which is very challenging in a site as large as ours.
Enter my new header, a component. Its got a parent of .HeaderComponent and everything is scoped inside of it. If I delete, say, a .Link here, it doesnt affect links elsewhere on the site. And since I include re-usable mixins for base styles, like text, its easy to (say) @include BodyFont; or HeaderFont; without affecting the page or the site as a whole.
What I mean when I say “a new level of bugs” is that how and why you build things becomes more important. If I build a header component, but a large change happens elsewhere on the site, its unlikely I will change my original component. I’ll make something new and call that, instead.
In this process you can wind up with poorly built components, things that wind up not being used as much as you thought, etc. But the beauty of it is that getting rid of them is SIMPLE. I made a lot of mistakes when I started building doggos.com with components, but I’m really excited about how easy they were to remove. If you just make something new when you need something new, you wont have a bunch of legacy code following you around everywhere.
That probably isn’t a greaaat explanation, but I’m very happy to expand further or give you some links. In particular, Airbnb.design has some great lessons on why they ultimately went this direction, and they do a much better job of explaining it than I!
Re: Tailwind: style your site without writing any CSS
#165Earlier quoted context omitted.
in what way is that consistent tho?
In what way is it not? You'll consistently get 10 or 12 colors instead of getting an inconsistent set of colors, for example.
But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray?
these inconsistencies compound, especially across teams.
Re: Tailwind: style your site without writing any CSS
#166Earlier quoted context omitted.
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…
If there are common elements then you name it and reuse the existing classes. So you are not adding much CSS just naming few conventions.
Mixins FTW!!
Re: Tailwind: style your site without writing any CSS
#167I honestly do not see the point in giving each of my css properties a separate class and then sticking those in my HTML.
If I wanted to do that I would have used the ‘style’ tag.
Re: Tailwind: style your site without writing any CSS
#168It'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…
I’ve tried just about every “modern” method of styling components over the last few years and this is what I still wish for.
Sass and Less has had this functionality for years.
Re: Tailwind: style your site without writing any CSS
#169Earlier quoted context omitted.
Bloating your markup with classes is simply a bad habit. It bites you hard in the long run. Even the framework that they are using proposes better alternatives. “ Tailwind encourages a "utility-first" workflow, where new designs are initially implemented using only utility classes to avoid premature abstraction. While we strongly believe you can get a lot further with just utilities than you might initially expect, w…
Could you suggest how it's bloating the markup and how it'll bite you in the long run? I understand that maybe adding a bunch of classes for every element will increase the overall size of the page but if it's served with gzip compression doesn't it actually (maybe only technically) work better to have repetitive classes everywhere instead of unique class names?
It’s not reusable. It’s not consistent. It’s not scoped.
It may be hard to see now how it will bite you now, but I promise you, it will. It would take hours to explain why, but I am speaking from years of experience here.
There is a reason large organizations have abandoned this approach, and it isn’t just personal preference.
This talk gives a pretty good explanation, Airbnb.design, Netflix, Facebook, and Instagram have many others
Re: Tailwind: style your site without writing any CSS
#170Earlier quoted context omitted.
> It bites you hard in the long run. How so? If what I need is (as the author describes) to occasionally make a quick relatively-usable site, and I want to do some styling on it, and then forget about frontend UX until I need to do another small site 4 months from now, how will this pattern bite me?
How can you achieve reuse (DRY) with this? Every time I have a button, if I want my buttons to be consistent and have a single place to change them, I have to like invoke a button partial that just outputs my with 20 classes on it? It's a lot easier to reuse a CSS class (an abstraction) than a template of a chunk of HTML (an indirection) -- especially across divides of languages/runtimes/client-vs-server if you have…
I agree with the point you're making, but it doesn't seem to address my question. The author describes the usage pattern that I find myself in, and I suspect is relatively common among non-frontend devs: we aren't particularly skilled in CSS or other frontend web dev work, but every now and then we find ourselves wanting to make a quick, simple, but usable site as a landing page for some other project we're releasing.
For people in that niche, frequent tweaks/changes to the styling seem unlikely: I'm going to make the site once and unless it breaks I'm unlikely to come back to the code for it.
The parent comment I replied to makes the direct claim that this class-based pattern will bite me, and I'm curious if somebody can help me figure out how that would happen.