221–230 of 448 posts
Looking at the new features, I wondered why they went with a major version bump, but seems like it's because the Just-in-Time engine released in Mars as a feature flag is now the default engine, which is a pretty big change by itself.
Earlier quoted context omitted.
Well that's easy, silly! Sign in A real joy compared to writing CSS, lemme tell ya.
It's fewer than half as many characters as writing the same thing in CSS: .btn { display: inline-flex; justify-content: center; padding: 8px 16px; border: 1px solid transparent; box-shadow: 0 1px 2px 0 rgb(0 0 0 / 0.05); font-size: 14px; border-radius: 6px; color: #fff; background-color: rgb(79 70 229); } .btn:hover { background-color: rgb(67 56 202); outline: 2px dotted transparent; outline-offset: 2px; box-shadow:…
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…
I don't understand Tailwind either; but I find myself struggling with CSS modules when I need to override a CSS rule of a child from a parent. Like, say, my button should always be green, except in this context I want it to be purple, its font-size larger and its padding a bit different. With CSS modules, the parent component is unaware of the class name of the child component; so it cannot target that. Perhaps this should all be done with CSS variables; but then hell, how many CSS variables should my components expose? and besides, I am not even sure even they will completely solve this.
Earlier quoted context omitted.
When did playful become offensive?
Because by definition offensive has to do with how people receive something. I love the library, will continue using and donate, I would prefer the docs not to assume that people that print papers are animals. That's all! Take it or leave it.
maybe i'm reading into it too much, but i don't think they think print readers are inferior.
I've been a Bootstrap user for a long time, but I recently made the jump to Tailwind. It's not the revolutionary upgrade I was hoping for, but it's nice evolutionary step in the right direction. It's quite intuitive, but it doesn't get rid of most of the frustrations that come from doing layouts, as those come from the design of CSS itself. `@apply` makes the upgrade worth it though, it's easy to make custom classes…
If you're talking about Tailwind UI[1] — I use Tailwind extensively and have basically never looked at Tailwind UI. It's just useful snippets of HTML styled with Tailwind. It is by no means required to get value out of Tailwind. I'm not sure what you mean by proprietary culture! Based on the fact that I've pretty much never seen anyone talk about it, I would guess (total guess, no real knowledge) that no more than 1%…
I really like Tailwind, and was excited to use it for a new application at our company. However, I find the lack of standard component classes (modal, card, button, wherever) pretty limiting. This makes it difficult to have open source Tailwind components that can be imported and themed differently for your apps. Even after buying Tailwind UI, they are basically just code samples that we'd have to copy into our own l…
There is a headless (meaning unstyled) set of components from the same authors: https://headlessui.dev/
With no disrespect to anyone, I think it'd be useful if people bashing Tailwind would briefly list what their day to day programming consists of. My impression is that most of the negative comments are coming from people that don't code for Web often (I could be wrong). To those folks: I'm not saying you don't know your stuff or that you argue badly - since I was on that side myself a few months back. What I am sayin…
When you write anything substantial you end up with class name soup. The answer to this is to use `@apply` which is literally just a normal CSS class with extra steps.
The new vernacular just means that users have to learn Tailwind language rather than proper CSS.
CSS modules solve the main problems that Tailwind attempts to solve. The other things are solved with use of CSS variables.
The only thing that I find useful in Tailwind is the responsive design classes. Being able to do `md:` is pretty cool.
To me, Tailwind seems valuable to newer engineers because they feel like they don't have to learn CSS. They learn "Tailwind." It's like all those people who would say "I don't know JavaScript, I know jQuery." Like jQuery, there are benefits in having a unified language especially when you're newer. I believe that a better solution to styling is inevitable (my latest favorite heavily uses CSS variables). I do not believe Tailwind is the best way forward.
I used the JIT version recently on a new landing page with code completion for class names in my IDE and found it great. The distance between what I'm picturing in my head and what I have to type to see that on the screen felt so much shorter and less fatiguing than the standard CSS approach. With the regular way, to style something that's probably not going to appear elsewhere, I'm having to: come up with class name…
The trick with CSS is to write semantic HTML and avoid div, span and css classes. You can of course inline css too (used mostly for optimization to prevent layout shift, but is also fine for elements/classes that are not repeated, such as the top menu, top banner/intro and header/footer)
I'm really glad I just powered through that point and let myself feel dumb.
I used the JIT version recently on a new landing page with code completion for class names in my IDE and found it great. The distance between what I'm picturing in my head and what I have to type to see that on the screen felt so much shorter and less fatiguing than the standard CSS approach. With the regular way, to style something that's probably not going to appear elsewhere, I'm having to: come up with class name…
Yeah, that's kinda the poster child use case for Tailwind and similar frameworks. Landing pages are all about being jazzy and unique and eye catching, and not so much about code reusability/composability.
Where it gets less fun is when you want widget consistency across multiple areas of a site and across design tweaks over time, since now you have to deal with several `class="..."` strings across multiple files, possibly with class names in arbitrary order, possibly mixed with logic from other templating languages (be it from Django or JSX or whatever). So you can't just grep to achieve the objective of changing styles in one place to affect all instances of some semantic group.
Personally I think comparing Tailwind directly against traditional CSS as a whole is painting in too broad strokes. There's a lot of CSS methodologies and also a lot of bad practices (e.g. using SASS indentation as namespacing mechanism and then running into the old problem of specificity), and comparatively, there's a lot more than Tailwind in the atomic CSS space, and more broadly, in the compiled CSS space.
Utilities like Bootstrap (e.g. `class="btn btn-primary"`) for example share many benefits of both atomic CSS and "good" subsets of traditional CSS practices (namely, you get memorable short class names, which are also organizable along semantic lines). So there's definitely more shades of gray than just "atomic-css-is-the-best-thing-since-sliced-bread" vs "looks-like-lazy-style-attributes-lol".