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.
It is a blessing for backend developers like me who suck at design.
I think Tailwind, at least as used by them on their linked demo site, is a very bad idea for people who suck at design. It promotes utility classes in HTML, like class="px-4 py-2 border-b border-gray-200 sm:flex justify-between items-center bg-white sm:py-4 sm:px-6 sm:items-baseline" which is no better than using inline styles. It's basically the same as using Dreamweaver from the 1990s to make your website.
Web Engineer. Working mostly with PHP, Symfony and Golang.
Entusiast about Engineering Best Practices, Continuous Delivery and DevOps.
Sports and FC Porto fan!
I completely understand what you are saying and I had exactly the same feeling when I saw it for the first time.
But after playing with it a bit I changed my mind.
I think where it plays better, is together with component-based framework like Vue or React, so you create components to avoid repeating the styles. I mean even to a regular template engine that supports "includes" you can take the same approach.
So let´s say you can create a component "Card" where the HTML contains the tailwind directives and use it everywhere in the application. If you want to change how the card looks, it´s just a single place to change.
Also, you can use normal CSS in an external file and apply the tailwind directives if you really can't stand the inline approach.
I have done very simple applications with it. I don´t know if wil scale well for medium and big size projects with many people working on it. Maybe not. Can I see it become a mess to mantain in some projects? yes! Like any technology.
But for personal and small projects, where you want to have a solid design without much effort, together with the amazing library of pre-made components provided by Tailwind UI, I believe it´s a great choice!
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.
Web Engineer. Working mostly with PHP, Symfony and Golang.
Entusiast about Engineering Best Practices, Continuous Delivery and DevOps.
Sports and FC Porto fan!
Yes they have helpers for their default color pallete like, bg-green, text-blue, etc and would have to change it all places.
But, you can define your own names, and having something like "bg-primary", "bg-secondary", etc, so if you want to change your colors, you just have to change in a config file. (tailwindcss.com/docs/customizing-c...).
Maybe they should promote these practices more. I agree it has the potential to become messy if you are not careful.
As I said, I only use it for small personal projects for now, where these points are not that important. What it gives me in terms of speed and good looking design out of the box, largely out-weights the possible problems you mentioned.
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.
Web Engineer. Working mostly with PHP, Symfony and Golang.
Entusiast about Engineering Best Practices, Continuous Delivery and DevOps.
Sports and FC Porto fan!
Web Engineer. Working mostly with PHP, Symfony and Golang.
Entusiast about Engineering Best Practices, Continuous Delivery and DevOps.
Sports and FC Porto fan!
Also not sure, if this reply is for me, but I read that post and some comments there, from what I read, Tailwind is planning to create Vue, and React components in the future, instead of only HTML versions. I guess it would be similar with Buetify and Vuetify, so you would have a let´s say tw-button element.
Still, for me the big advantage of Tailwind is there good looking design by default.
I agree with that. It's the reason I tend to avoid frameworks like Bootstrap. Furthermore, if you need to build more complex custom layouts (e.g. out of a PSD), such frameworks might even end up being an obstacle rather than a help. A few years back I would use bootstrap or whatever framework for its grid layout, but today, with native CSS solutions like flexbox and grid, it seems to me that it's not worth it.
Actually, at some point, I used to use a CSS Grid framework because it was implementing flexbox, which seemed intimidating at the time (Bootstrap was on version 3, which hadn't implemented it yet). It was great for simple layouts, but on more complicated designs trying to fit the HTML markup to the conventions of the framework was a nightmare. Eventually, I ditched it completely and decided to properly learn how to use flexbox. It was one of the wisest choices I've made, as learning was much easier than I thought, and since then styling a page became much easier on every aspect.
In my opinion, the biggest drawback of such frameworks is that there is a danger that you will end up learning the framework and forget the actual CSS without a good enough payoff. Doing <div class="sm:flex;"> instead of putting display: flex; on a media query, not only won't save you from any worthwhile trouble but if you get used to it you might unfamiliarize yourself with how things actually work.
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.
I think Tailwind, at least as used by them on their linked demo site, is a very bad idea for people who suck at design. It promotes utility classes in HTML, like
class="px-4 py-2 border-b border-gray-200 sm:flex justify-between items-center bg-white sm:py-4 sm:px-6 sm:items-baseline"which is no better than using inline styles. It's basically the same as using Dreamweaver from the 1990s to make your website.I completely understand what you are saying and I had exactly the same feeling when I saw it for the first time.
But after playing with it a bit I changed my mind.
I think where it plays better, is together with component-based framework like Vue or React, so you create components to avoid repeating the styles. I mean even to a regular template engine that supports "includes" you can take the same approach.
So let´s say you can create a component "Card" where the HTML contains the tailwind directives and use it everywhere in the application. If you want to change how the card looks, it´s just a single place to change.
Also, you can use normal CSS in an external file and apply the tailwind directives if you really can't stand the inline approach.
I have done very simple applications with it. I don´t know if wil scale well for medium and big size projects with many people working on it. Maybe not. Can I see it become a mess to mantain in some projects? yes! Like any technology.
But for personal and small projects, where you want to have a solid design without much effort, together with the amazing library of pre-made components provided by Tailwind UI, I believe it´s a great choice!
But if you want to change the theme of your entire page, you'll need to do it repeatedly to every component.
Tailwind has great support for themes,
Yes they have helpers for their default color pallete like, bg-green, text-blue, etc and would have to change it all places.
But, you can define your own names, and having something like "bg-primary", "bg-secondary", etc, so if you want to change your colors, you just have to change in a config file. (tailwindcss.com/docs/customizing-c...).
Maybe they should promote these practices more. I agree it has the potential to become messy if you are not careful.
As I said, I only use it for small personal projects for now, where these points are not that important. What it gives me in terms of speed and good looking design out of the box, largely out-weights the possible problems you mentioned.
Let´s see, where it goes ;)
I think you are still looking for Component libraries, as opposed to atomic CSS.
But that is what current Dev.to don't suggest much, at least according to my another question.
Looking for a CSS framework that I don't have to fight against it (also Vue Framework)
Pacharapol Withayasakpunt ・ Apr 16 ・ 1 min read
CSS-in-JS components or Single File Components, might be the answer you wanted.
Who is this reply to? Sorry, threading is only a level or two deep here :)
If me, then I'm not sure what you mean?
NVM, but I actually mean that Tailwind is not meant for backend dev who are suck at design.
For me, it´s amazing for that. ;)
I can build good looking interfaces without much effort thanks to the solid foundation tailwind provides me.
A full-stack need to carefully pick up their battles. Tailwind gives me time to focus on other areas.
But again, this is my personal experience and my goals.
Also not sure, if this reply is for me, but I read that post and some comments there, from what I read, Tailwind is planning to create Vue, and React components in the future, instead of only HTML versions. I guess it would be similar with Buetify and Vuetify, so you would have a let´s say
tw-buttonelement.Still, for me the big advantage of Tailwind is there good looking design by default.
Tailwind did made a good showroom, though.
But, originally I intended this for Ben.
I agree with that. It's the reason I tend to avoid frameworks like Bootstrap. Furthermore, if you need to build more complex custom layouts (e.g. out of a PSD), such frameworks might even end up being an obstacle rather than a help. A few years back I would use bootstrap or whatever framework for its grid layout, but today, with native CSS solutions like flexbox and grid, it seems to me that it's not worth it.
Actually, at some point, I used to use a CSS Grid framework because it was implementing flexbox, which seemed intimidating at the time (Bootstrap was on version 3, which hadn't implemented it yet). It was great for simple layouts, but on more complicated designs trying to fit the HTML markup to the conventions of the framework was a nightmare. Eventually, I ditched it completely and decided to properly learn how to use flexbox. It was one of the wisest choices I've made, as learning was much easier than I thought, and since then styling a page became much easier on every aspect.
In my opinion, the biggest drawback of such frameworks is that there is a danger that you will end up learning the framework and forget the actual CSS without a good enough payoff. Doing
<div class="sm:flex;">instead of puttingdisplay: flex;on a media query, not only won't save you from any worthwhile trouble but if you get used to it you might unfamiliarize yourself with how things actually work.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.