I finally understand what mobile first means in bootstrap/tailwind.
I feel dumb lol

Let me blow your mind with another phrase.. “ladies first”!

@Cyanide I think blowing one's mind is more sufficient with the topic of "Responsive vs Adaptive". Right now, I'm trying to insert layout methods in my handbook, but I'm stuck with these two seemingly interchanegable terms.

how many past projects of yours do you have to fix now @nitnip? 🤡

I'm not sold on Tailwind yet. Doesn't seem to simplify much - I mean....class="w-16 h-16 rounded text-white bg-black py-1 px-2 m-1 text-sm md:w-32 md:h-32 md:rounded-md md:text-base lg:w-48 lg:h-48 lg:rounded-lg lg:text-lg" ...I feel like I could just use a few simple Sass/Less classes and get the same result.

@heyheni
All of them. Now that I understand how breakpoints work better, I feel like the optimal way to develop with mobile responsiveness in mind is literally "mobile-first".

Make a markup for mobile, then make that markup look good for the 768px breakpoint, then for the 1024px breakpoint, then for the 1280px breakpoint and so on and so forth. I think it should be easier to go from mobile res to desktop res than doing it the other way around (as I always do).

@ojt-rant This was how I felt with tailwind 1. Right now, I feel tailwind's strengths lie not in its many, many classes but in the way you combine those many many classes with variants (breakpoints like sm:, md:, lg:, states like hover:, focus:, active:, and themes like dark:)

You can end up with something like this

<section class="section">
<a href="#" class="link"></a>
</section>

Just by writing the following on your compilable css

.section {
@apply border-gray-300 bg-gray-300 border rounded-lg dark:border-gray-800 dark:bg-gray-800;
}

.link {
@apply p-2 text-gray-800 hover:text-black hover:bg-gray-500 dark:text-gray-300 dark:hover:text-white dark:hover:bg-blue-800
}

Notice I don't have to declare any pseudo extra classes for hover like I'd usually have to ( .link:hover {} ), and I'm able to combine variants (dark:hover.)

@nitnip The approach you describe is really nice: just sort out these classes by utility in separate @apply statements - get less trouble reading it all a month later. @apply-ing classes has uses: when the superclass you write is gonna be reused a lot and when components are utterly verbose for this purpose.

But what I'd like to point out the most is the advantages of utility-first in HTML:
+ use plain old classes and play with them in devtools (use checkboxes, type less, try more);
+ let framework like Vue/Angular decide on which utility classes get included and when, depending on the state;
+ stop jumping between stylesheet and template - if components are an option, declare everything in template and only delegate to CSS a complex part (animations, list transitions, etc.).