Why Utility Classes?
If you have never used a CSS library like this, it probably seems ridiculous. It seems that we are mixing content and presentation, that we are avoiding using CSS as it was intended, creating unsematic markup, or otherwise making a soup of characters that no one could possibly manage. You may also think this is just a short-hand for inline styles.
Let's take these one at a time.
Mixing content and presentation. There's no denying that placing a class like bg-purple-500 inside HTML is putting visual instructions into the markup. It's worth understanding why this feels like a problem. If the same markup is intended to produce many different visual representations then, yes, mixing presentation instructions into the markup makes it hard to manage. When we build web applications, however, we are rarely doing this.
Most web applications deliver a specific user experience, usually with some slight modifications on different screen sizes. This is not the “CSS Zen Garden” approach and very few web apps need that. If they do, MelangeCSS is not for them. But for most apps, it turns out that putting styling instructions in the markup makes some things easier.
When you open an HTML file and see <a href="/" class="blue-400 f-3">link</a>, you can see that the link is rendered in the third sized font in the dark blue color. If, instead, the value for class was something more abstract like primary-link it would be harder to figure out how that link renders in a browser. Depending on what CSS is included on the page, it could be extremely hard.
These classes are not semantic. The class attribute is ignored by most screen readers. Users who are not viewing your app in a traditional web browser will get semantic information from the tags used. The app can make use of ARIA roles to further clarify. The class attribute is irrelevant. There is no reason or benefit to making its value have semantic meaning. It is entirely a hook for styling.
The terse names are an unmanageable, nonsensical mess of characters. Any verbose code in any programming language can be abstracted or simplified through the use of functional decomposition. Your web app is no different. You can use its templating system to extract re-usable code, when you want, not before.
The terse class names can be hard to learn at first, because a class like fw-4 doesn't seem immediately obvious. But, if you know CSS, understand the naming conventions, and use MelangeCSS for just a small amount of time, you will learn these class names. And you will start to go much faster, because you won't rely on autocomplete or flipping back to the documentation.
Why not just use inline styles, then? MelangeCSS has four differences from inline styles.
The class names are far shorter than their analogous CSS properties and values. Even with sophisticated auto-compete, typing out these terse classes is faster.
Inline styles cannot target media queries to allow for responsive design.
Inline styles have a higher specificity, so they can still use used alongside classes if needed.
Most importantly, Melange includes a grid-based design system. While you can use custom properties in inline styles, it's far more difficult than using classes based on a design system (based on custom properties).
Being able to design and style by selecting from a small set of values vastly increases the speed at which you can produce styled views. You can quickly iterate through all possible spacings, font sizes, or widths and choose the one that works. Yes, you lose the flexibilty of using any of the infinite possible sizes, but you usually don't need that many.
As a demonstration, here are all the buttons you can make with changes to border radius. Surely, one of these will work for you?