291–300 of 448 posts
Earlier quoted context omitted.
https://windicss.org/ does it It also seems that the major speed improvement in Tailwind is inspired by windi
I looked into windicss before and didn't see the attributify mode https://windicss.org/features/attributify.html It's exactly what I was looking for, Thanks!
Last time I tried the jit or purge mode, some classes were missing randomly each build and broke my site. (I followed their purge rules very carefully). The worst thing is it ONLY happens on the production build. I like Tailwind CSS and I really hope they make it stable.
I'm not sure I get Tailwind still. Doing everything with utility classes and OOCSS / BEM are things we stopped doing literally decades ago. CSS modules still seem to solve every problem Tailwind solves, and better. CSS modules combine the power of global utility classes with locally styled components/locally scoped classes, and compile to static stylesheets, a requirement for performance. I'm not sure how Tailwind wo…
Earlier quoted context omitted.
Or make a Button component in your framework of choice. function Button = ({ children }) => {children} Create Edit // Same style Delete // Same style
No, we don't want all of the buttons to look identical. Some are big and some are small; some are bold and primary and some are muted and secondary; some have icons; some have shadows; some are disabled, etc, etc. It's easy to make them identical. The challenge is to be as flexible as necessary in a mature application, while minimizing verbosity and complexity. In my experience Tailwind hurts more than it helps here.…
Earlier quoted context omitted.
The difference is you type that lingo inline into the HTML instead of in separate files and you don't have to come up with any class names.
Coming up with variable/class names is one of the most annoying aspects of programming, so any way we can eliminate that task I think is always going to be a productivity boom
I tried Tailwind (and a similar project Windi) on a few projects now and have some findings. Tailwind aggressively speeds up development time of components by allowing me to stay in the same cobtext when styling things. The brevity of class names also dramatically shortens the time spent writing styles. While working on the projects I'd setup with Tailwind, I felt far more productive. However, those were new projects…
It's been an absolute dream in a decent-sized project so far, and even with some refactors.
Regardless, it's not everyone's cup of tea, but depending on the UI framework of choice and the flavor of CSS you use, YMMV when it comes to dev experience.
In Vue or Svelte, I wouldn't even use a CSS-in-JS solution because vanilla Tailwind to compose utilities into localized classes is a straightforward approach.
I'm ambivalent about Tailwind, but I've used it a lot. I will say the hypothetical advantages are mostly the following: 1. It's a step function over CSS units. This is the biggest strength, just standardizing that your design uses padding of 2, 4, 8px, but not 1px, 3px, or 1.23123em :). It provides more steps than you need, but still it's good that the core of Tailwind is a design system with defined unit and color v…
>This works okay in extremely componentized web apps. It's a nightmare if your UI isn't highly componentized. I've seen projects where you make a button by copy pasting this ~80 character string of tailwind classes all over the place, and then changing the color names if you need to. Good luck fixing that when the designer decides that we don't want any buttons to have rounded corners anymore. That app is done wrong.…
Earlier quoted context omitted.
Aside from all of this. Try to use tailwind for 1 side project. You’ll see the difference of productivity when you remember most of the tailwind classes as opposed to having to open another css file, create a class, then reimport them. I just can’t go back without tailwind.
I used Emotion for a few years (CSS-in-JS). I was so in love with it that I never thought I'd change to something else. But Tailwind converted me. I can't go back either, it's too powerful.
It sits on top of Styled Components or Emotion (your choice), and uses your project's Tailwind config faithfully, minus a few of the plugin features.
It eliminates the need for JIT or PurgeCSS because it compiles Tailwind's utils with a drop-in Babel macro, eliminating the need for PostCSS.
As a lover of vanilla Tailwind in Vue and Svelte projects, Twin Macro has made using it in React 10x better and I haven't looked back! :)
Earlier quoted context omitted.
Based on what you've said, you're right, you don't understand it...the things you're comparing it to don't really make sense. Bem doesn't make sense to compare and neither do css modules. Tailwind is a stylesheet with css classes that do atomic things like changing border radius. It gives you a set of classes that allow you to build just about anything you need with just classes. When you compile an app that uses tai…
I (not OP) get all of these, incl. the relief of not naming things. But I still prefer naming things to the class soup and the excessive repetition. ITCSS (Inverted triangle CSS) works with the cascade and results in clean, minimalistic CSS files. I do not build SPAs though and do get that quick styling works really well for that scenario. I do import Tailwind colors, spacing and sizes in SCSS maps for easy access an…
Earlier quoted context omitted.
.button is the default .button-context is the context version className={isContext ? ".button--context" : ".button"} ---- alternatively if you want many unrelated base rules that aren't color/padding as a baseline: .button contains base rules .button--default default color/padding .button--context contextful color/padding className={`.button ${isContext ? ".button--context" : ".button--default"}`}
Yeah, sounds sensible. What I've been doing so far was attempting to extend the base class like so: import classNames from 'classnames'; ... className = classNames(styles.buttton, props.className); But this leaves me at the mercy of the order in which webpack builds stylesheets (sometimes props.className will be defined after styles.button and my plan would work; other times it will get defined before styles.button,…