14 ms·
I'll post one of my previous comments here, hoping to get a discussion going... > The problem with Tailwind for me is that Mr Wathan misrepresented « Good CSS
by emmacharp 4y ago
I'll post one of my previous comments here, hoping to get a discussion going...
> The problem with Tailwind for me is that Mr Wathan misrepresented « Good CSS » in his essay. His examples are BAD CSS, not good CSS. He then sets out to correct a problem with CSS that HE created by writing dirt poor CSS.
`.author-bio > div > h2 { color: red } is NOT good CSS. The div part has no reason being there (why would the div change the color of the title ?). After presenting this auto-created problem, he sets out to solve it with BEM, where you need untold numbers of classes for everything. So now, CSS has a naming problem, created to solve a non-existing auto-created CSS problem. And Tailwind now solves this pseudo-problem.
Apart from this, the thing that really bugs me is that every advantage claimed (apart from one) is also non-existing because if you do your CSS right, the same claimed advantages arise in pure CSS. Design tokens ? No need for json, custom properties are all you need. Specificity ? Cascade layers, pseudo-selectors are here for you.
The only "advantage" I see is the possibility of working in one file only rather than a couple of files. And that, for me at least, is not a real advantage but only a justification for being lazy. There's no way the price of all these processes and dependencies complexity are worth the laziness-added value.
Does someone care to "prove" me wrong here ? At least, can someone engage these arguments ?
Looking forward to it!
- kaba0 4y agoThe problem is that I’m not convinced that “good CSS” even exists. Even the very idea of separating content and style seems problematic to me, and in my experience it simply doesn’t works for anything more complex than a markdown converted to html. Add to it that for some weird reason web’s style includes layouting, which imo should be a separate thing entirely, and this is the primary reason why any given CSS has to be specifically created for a given HTML template, and why seemingly benign CSS modifications can move that 3rd step of the checkout page, rendering it completely broken. Restricting CSS to a subset of only cascading some very basic properties (fonts, colors, default font-size), and letting everything else be managed on a per component basis (where close coupling of style and template absolutely makes sense) and simply layouting those components to form the given design makes much more sense to me (and frankly, it was sort of figured out a few decades ago by several desktop GUI framework..). And while you can write vanilla CSS this way, tailwind just restricts you to this subset — the same way there sure exists some safe subset of C, but you need something like Rust to restrict you to that [1] [1] I know, this is not really how it works, it’s only for the analogy’s sake
- emmacharp 4y agoWhy is the component-based approach to CSS not working here? Am I missing something?
- pcthrowaway 4y agoHow would you maintain a reasonable "component-based" approach without something like scss? I'm legitimately curious. Otherwise, you have to take great pains to ensure styles don't conflict or accidentally apply to things they're not intended for. Or you have to use some other framework/tooling to convert your css selectors and markup so that scoping is enforced
- claytongulick 4y agoShadow DOM works well for this if you need true encapsulation. A blend of shadow and light DOM in web components solves most of the issues I've run into over the years. It's also easy to scope styles to a custom component in the light dom with: my-component .header {...} I do this a lot in light DOM web components and render the styles with lit-html as part of a template.
- quechimba 4y agoThere is also the ::part() selector now which is quite useful for selecting things within a shadow. https://shoelace.style/ https://shoelace.style/ uses parts for styling individual parts within custom elements.
- claytongulick 4y agoIn practice, I've found that to be pretty unwieldy and difficult to use. My general approach is to keep most application level components in the light dom for styling, and only use shadow dom for library-like components, mostly layouts for slotting light dom stuff.
- mhoad 4y ago
- ghc 4y agoNobody's going to engage with those arguments because they miss the point. Tailwind is CSS, ergo it wouldn't work if what you're saying wasn't possible. Writing good CSS for interfaces in a web application of significant complexity is expensive and time consuming. Tailwind solves that problem very well. Other CSS frameworks have done so as well over the years -- I wouldn't call Tailwind unique -- but the micro-class approach it takes is perfect for modern interface templating systems like Vue, where you tend to abstract at the component level instead of at the style level.
- emmacharp 4y agoHow is that better than enclosing CSS in a component file with a class as first selector? I see that bad developers could make mistakes, but besides that, which is kind of easy to lint, the only advantage I see is the need to maintain only one file instead of two. What do I get wrong? edit: syntax
- adamhp 4y agoIt is quite fast to make changes and see immediate visual results. There's basically one less step to making css changes. What you call "lazy" in your OP, the rest of us comfortably call "useful". If I need to add some padding, I slap on some p-4, my browser refreshes, and I see the result. I don't really get the spiritual debate. It's a tool, use it or don't.
- emmacharp 4y agoYou can do the exact same thing with CSS. It does not matter if the code is added to HTML or CSS. And for me, at least, this is not a spiritual debate. On the contrary, this is a very practical debate. The popularity of the tool and the signal it conveys absolutely has consequences on all of the development community. Whether I like Tailwind or not, I have to maintain projects that were done with it, I get asked about it, etc. I think that saying "it's just a tool" is kind of short-sighted. It's a paradigm. And as such, its practical implications are far reaching.
- madeofpalk 4y agoI don't think tailwind is the right solution, mainly because there's just zero type safety with it. The ergonomics are terrible for knowing what options you have available, and whether you made a mistake or not. > if you do your CSS right I think the reality is, when you hit a certain size and scale of developers working on your product, it's next to impossible to do CSS "right". It's just not a skill that's widely shared in large frontend teams - a part of this is that the role of a "frontend developer" is pretty broad now. There's a lot of frontend work where you just don't end up styling things. This is why you might want to abstract out HTML is styled one level up, and then go from there. Having a good framework for people to style things consistently, and then create higher and higher level components for all the common patterns. Personally, I think the better solution for this (as opposed to tailwind, not "let everyone write their own bare css") is something like Vanilla Extract's Sprinkles to create your meta framework for styling with full type safety and editor suggestions https://vanilla-extract.style/documentation/packages/sprinkles/#usage https://vanilla-extract.style/documentation/packages/sprinkl...
- emmacharp 4y agoYes, I see. It's a way of limiting the damage done by careless CSS developers. But couldn't these mistakes be flagged easily through linting only?
- madeofpalk 4y agoOutside of agency land building bespoke brouchure websites, I've never seen companies hire "CSS Developers". Closest would be hiring developers to work specifically on design systems/component library. I think it's useful to think about analogies for other parts of the tech stack. You probably don't want every backend developer writing SQL by hand every time you interact with the database, so you create various levels of abstraction on top of that to "limit the damage done by careless SQL developers". The negative sentiment ("careless CSS developers") isn't necessary. It's not about fixing the problems from bad developers doing bad things, but just giving people better alternatives to make it not possible for anyone to do "bad" things.
- davnicwil 4y agoMaybe it's less about representing good/bad CSS and more about representing the CSS people typically write in the wild. I guess if people only wrote really good CSS in the wild, or hey even agreed upon what it looks like, there would be no need for tailwind, that's true. But that's not reality.
- emmacharp 4y agoI see, yes. But could we not care and try to use this native language as it was designed instead of short-circuiting it by slapping costly dependencies on top of it? Wouldn't it be a better approach considering, among other things, the coming ressource optimization in HTTP3?
- that_guy_iain 4y agoI'm using tailwind in one of my projects. As a normally backend dev, I find tailwind rather weird. It seems very much like it just gives you classes for every css property&value match. It seems very much like I'm just writing the css but in a different way. cursor-pointer class for "cursor: pointer" for example. However, I find the responsiveness side of things very useful.
- tough 4y agoYeah that's precisely what it is at the end of the day
- emmacharp 4y agoWhat do you mean by responsiveness?
- that_guy_iain 4y agoYou can use md:class-name so that when the screen size is the size for medium then that class will be used. An easier way to do the screen size stuff.
- emmacharp 4y agoEasier, like in less characters? Because I wouldn't say using CSS media queries is hard.
- that_guy_iain 4y agoIt's not that hard but it's more work than I would like to do as a backend developer. Realistically, I want to put as little work as possible in to frontend and focus on backend.
- pcthrowaway 4y agoYeah, tailwind isn't intended to make it so you don't have to learn CSS. It very much tries to map to CSS fairly directly, so it wouldn't prevent you from needing to learn it. > I'm just writing the css but in a different way. cursor-pointer class for "cursor: pointer" for example. The difference is, when writing the CSS yourself you also have to find a way to apply this to the thing you want it to apply to. Which means you have to write your own selector. Which gives you 1000 guns pointed at your feet, and maybe two aimed away from you (and one of those is just the same one that tailwind gives you, but less portable).
- swyx 4y agoi think you're kinda proving his point. it's easy to write "BAD CSS". I write "BAD CSS". you may be so good you only write GOOD CSS. i'm not. I may never be as good as you. tailwind is a framework for people like me. (there are lots like me)
- emmacharp 4y agoCSS is really not that hard to understand and use adequately. And as I said here, linting should be more than enough to nudge you in the right direction, CSS-wise. Or maybe you don't like CSS at all?
- pcthrowaway 4y agoAre you managing the entire front-end stack? Or just design?
- emmacharp 4y agoIt depends on the project. More HTML and CSS than JS. But, as I said, the team has been generally using the Tailwind paradigm for 5 years now. The team has also been divided for while about it. Heheh.
- mhoad 4y agoI also used to feel like the comment you were replying to. About two years ago I decided to try and lean in heavily towards “modern” CSS and honestly things have gotten so much better the past few years. I also leaned in heavily to the component model with Web Components which was another huge win for my experience with CSS. I actively enjoy it now rather than dread it. Catching up wasn’t too difficult and if someone else is in the same boat I would recommend the investment.
- emmacharp 4y agoMy thoughts exactly!
- deleted 4y ago
- hoofhearted 4y agoI posted your thoughts on the Tailwind chat. I’m trying to push Adam or one of the other leads to come on and post a proper response. I completely disagree with your opinion, as well as numerous other Tailwind developers lol. Your opinion of Tailwind is kind of the like what the person who may have believed the flat head screw was the way when they introduced the Phillips head screw. Both types of screws are great tools, but a Phillips head may have seemed less superior to you because you didn’t understand its purpose and value.
- emmacharp 4y agoThat's great! I'd love to have a proper response as you say. As for your analogy, I'm not convinced it's adequate. The Phillips screwdriver does not reinvent the way to turn screws as Tailwind does here with styles. The Phillips screwdriver does not add complexity in the building of houses.
- hoofhearted 4y agoThey aren’t reinventing the way you write styles. Tailwind is actually just a CSS design token and utility class library at its core. It’s the Bootstrap of the 2020’s. Regarding design tokens, they are taking notes from 1996, and they realized that it is much more computational efficient to describe your component visually with inline styles compared to loading separate style sheets. Tailwind and CSS design tokens in general make it easier to make smart, efficient choices from curated palettes. Design tokens also create a common language for everyone who uses Tailwind - both across teams and across projects, which can break down communication barriers in large scale projects.
- emmacharp 4y agoI agree wholeheartedly about design tokens. I use this in every project, always. But I only need custom properties, nothing else. And I get all the advantages you're describing. And I'd say that striping the cascade, removing selection and specificity and implementing new ways to do the same things (ie: peer-[:nth-of-type(3)_&]:block) is indeed reinventing our use of CSS.
- enkrs 4y agoMaybe one point not raised enough in the eternal discussion between Tailwind vs CSS properly is the cognitive load of naming and organizing things. To do CSS properly, you need to name classes, you need to come up with CSS cascades that work. Being programmers we would love to categorize and name things all day long. Ever heard how we over-engineer things because of the DRY principle? But we would love to name classes and do CSS properly only theoretically. In practice, we run out of time making CSS with nothing to show a week into the task except a CSS kitchen sink demo. By the time we're done, the scope of some component has grown in a way we did not expect and is hard to represent without markup change. Tailwind on the other hand removes the task of thinking how to name the thing we're making. A appbutton appbutton--state-user-notallowed or a touchbutton touchbutton--disabled? In Tailwind it's just a a blue-600 rounded rectangle. Scope changed? No problem, now it's a green-400 shadow special rectangle, without checking where else it was or will be used or coming up with a new name for this special rectangle. It's just faster. Not strictly better.
- emmacharp 4y agoThe naming of every little thing in CSS is what I call a "pseudo-problem" in the original post. You don't have to name classes for everything inside a component. You only have to name the component, as in Tailwind. Afterwards, tag selection is totally fine. And with all the new CSS pseudo-selectors it is now easier than ever to be styling with low specifity while including markup options.
- ethanbond 4y agoIf you don’t name it then it’s sensitive to DOM changes which can look completely inert in the file in which they occur. Have you actually used Tailwind for a week or more?
- emmacharp 4y agoYes I have. For a couple of years and my team still uses it. But Tailwind is sensitive to DOM changes too, since every style is on tag. You wouldn't remove any tag without understanding its usage in a component using Tailwind. Why would you treat a CSS component any other way? If a tag's there, it must be used for something. Again, I may miss something but I see that as normal care and dilligence in both ways. On a sidenote it's now easy to include, for example, all headings to be styled the same in a component, thereby limiting the need to adjust the CSS in case of a change of tag. There are many ways now to leave markup options opened if need be.
- mfsch 4y agoThe way I see it, the problem is the C in CSS. If you rely on `.author-bio > h2`, then every time you make a change to `.author-bio`, you have to consider all the contexts in which this class may be used globally in your site, and if you change the styles for `h2` even more so. Sure you can say you encapsulate every context with a globally unique id, but since you’re probably already using some kind of templating system for you HTML, it’s easier to specify the styles there. It’s basically the difference between having variables scoped global vs. local by default.
- emmacharp 4y agoThe « > » part should not be necessary 90% of the time. And while using Tailwind, I still have to know where I include my components. I still need to test different instances in different places. With that in mind, I don't see the added benefit of Tailwind here (again, other than limiting the damage done by careless devs). Maybe I'm missing something?
- waldothedog 4y agoNo argument here. But I believe, as others have suggested, that Tailwind is for people who have given up on (or aren’t motivated enough to pursue) the idea that they can /ever/ learn CSS. Adopting Tailwind is easier than thinking about CSS, even if they end result is (IME) just as wonky and disjointed as a ‘bad css’ implementation
- ch4s3 4y agoI can see where this comes from, but in my case Tailwind is nice because while I know a good deal about CSS it is far from my core competency. Tailwind offers me a well organized toolbox of things that are all good enough, but more importantly easy for me to use pick up and use occasionally. It is also something that I can work in with both FE and BE engineers, it provides a nice lowest common denominator.
- waldothedog 4y agoHmm, ya know after thinking about your reply… I could see there being a way of executing TW that increases the chances of higher quality FE—-and probably make refactoring safer and more systematic to boot. Unfortunately, I haven’t experienced this :/ (yet)
- datavirtue 4y agoPartially true. I had (once upon a time) mastered CSS to the point of being able to make pixel perfect documents. I understand CSS, that is WHY I use Tailwind. CSS is the low level language of styling. For the same reason I use C# or Javascript instead of assembly language or C, I need to get shit done.
- ianbutler 4y agoI think most developers simply don't care about this, I know I don't*. I don't see CSS as some beautiful thing I should tweak and spend time naming and doing "right". I want to be able to slap some class names onto things that quickly make it look the way I want, with a system I know others will be able to grok almost immediately with a high level of consistency and get back to building the features that are actually going to attract customers and generate more value. The advantage of Tailwind is commoditizing CSS into something no one has to really think about as deeply as you're suggesting we do. Someone who cares to can do that thinking and put it into a Tailwind class in one of the versions. It's also portable, in that anyone who works with Tailwind can come in and immediately contribute, instead of figuring out whatever structure we've built ourselves. Tailwind provides me a lot of value in that it lets me continue building while providing a very nice UI (which is required in modern times) and not having to engage too deeply with styles, because I'm not trying to be a master of CSS, I'm trying to build a wholistic product and I have 500 other things I need to do. * I'm a backend guy but recognize I need nice UIs.
- emmacharp 4y agoWell, I wouldn't say it's about CSS being a "beautiful thing". It's about delivering great experiences to our users, experiences that use our native tools in an optimized way. Because, you can ship the same experience with less code, less dependencies, less complexity. You can better serve users by easily catering to their preferences via the cascade. You can make use of new technologies that increase performance (see, among others, HTTP3). You can profit from the newest supported CSS properties that are way more expressive and give you more flexibility for cheaper. It's about trying to do the right thing.
- lcnPylGDnU4H9OF 4y agoIs there a way to implement responsive inline styling (e.g. class="flex-col lg:flex-row") in pure CSS? I remember thinking a lot about what Tailwind offers and I came up with that and a vague sense that I probably just don't know CSS well enough to have an opinion I'm comfortable with. Edit: I guess this question kinda doesn't make sense. There's a lot of CSS syntax that isn't available inline in the style attribute and the example I gave can be done with "traditional" CSS classes. The thing I'm really considering is how one can semantically choose HTML elements while using small bits of inline "styling" (read: atomic CSS classes masquerading as styles) to change the properties which need changing and forego CSS otherwise. Anyway, ultimately I don't think that's necessarily better than other styling implementations.
- andrei_says_ 4y agoI think another advantage of using the framework is that one does not need to learn CSS in depth and in detail. I have learned CSS and absolutely love the cascade. If I hadn't, and was on the clock, I'd consider something more shortcut-like, even if it's less precise. If I was using React, writing components in the way SPAs require, Tailwind could make more sense. SPAs fragment code into such little pieces, that thinking about CSS as a whole becomes less necessary. But, I do know CSS, I have adopted the ITCSS code structure, I do have the Tailwind colors in my SCSS codebase, use the Utopia fluid typography and spacing scales, and with grid, container queries, flexbox, gap etc. life is good. CSS is fun.
- emmacharp 4y agoIt is, as of now, the only argument I've read that sticks. Lots of devs do not like CSS. And this is a way for them, as you said, to skip understanding the language. But, is it a "good" argument though?