> 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 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).