Why Tailwind CSS Won

No, Utility Classes Aren't the Same As Inline Styles

https://frontstuff.io/no-utility-classes-arent-the-same-as-i...

While that's true, it also means you need to propagate all of your exceptions for support of old browsers. And you still need a ton of global styles so your application can be re-themed or white-labeled according to your customer specifications. And god forbid someone applies a color directly in a component and you have to grep the codebase looking for the errant code.

After 5 years of tailwind on several complex applications, I can say that it's been easier to maintain, especially as engineers come and go, than any of the applications I worked on before. Frankly, every company I've ever worked for wound up with something like their own bespoke tailwind anyway, but instead of having it well-documented, every new hire had to learn whatever naming system whoever wrote the global design styles decided on.

> I believe both React and Vue have the capability to scope your CSS along with the components. Modular CSS has been much easier to maintain over years than fixing when Tailwind updates or finding (again) that one !important that happens to conflict with a new released component set.

In my experience that's empirically false. Maybe if you only care about Chrome, but CSS is hell to maintain when you need to keep support for browsers like pre-blink Edge.

   
      
      Blah

   

   
      ...

   .unique-component-name {
      ...

Learning A can be pretty quick for some basics, learning B is a rabbit hole that can take ages to 'learn'. The good news is most of what you need is for something 'competent' is in A

To answer your points below:

1) Front load your design. The equivalent to Pseudocode for the Front-End is to wireframe. Consider all of your pieces, how they should be grouped, and why. There are some common patterns you'll run into in everyday life. If you find those patterns, draw them on a piece of paper (or your editor of choice, you could do it with mspaint if you wanna). Then you can write out your HTML/CSS. I typically work back and forth. All the HTML, then I CSS, then more html if needed, then more css. etc.

2) An effective Front-End is one which gets the user where they want to go with as little friction *as possible*. Emphasis on as-possible because, just like asap, it doesn't mean "yesterday" it means, "Please prioritize this task above other tasks". An effective FE has a clear idea of purpose and wastes no time achieving those goals. Also, see patterns above. This might not be useful yet but one pattern is to look at the shape of what you're trying to display and allow that to dictate the FE. As an example - almost all documentation sites have a left (or right, or floating) vertical navigation, it takes up maybe 10% of screen width, and then the content of that documentation fill the rest of the width with some amount of padding on the left and right. Consider flipping this pattern. Make the Nav horizontal and the documentation full width to get a feel for why most documentation looks the way it does.

2.1) Some terms to search, "Elements of Art and Principles of Design". I recommend everyone look them up - there are ~20 ideas that reference how we go about making something aesthetic.( Art - color, form, line, shape, space, texture, and value ; Design contrast, balance, emphasis, proportion, hierarchy, repetition, rhythm, pattern, white space, movement, variety, and unity )

3) Uh this is a bit more complicated than I can do in a single comment but maybe we can share discord names if you like the cut of my jib so far.