Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Play with TailwindCSS in the Browser

play.tailwindcss.com

Post reply on HN
Print view View original

151–160 of 300 posts

Re: Play with TailwindCSS in the Browser

#151

Post by EudaimonBlue »

My90thaccount wrote: post #55
jonwinstanley wrote: post #41

Earlier quoted context omitted.

How does it affect quality?

Tailwind means making your HTML non-semantic, usually backed by JavaScript. This has created an arms race where parsers such as screen readers need to do ever-evolving heuristics to provide a reader mode. The code usually cannot be modified or even viewed in a readable form by users. Of all things, it's not user-centric. You're going to tell me next that you have a JSON interface instead. But that's a site-specific A…

The JS part is just clean up the final result result of classes.

From what I've seen online using Tailwind over other frameworks like Styled Components, gives +5x speed ups. So it is not wasted effort.

> The code usually cannot be modified or even viewed in a readable form by users.

That's right, most of the time it is even minified. It' is not meant to be read by humans but by the browser. Poor accessibility is is a result of it not being prioritized designing/development of a product.

Re: Play with TailwindCSS in the Browser

#152

Post by gedy »

likortera wrote: post #136
gedy wrote: post #126

Earlier quoted context omitted.

I really like utility classes and think Tailwind is really smart for many usecases, but the drawback with Tailwind is even if you componentize, your code is sprinkled with very specific visual classes like for shadows, border radius, etc. When companies want to refresh their look and feel, it's really annoying to change everything to remove now unwanted shadows, etc. In spite of it's age, I've found Bootstrap is bett…

Have you ever had to change the company's look and feel with anything else than tailwind? I had to do it with a BEM codebase, and I also had to do it with tailwind. The tailwind situation was by far the easiest one. And it was because I was not afraid to remove things that could break unrelated parts of the application. Not allowing developer to hand write CSS is a great restriction for a good bunch of developers. Th…

> Not allowing developer to hand write CSS is a great restriction for a good bunch of developers.

I agree, main point is that I think there are better tools for large codebases. We had a "no CSS" rule where we used bootstrap components and utility classes only.

Re: Play with TailwindCSS in the Browser

#153

Post by ramesh31 »

erokar wrote: post #105
halotrope wrote: post #71

There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I know it is conceptually "wrong" and a bunch of well crafted CSS classes would be more elegant. In the end it works, works really well and makes collaboration dead simple. Commonly used groups of classes can either be aliased by @apply or used in a (react) component. I used CSS way before Tailwind was a thing and in…

I've used Tailwind on many projects at work for about a year now. I do not like it. Tailwind seemingly affords an easy way of writing inline styles, but it 1) clutters the HTML, 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that), 3) uses names that can be similar but are not identical to CSS properties and feels like a bad abstracti…

> 1) clutters the HTML,

Or, it makes your HTML far more representative of the state of your application, rather than having to open up a CSS file and match to the class name + whatever madness you have going on in your SASS with mixins and conditional style logic.

> 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that)

Blindly following DRY is dogma. Not everything can (or should) be a component. The number one mistake I see with new React developers is "over componentization", where everything is a sub component, and now I'm digging through 5 different files to work on a feature. Use the "rule of three" here. The first time you write something, don't even think about making it a component. The second time you write it, start planning how to generalize. The third time you need it, make it a component.

Copy/pasting is OK. Declaratively laying out your UI rather than generating it through configuration is OK. Having no abstractions is better than a bad or even mediocre abstraction.

Re: Play with TailwindCSS in the Browser

#154

Post by gedy »

bpicolo wrote: post #131
gedy wrote: post #126

Earlier quoted context omitted.

I really like utility classes and think Tailwind is really smart for many usecases, but the drawback with Tailwind is even if you componentize, your code is sprinkled with very specific visual classes like for shadows, border radius, etc. When companies want to refresh their look and feel, it's really annoying to change everything to remove now unwanted shadows, etc. In spite of it's age, I've found Bootstrap is bett…

> but with no 3rd party components available There are a bunch of great 3rd party components available in tailwind now. https://daisyui.com/ is one I've been using. They're usually a tad bit lower level than typical framework component libs, but the flexibility is great. A great thing about that is they're not React-specific, Vue-specific, etc. You can use them in everything from raw html to your JS library flavor of…

DaisyUI is a nice approach and hope it succeeds. We were looking to use that until we realized it's almost identical to Bootstrap, and that we were just using Tailwind as an elaborate way to make a custom Bootstrap theme at build time. Company decided to go with BS5 instead.

Re: Play with TailwindCSS in the Browser

#155

Post by phreack »

DecayingOrganic wrote: post #133
65 wrote: post #80

I used to be a Tailwind hater. I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file. If you're on the fence, try it out. I think it's the future…

As a side note, you can configure prettier for automatic class sorting for tailwind! It makes a huge difference in terms of code readability and maintenance. https://tailwindcss.com/blog/automatic-class-sorting-with-pr...

Thank you so much for sharing that! I had no idea how much I even needed this, my classes tend to get incredibly messy and it'd always bothered me.

