5 ms·
The things I love the most about TailwindCSS: 1. After purged the CSS file is really, really small. 2. Hopping into all of my projects and not having to remem
by lemonberry 6y ago
The things I love the most about TailwindCSS:
1. After purged the CSS file is really, really small.
2. Hopping into all of my projects and not having to remember new class names.
3. Not having to come up with new class names.
4. Not worrying about making a change in a class and having unintended consequences.
5. Not skipping back and forth between HTML or CSS files.
That said, if you don't dig it, there are plenty of other great frameworks, naming conventions and approaches that people use. Or start from scratch and roll your own.
For frameworks I flirted with InuitCSS for a bit. It's pretty nice and after digging through the code I realized it's not as complex as it first appears.
I also like Andy Bell's approach with Cube CSS.
- aidos 6y agoI’ve been keeping an eye on Tailwind. Over the last few years we’ve switched from old school single css file to css in js, and while that helps with the class spread issues, by lots of other measures it’s inferior. This was solidified for me last week when we rebranded our app and I needed to hack in both new and old code. Editing is js controlled css in the browser is just too painful. Anyway, couple of weeks back I needed to make a website for a mate and decided I’d give tailwind a spin. My god does it make css fun again. I’m not sure how you look after sprawling styles in a bigger app (though I’m sure I’ll figure something out) but having the right combination of safe css, everything right there and responsive styling locally is a dream. I’m totally sold.
- JxLS-cpgbe0 6y ago> 5. Not skipping back and forth between HTML or CSS files. What? I thought the point of this was for use with composable JS components. You're manually writing and updating attributes like this?! class="text-4xl sm:text-6xl lg:text-7xl leading-none font-extrabold tracking-tight text-gray-900 mt-10 mb-8 sm:mt-14 sm:mb-10" How could you possibly manage this without components? Ctrl-F "lg:text-7xl" and replace?
- ssijak 6y agoYou make components as usual, but you style with those utility classes. Those utility classes are configurable in one theme file where you can set what "text-4xl" is or how much space "mt-10" is.
- yurishimo 6y agoYes, if it's not componentized into a smaller chunk, find and replace works fine. The beauty of Tailwind is though, if you change that, you know exactly what the consequence is since every utility is so highly targeted. You absolutely do skip between lots of HTML/JSX/VUE files, but that's true of any project. The point of tailwind is to keep you in the view layer of your project and not jumping between more than a browser and one tab in a code editor when building your UI.
- JxLS-cpgbe0 6y ago> find and replace works fine It would replace every `.font-extrabold` element on the page. What if I only want to update my extra bold headlines, not the extra bold subheadings? Global search-and-replace breaks my subheadings. >> 5. Not skipping back and forth between HTML or CSS files [with Tailwind] > You absolutely do skip between lots of HTML [with Tailwind] ??
- Wolfr_ 6y agoYep. There's so many global replace situations where the logic completely breaks.
- lemonberry 6y agoIn my experience global replace is much easier across multiple component files rather than multiple CSS files. If I need to do change a font color I do a search and know to change it based on the file/component it's used in. If I had to change the color in css files I'd have to review the class and also track down where that class is in use.
- lemonberry 6y agoSometimes I extract to component classes, but in Laravel or Statamc the html element and the classes have already been extracted to a component so there's only one place to make the change anyway. When doing WordPress sites I extract to component classes more often.
- deergomoo 6y agoYou don’t need to be using a JS framework to have components. Pretty much any server-side templating language allows extracting “components” in the form of reusable HTML fragments. And even if you’re serving static HTML, there’s plenty of ways to compile a template into a static file.
- JxLS-cpgbe0 6y agoRight, components. Not a search-and-replace for every instance of ".color-pink" in your codebase, suggested by the parent.
- cactus2093 6y agoLots of good responses already on other ways to abstract, but I'll even go one further and say "sure, why not?" When are you changing every single instance of "lg:text-7xl"? More often you're probably making a change in one single place in the app, in which case this is incredibly easy, you just make your change where you want. You're not slowed down by digging through layers of abstraction cruft and indirection until you find the right place to make the change. If you're doing an entire site design refresh, then doing some find and replace isn't really that crazy. For something you do relatively infrequently like this (maybe every couple of months or even every couple of years?) it's not a big deal if it takes a little bit longer. And likely you'll need to look through and test your changes on every page one by one anyway, to make sure you're not breaking anything you didn't mean to. You'll need to do that whether you changed the definition of a css class, or you made a bunch of inline changes, at which point making the actual code edits inline probably isn't even the bottleneck. But again, that's perhaps a bit extreme of a way to look at it. You will inevitably have some layer of abstraction anyway, something like components or templates or partials, in which to wrap your styles.
- JxLS-cpgbe0 6y ago> When are you changing every single instance of "lg:text-7xl" I'm not, I'm changing some 7xl-sized text in multiple places. But I don't want to change every element that is .lg:text-7xl already. > If you're doing an entire site design refresh I'm not > You will inevitably have some layer of abstraction anyway, something like components I already do, they're in JS, and much more powerful and extensible than HTML attributes.