101–110 of 125 posts
Earlier quoted context omitted.
Naming things is notoriously hard, but it's a skill you need to master to make reusable things. You name things that repeat. Think of function names in JavaScript, class names in object-oriented languages, or component names in Figma.
Tailwind lets you stick to just naming your components, don't bother trying to give names to all the re-usable sets of styles
Tailwind is nice because it’s fast and you have a good idea what you’re going to get while writing it. Nobody believes that it’s the pinnacle of performance or maintainability. Keep using Tailwind if you like it and it’s appropriate for your project or business.
Earlier quoted context omitted.
But CSS handles it much better, which is the point. You separate it into a .button class, and then further specialize it by adding more classes (like ".button .button-primary"). With Tailwind everything is duplicated, but with CSS you can move out the common parts.
And to do this with a component framework and tailwind you give your component some props that customize it. With CSS you also have to worry about the cascade way too much, so while you are doing much of the same work with Tailwind, you get the nice benefit of inlining the styles which will actually apply to your component. Yes, you still have to think about organization and how to make different styles apply to vari…
If so; what would be the motivation for using JavaScript to style a button? Call me old - my coworkers do -, but that feels counterintuitive.
Please note that I haven’t really formed an opinion on Tailwind yet. This is an honest question.
Being a designer who does his work inside code, Tailwind is a nightmare. I hand off my design files, the developers do their thing. But then, maybe I want to tweak things after a review, or the design system changes, so I have to do a sweeping change to those buttons. Now I need to touch dozens of jsx/tsx files around the platform and make humongous pull requests, and the result is often dozens of merge conflicts. If…
> ...I have to do a sweeping change to those buttons. Why aren't those buttons encapsulated in reusable components or templates? What sorts of changes do you need to make where this is an issue?
When building a design system, there are a bunch of default styles, and then there are variations based on context. To put it in a real world example, imagine a newspaper heading style that varies depending on where the heading appears. Front page headings are bigger, sports pages might use a different style, and so on. Same with buttons, cards, tabs, what have you.
This isn't impossible to build with Tailwind by adding, say, react logic, but it becomes a mess quickly. If you have a well-built design system, class naming shouldn't be that hard to figure out and communicate to developers. But deciding on a coding logic to account for these context changes and sticking to it seems not as easy, especially when developers come and go.
Earlier quoted context omitted.
> ...I have to do a sweeping change to those buttons. Why aren't those buttons encapsulated in reusable components or templates? What sorts of changes do you need to make where this is an issue?
They are (encapsulated in reusable components). But when the project grows big, Tailwind's shortcomings become apparent, the biggest ones being the loss of context (cascading) – and of course the lack of separation of concerns, when the concerned parties are also separate (developers and designers). When building a design system, there are a bunch of default styles, and then there are variations based on context. To…
Global defaults are a separate matter. As are prose styles / styles for UGC text because you don't know the HTML structure ahead of time - by all means use the cascade here, but for almost but for everything else you have two maintainable options:
1) Some CSS naming system or scoping system, e.g. BEM where you enforce proper naming and selector complexity limits (except in rare circumstances). This is extremely hard to do in the long term on a big project.
2) Leverage the component system / template system of whatever system you're using to make reusable components and use utility styles.
Using the cascade extensively on a long running project is a recipe for maintainability disaster - you will face a wild goose chase for the file you want every time you want to make a change, and then another wild goose chase for unexpected changes because your selectors weren't specific enough.
I'm also pretty strongly of the opinion nowadays that separation of concerns of CSS and HTML is a false separation - the single concern is how a thing looks on the page.
"At some point, hundreds of utilities later, the code you've written doesn't look pretty." Personally I find diving through a bloat of identifiable tailwind classes allows me to review/change/adapt/create UI code MUCH QUICKER than having to re-learn some other abstraction or naming convention that some other developer came up with. Complaining that lots of Tailwind classes "don't look pretty" makes me think the autho…
I’ve worked on some large projects including refactors with Tailwind and my view is opposite. I can see how Tailwind would work on small projects, or ones where the designer never touches the styling inside the code. But on the other hand, avoiding naming because it’s hard isn’t how I approach organising design, and it doesn’t sound like a good approach to coding either. But I can see how there may be a need to bypas…
The snails pace updates on TailwindUI are bad enough, in the time it takes them to release one tiny ~20 line component you'll see half a dozen new and better UI frameworks pop up. But to add insult to injury their obssession with over the top React and Vue usage on the most basic of components just highlights how disconnected from the reality of web development they've become.
It's a CSS framework. I shouldn't be seeing Next, Nuxt, React, Vue or whatever 'hot thing of the week' they're gawping at.
Where tailwind on its own shines is inside a Laravel project with blade components. They are their own individual, reusable and extendable items. Wheather thats better or worse than css classes is up for debate however.
Earlier quoted context omitted.
> ...I have to do a sweeping change to those buttons. Why aren't those buttons encapsulated in reusable components or templates? What sorts of changes do you need to make where this is an issue?
They are (encapsulated in reusable components). But when the project grows big, Tailwind's shortcomings become apparent, the biggest ones being the loss of context (cascading) – and of course the lack of separation of concerns, when the concerned parties are also separate (developers and designers). When building a design system, there are a bunch of default styles, and then there are variations based on context. To…
At one time a web designer could write CSS and HTML, pass it off to a web developer who would generate the HTML in some manner and use the same CSS written by the designer, who could then go in and make changes to the CSS without having to involve the developer or much if any of the developer's tooling.
The separation of concerns is not just about code organization. It is also about people organization.
Your average React component is starting to look like late 90s PHP: an intermingling of CSS, HTML, SQL calls, the kitchen sink, the entire cast of Glee, Kit from Knight Rider and your high school nurse.
Tailwind is write only, you’re not supposed to read it or maintain in. Want to change some property? Delete the entire class=“” attribute and start anew. Take that primary button example from the article - no one is claiming that it’s readable, especially when there are hundreds of primary buttons throughout the app, each with a slight variation. This works great for marketing or landing pages, or other use cases whe…
I modify it all the time so I'm not sure what you're on about. I have a feeling people hate Tailwind for making CSS accessible to the masses.