Re: Play with TailwindCSS in the Browser

#156

Post by dangerface »

onion2k wrote: post #40
rco8786 wrote: post #16

Im sorry but I don’t understand how anyone can look at that and think it’s a good way to build UIs. I’m almost certainly in the wrong, considering how popular this library seems to be getting, but holy heck that looks like a tedious mess to work with. It’s like you have to learn every raw CSS selector, and then also learned how it’s represented in Tailwind, and then scatter that all over your markup.

It’s like you have to learn every raw CSS selector, and then also learned how it’s represented in Tailwind, and then scatter that all over your markup. That's exactly what it is. But... you have to do that regardless of what you use for CSS layout. If you're not using Tailwind (or something like it) then you're going to end up creating classes using the raw CSS, and then naming them yourself, and then having to remem…

It seems like the main advantage of tailwind is that you don't have to learn how CSS cascading and specificity works, which is a fair advantage as most frontend developers I talk to don't even realise that specificity is a thing.

I don't see the advantage over inline style tho. I see abbreviations as a disadvantage as its just as fast to type background as it is bg but background is clearly more intelligible.

How do you deal with side effects for example I think bg-red is the brand red but some one has modified that class so it now has a border. You could prevent this with convention but then you have the same issues as using css with specificity and people not understanding the conventions around it.

I think its easier for every one to just force your frontend developers to just learn CSS and use it.

Re: Play with TailwindCSS in the Browser

#157

Post by nojs »

Vinnl wrote: post #146
65 wrote: post #80

I used to be a Tailwind hater. I couldn't fathom why anyone would ever use it. And then I used it. It seriously makes CSS significantly easier to maintain, dramatically reduces your CSS build size, and is really good for teams if you're trying to use consistent CSS throughout your UIs. You also don't need to go back and forth between CSS file and HTML file. If you're on the fence, try it out. I think it's the future…

If you're using a component-based architecture (e.g. when using React, Vue or Angular), otherwise it can get pretty annoying. But if you do, it's pretty great; you don't really need the abstraction of reusable classes, when you already have reusable components, and getting rid of useless abstractions makes me a happy programmer.

I am using it with traditional Django + Jinja2 for templating now which is working well. With {% macro %} you basically get fully reusable “components” on the backend so there’s limited copy pasting of tailwind classes.

Re: Play with TailwindCSS in the Browser

#158

Post by dawnerd »

nazka wrote: post #99
halotrope wrote: post #71

There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I know it is conceptually "wrong" and a bunch of well crafted CSS classes would be more elegant. In the end it works, works really well and makes collaboration dead simple. Commonly used groups of classes can either be aliased by @apply or used in a (react) component. I used CSS way before Tailwind was a thing and in…

No at the end you end up having to learn all their classes, for almost no gain in speed of dev, and then you forget how to do stuff in CSS. For me Tailwind barely make it anything faster but I have to learn all their classes and then I am stuck to have to relearn CSS when their is custom stuff. Maybe for greenfield or MVP sure. But if you are on a big project you have one or more designers and 99% of the time you hav…

Re working with designers: that's why the tailwind config exists.

Re: Play with TailwindCSS in the Browser

#159

Post by skttl »

jakelazaroff wrote: post #127
hbn wrote: post #109

Earlier quoted context omitted.

I want the styles to be in the template though, because I don't want to bounce back and forth between 2 files when designing a single UI. And it's not just inline styles, there's some things Tailwind can do that a style tag can't. Such as screen size breakpoints. Here's how to make a div have 0.5rem of left/right padding on mobile, and 2rem on any screen larger: I'd much rather do this than mess with CSS's horrible m…

Okay, but now we’re back to Tailwind being back to syntactic sugar for styles (you can definitely put media queries in a style tag). I disagree with your preference; all the classnames are not easily parseable and obscure the markup, and I much prefer the CSS media query syntax. But that’s, like, just my opinion, man. If you like it better, don’t let me stop you!

>(you can definitely put media queries in a style tag)

How?

Re: Play with TailwindCSS in the Browser

#160

Post by nojs »

the_other wrote: post #68
pocketsand wrote: post #33

Earlier quoted context omitted.

It pushes you to componentize common UI elements. Feel bad to have long utility classes that look like . Change it to: Submit using whatever tooling you prefer. If you don't use this style, maybe you won't like it. I've found it's a waste of time to extract classes for items that are not repeated. And putting utilities in components lightens your "master" CSS file and makes it a lot easier to work with CSS. I've foun…

> It pushes you to componentize common UI elements. Feel bad to have long utility classes that look like . Change it to: Submit using whatever tooling you prefer. Even when you do that, you're still delivering the long, repetitive mark-up to the browser, rather than relying on the CSS engine to handle this for you. You're making the DOM MUCH MUCH heavier than it needs to be and ignoring the rendering engine that's op…

> Even when you do that, you're still delivering the long, repetitive mark-up to the browser, rather than relying on the CSS engine to handle this for you.

The crazy repetition of classes gzips away though so there really isn’t any extra overhead.

Post reply on HN