Hi Ben, what you see in their landing page is not how it really meant to be used. It's just for demo purposes and fast prototyping. In practical use cases, you would make components to group classes or to re-use the markup. Read more at Extracting Components docs.
which is no better than using inline styles
Inline Styles does not support media queries and pseudo-classes. Also, it will add a high specificity to your CSS. Last but not least, managing consistent values for padding, margin, color... is very hard with inline-styles unlike using Tailwind utility classes. So it's unfair to assume they are the same or worse.
It may be truly overwhelming at first, but once you get used to it will be very useful and practical.
Inline Styles does not support media queries and pseudo-classes. Also, it will add a high specificity to your CSS
Still, IMO, it might be only marginally better than plain inline style. (in most aspects)
However, right now, even if I am still not convinced about including the whole Tailwind (and Purge CSS), I am very convinced that I should write CSS in Atomic style. I even used names similar to Tailwind website.
I cannot see how supporting responsive design and adding low CSS specificity to the element is "only marginally better". A big portion, if not the biggest, of your visitors will be using mobile devices.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I don't think it's overwhelming at all, I see what people are doing with it and I'm aware that you can make classes in a similar way to extending in Less or Sass, e.g. (pseudocode):
However, that's not how people work. It's not how people do things in the real world. Evidence? Their site doesn't. Their site does it that "bad" way, and if even they won't do it right, why would any of their users?
You might point out a couple of technical ways it's better than inline styles, but practice-wise, it's the same. It's encouraging mixing presentation and markup, which wasn't a good idea 10 years ago and it's suddenly a good idea now because it's the easy way.
By overwhelming I meant it makes you hesitating or refusing to consider using it. What you see in their site is the compiled code. You can't tell if they are using it wrong or not. Most likely they have used component based approach to re-use the markup. The whole point of the website is to showcase the versatility and the power of their utility-based framework. It will make no sense if they used class names and used @apply directive which will obscure the versatility and dictate a CSS naming convention which is not the aimed goal behind the framework.
which wasn't a good idea 10 years ago [...]
Since 10 years ago a lot has been changed. Mixing presentation and markup is a real complication when using a monolithic approach. But now, you can separate the logic of your app in a small digestible and encapsulated components. Such approach wasn't easily possible 10 years ago as today there's a lot of powerful build tools that make such thing possible.
Some people even decide to mix markup + presentation + business logic in a single component when using JS frameworks like React, Angular or VueJS. Yet, they succeed to delivery a powerful and maintainable web apps.
My point is, as technology advance the decision making changes too. For example, years ago computers were limited in memory and storage that made developers very concerned about managing every single byte of memory. Now such concerns are tend to be called micro-optimization.
Myself included I still hesitate to mix the three layers in a single file. I still tend to be influenced by the old school way. However, when you mix them you're not automatically wrong. It always depends on how you do it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Ben, what you see in their landing page is not how it really meant to be used. It's just for demo purposes and fast prototyping. In practical use cases, you would make components to group classes or to re-use the markup. Read more at Extracting Components docs.
Inline Styles does not support media queries and pseudo-classes. Also, it will add a high specificity to your CSS. Last but not least, managing consistent values for padding, margin, color... is very hard with inline-styles unlike using Tailwind utility classes. So it's unfair to assume they are the same or worse.
It may be truly overwhelming at first, but once you get used to it will be very useful and practical.
Still, IMO, it might be only marginally better than plain inline style. (in most aspects)
However, right now, even if I am still not convinced about including the whole Tailwind (and Purge CSS), I am very convinced that I should write CSS in Atomic style. I even used names similar to Tailwind website.
I cannot see how supporting responsive design and adding low CSS specificity to the element is "only marginally better". A big portion, if not the biggest, of your visitors will be using mobile devices.
I don't think it's overwhelming at all, I see what people are doing with it and I'm aware that you can make classes in a similar way to extending in Less or Sass, e.g. (pseudocode):
However, that's not how people work. It's not how people do things in the real world. Evidence? Their site doesn't. Their site does it that "bad" way, and if even they won't do it right, why would any of their users?
You might point out a couple of technical ways it's better than inline styles, but practice-wise, it's the same. It's encouraging mixing presentation and markup, which wasn't a good idea 10 years ago and it's suddenly a good idea now because it's the easy way.
Yes, you can
@applyin Tailwind as well. So, in the end, it's the good ol' CSS, with Tailwind website acting as a showroom.@ ben
By overwhelming I meant it makes you hesitating or refusing to consider using it. What you see in their site is the compiled code. You can't tell if they are using it wrong or not. Most likely they have used component based approach to re-use the markup. The whole point of the website is to showcase the versatility and the power of their utility-based framework. It will make no sense if they used class names and used
@applydirective which will obscure the versatility and dictate a CSS naming convention which is not the aimed goal behind the framework.Since 10 years ago a lot has been changed. Mixing presentation and markup is a real complication when using a monolithic approach. But now, you can separate the logic of your app in a small digestible and encapsulated components. Such approach wasn't easily possible 10 years ago as today there's a lot of powerful build tools that make such thing possible.
Some people even decide to mix markup + presentation + business logic in a single component when using JS frameworks like React, Angular or VueJS. Yet, they succeed to delivery a powerful and maintainable web apps.
My point is, as technology advance the decision making changes too. For example, years ago computers were limited in memory and storage that made developers very concerned about managing every single byte of memory. Now such concerns are tend to be called micro-optimization.
Myself included I still hesitate to mix the three layers in a single file. I still tend to be influenced by the old school way. However, when you mix them you're not automatically wrong. It always depends on how you do it.