I understand the author points, and the article is well written. But, I moved to tailwind for different projects and now I use it nearly exclusively.
I don't want to argue whenever it is good or bad, but it solves my problems. When you are deep down some html component, being able to style it without having to find the css file is very pleasant. The code is also more maintainable as there is no "domino effect". You change what you want to change, and you are done.
As for vendor lock in, tailwind is MIT licensed, I don't see the issue here. Of course if you use X, you are going to depend on X. And if they release a breaking update, just pin the old version. I'm happy with improvement in tailwind 2, but to me the framework is complete, I don't mind it being frozen.
Concerning the long lines, I agree, but you can just put newlines between class names. Class name is a cdata list, newlines are ignored: https://www.w3.org/TR/html401/types.html#type-cdata
What I do is that I group classes by function, like color on one line, margin/padding on another...
> deep down some html component, being able to style it without having to find the css file is very pleasant
Is this a template based project with global CSS? That is not an issue at all if you're using an actual component system.
> tailwind is MIT licensed
I don't think the lock-in has anything to do with the license, but how hard it is to migrate away from it. You're locked to its build tooling and converting the styles back to anything else is a rewrite-everything-from-scratch proposition. Whereas migrating from say, styled-jsx to styled-components is a lot easier.
> Is this a template based project with global CSS? That is not an issue at all if you're using an actual component system.
Yes, I use phoenix live views, which is just HTML templates with global CSS. I know there are tons of "real" CSS component systems, but live views has been really a life saver to me, and I don't need offline apps.
Concerning the lock in, I think it makes sense only if the vendor will stop supporting it. I mean, if it works, doesn't change it, even if it means forking the repo and having it sit somewhere. The security and "bugs" are handled by the browser, the CSS framework can just be stuck in times, it shouldn't be an issue. Of course if CSS specs changes drastically, it might be an issue, but it would be for any other CSS solution. Also, we are talking about class names, this is fairly standard, tailwind didn't invent "utility-first" CSS, maybe not a drop in replacement, but I don't see that as a real lock in.
> Concerning the lock in, I think it makes sense only if the vendor will stop supporting it.
I believe it's still not the point. By vendor lock-in, the author meant that if one day for any reason (maybe size of the bundle due to many unnecessary class variants?) you will have to go away from tailwind, you will find it either extremely time consuming or even impossible (for example due to time/budget limits).
> The same could be said about any framework or language or tooling
That's simply not true. The knowledge of Tailwind's class names, media queries, and tooling is not transferrable, whereas styled-jsx/styled components/css modules/emotion are all still based on CSS syntax and applying classes, moving between them is vastly easier than to/from a framework like Tailwind.
Moving from AngularJS to React is not the same either. Understanding the way that data moves through AngularJS does not map directly to the way that React moves data through the system or how AngularJS updates the DOM vs React and all the idiosyncrasies involved.
Same is said for moving from Bootstrap to some other way of managing your styling.
Different tools have different naming, different "class names", different "media queries", and different "tooling".
I can't take my direct knowledge of Bootstrap 3 and use it in a styled-JSX world.
Moving between frameworks is always going to be difficult and require rethinking how things are built.
That was about CSS/styling frameworks only. Unlike application frameworks, the underlying tech and knowledge of CSS is the same, so you're really comparing apples to oranges.
I don't want to argue whenever it is good or bad, but it solves my problems. When you are deep down some html component, being able to style it without having to find the css file is very pleasant. The code is also more maintainable as there is no "domino effect". You change what you want to change, and you are done.
As for vendor lock in, tailwind is MIT licensed, I don't see the issue here. Of course if you use X, you are going to depend on X. And if they release a breaking update, just pin the old version. I'm happy with improvement in tailwind 2, but to me the framework is complete, I don't mind it being frozen.
Concerning the long lines, I agree, but you can just put newlines between class names. Class name is a cdata list, newlines are ignored: https://www.w3.org/TR/html401/types.html#type-cdata What I do is that I group classes by function, like color on one line, margin/padding on another...