I don’t think it’s in good faith to accuse someone of using multiple accounts to flag your comments without any basis and I believe this type of behavior is directly in violation of the guidelines of HN.
I have been using tailwind on a new project and I only see 3 real benefits over using inline css styles:
1) Sizes are standardized in a predetermined set of discrete size classes. So you start to think about sizes, padding, margins, etc in terms of steps instead of values. You can change the steps in one place and they apply globally. It's a little easier to standardize a rough style guide compared to starting from scratch.
2) Colors are standardized in a similar way. You just need to configure your app's core colors and then you can just think in terms of steps instead of color values.
3) You have a smaller set of "best practice" means to achieve most outcomes compared to all that's available with css. You don't need to know the best way to do what you want, you can just browse the documentation to find what you want.
Outside of that, you still have to use @apply to collapse utility classes into more semantic classes if you want style changes to cascade (tailwind recommends using components or view partials to achieve this instead of via css classes, though this would work equally well with inline styles)
The styles are very verbose, just like with inline styles. They are only slightly shorter than inline styles since they are basically abbreviated forms of inline styles.
You can still do everything tailwind does for you by using your own style guide and building out css classes, but tailwind gives you a head start.
It feels like it makes you more productive in the beginning because you get a toolset with a lot of decisions already made for you, but I suspect it will make things a bit slower as the app gets more complicated.
You're exactly right wrt interviewing. I was talking in general and not in the context of an interview.
If you are interviewing someone and they solve the problem you ask, and then you don't give them some sort of guidance or constraints to meet your "correct" guidelines, then you aren't doing a good and fair interview.
>One result set is equivalent to another, and as long as you aren't using unnecessary nested loop joins or such, there are a dozen ways to solve a query.
If they consume similar resources I'd almost always opt for the simplest one to understand.
In cases where the simpler one is less efficient, I might still use it if the task didn't require absolute optimization.