141–150 of 164 posts
This should be called "Don't use Tailwind in a React library for a design system" as this really has nothing to do with Tailwind and is all about integration of Tailwind into a React design system. None of these "negatives" are "negatives" for using it as part of a standard HTML/CSS website outside of React. The comparison between readability of a bunch of divs and web components or react makes no sense, of course is…
But of course, there are situations where it becomes unwieldy. I'd wager that a lot of the problems people have with Tailwind are more social in nature. Which are valid problems! It just means that you need some other solution for that. Analogously, many of the benefits of static typing are social in nature; notably in enforcing interfaces between teams. I suspect people are looking for a similar thing for CSS. But that doesn't invalidate the use cases where Tailwind is particularly handy.
Earlier quoted context omitted.
> "but nobody writes React like that" If it's "possible" people WILL write code like that. That's why I like styled-components, you are FORCED to separate the style definition and then you can say nobody writes code like that. But dozens of style classes mixed with functionality? People DO write code like that, a lot more than I like admitting seeing myself.
This is why I have a hard time getting on the Tailwind bandwagon. It feels like a pipeline equivalent to "margin: 1px 0 0 4px;" and other element-specific stylings _everywhere_. CSS brought some opportunity for structure. At least it started out as "define a common style for a thing", and then if you really wanted to make a small deviation you could inherit and override something from the class. Could be that since I…
It can get messy pretty fast but I find once you sorta get a handle on the frameworks, it becomes easy to parse as long as people aren't doing 10+ classes per element.
I've found working without a CSS framework, people will tend to re-invent the wheel 100 times. i.e. I've seen "padded-box" and "box-with-padding" classes.
I experience the worst of the worst tho, as I do a lot of refactoring work, so my take is a bit bias haha.
Earlier quoted context omitted.
tbh, tailwind feels like the worst thing that happened to frontend dev since coffee script.
Have you seen "The modern way to write TypeScript"? https://github.com/DanielXMoore/Civet *runs for cover*
Earlier quoted context omitted.
> Tamagui actually does solve all four of the mentioned problems in the article. How? The very first example in Tamagui docs is this: export const Circle = styled(Stack, { backgroundColor: '$background', color: '$color9', borderRadius: 100_000_000, variants: { pin: { top: { position: 'absolute', top: 0, }, }, size: { '...size': (size, { tokens }) => { return { width: tokens.size[size] ?? size, height: tokens.size[siz…
That example doesn't use shorthands to be more clear, and shows the styled utility function which is a more advanced case of wanting to define a group of styles nicely. Which is incidentally fixing a couple of the problems in TFA. If you just want the simple Tailwind experience you can use shorthands only in those, or even closer just import or directly and use shorthands with typed tokens. It's there in a few of the…
This should be called "Don't use Tailwind in a React library for a design system" as this really has nothing to do with Tailwind and is all about integration of Tailwind into a React design system. None of these "negatives" are "negatives" for using it as part of a standard HTML/CSS website outside of React. The comparison between readability of a bunch of divs and web components or react makes no sense, of course is…
I do write like that. Heck, even a mix of both: , using Chakra-UI [1] (not too dissimilar to Tailwind in spirit). Even the best design system needs local overrides to satisfy a product owner's incomprehensible requests, like "can we push that button a few pixels to the left?". [1] https://chakra-ui.com/
In a design system. You specify variants of a component. Each one has its own combination of style defined by the design system.
You do not set „Gap“ to 2. you would specify smth like „small“, „medium“ or „large“ as props.
This is not a tailwind issue.
Earlier quoted context omitted.
I find that using utilities where appropriate is a win, not everything need be extracted into a stylesheet or component. Having a standard library of utilities makes sense because if you don't use one you end up writing the exact same thin since they are mostly one liners. What I don't understand is why you'd want to build a design system component out of utilities much less build everything out of utilities.
Here's an example that might give an idea: https://tailwindcss.com/#component-driven
Earlier quoted context omitted.
Yea I’ve used and I think it’s cool for prototyping quickly but the idea of coming back and making edits to it in production code a year from now terrifies the bejeezus out of me.
If you apply it to a component that you reuse then how is it unmaintainable?
In most organizations I’ve been in components are used in applications that share a brand identity/style. Even if there are different brands consistency matters for each brand’s look/feel.
If styling is to be consistent then it’s way more maintenance to change each component to reflect branding changes than it is to have the brand/house style defined in one place and passed into the components.
E.g. decide that all the outlines around inputs, certain boxes etc. are going to be wider - that’s something you probably want to be able to change in one place not 20 or 100 down the line. Sure you “could” find and replace for some stuff but that could easily match the wrong stuff if you use tailwind on something big/complex… at least that’s my concern looking at it for stuff beyond quick prototyping.
Earlier quoted context omitted.
If I were to look at your code (or revisiting my own after some time) I'd know what was likely for straight away. But I would need to construct the likely intent of the version in my mind. Of course you could abstract those classes into one that provides semantics;
I meant SideBarItem's implementation is the tailwind div, but is referenced as SideBarItem like any other React component, not that the tailwind div is pasted all over. :)