And how we can improve with a practical example.

MystPi

Gleam

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

CSS is more like putting their hand in the pain box from Dune while some product manager has a gom jabbar to their neck, daring them to pull their hand out. Despite the latest advancements in CSS, many are still stuck in this kind of BEM mindset, trying to encapsulate everything.

Why we're bad at CSS

I think this is the first CSS article I have ever read that gives an actually good reason for using inline styles… lol. never saw that coming…
but although the concept is interesting, I would still avoid that myself… I worry that using the <code>style</code> prop to override class-specific CSS variables will get just as verbose and difficult to read as the Tailwind example, especially if you also like super clear (read: verbose) variable names.
using the same card example, I prefer to define all the main CSS variables scoped to one-or-more classes, and attached to the outer-most card element. this allows other variables to override these from classes with a higher specificity, which is dead simple to do with nesting in SCSS.
still… that was a very interesting read, good food for thought. :)

I love these articles about a single component Utilities vs Vanilla CSS comparison.
They make no sense what so ever.
They often end up with something like <code>cool-text-interactive</code>, which is a completely meaningless class name. It’s not shorter then <code>color:$text-color</code>, nor more maintainable.
Yes, CSS, is the most “future-proof” way to write CSS.
Yes, frameworks add complexity and dependencies to your project.
But… try to make comparison for a project with hundreds of pages.
I would love to see, how authors of such articles explains, how to write CSS, how to split each component into dozens of CSS files to a beginner and how to set up linters, checkers and other tools to check unused CSS, duplicates, incorrect specificity and unused variations… Nobody writes that, because it’s not that simple to write these articles, neither to explain that.
:D. But hey, le’ts write the css correctly, it’s simple… <a href="https://stylifycss.com/en/docs/get-started/why-stylify-css/" target="_blank" rel="noopener nofollow">No, it’s not</a>. (even a CSS for a small blog can turn into a mess)
The reason, why devs were complaining about AMP project 50 KB CSS limit was, because they were not able to write it so small. It can be done only with utilities or a ton of time spend by optimizing your “framework”.
But with frameworks like <a href="https://stylifycss.com" target="_blank" rel="noopener nofollow">Stylify CSS</a> or Tailwind, you can do it without spending any time on optimization. Because IT IS DONE AUTOMATICALLY. The same way like Laravel and Next solves your SSR and contextual escaping (which you could do manually, except, very probably, in a wrong way).
The author is right about the courses and writting though. There is a lot of “copy pasting” and “less studying/thinking” in these days. I would also say, there is missing a part about “chrome only testing/no testing at all”. It’s probably caused by “the hype” about frameworks and “less time” to ship something.

chatgpt has fixed all of my CSS struggles haha

Sure, let’s compare these two approaches. The choice between Tailwind CSS and CSS preprocessors like SASS or SCSS often comes down to the type of project you’re working on, your team’s preferences, and your own workflow. Here are some key considerations:
<ol>
<li>
Utility-First vs. Traditional CSS:
<ul>
<li>Tailwind CSS is a utility-first CSS framework. This means it provides low-level utility classes that let you build completely custom designs without ever leaving your HTML. The example you gave, <code>&quot;text-sky-500 dark:text-sky-400&quot;</code>, is a clear instance of this utility-first approach. Each class modifies one or a few CSS properties, making it easy to create complex designs directly in your HTML. This approach is great for maintaining consistency and can make it faster to prototype and develop new interfaces, but it can lead to heavy HTML and potentially affect readability.</li>
<li>SASS/SCSS, on the other hand, use a more traditional CSS approach. They provide variables, mixins, nesting, and more, allowing you to write more maintainable and DRY (Don’t Repeat Yourself) CSS. They are great when you have complex styling that would benefit from the use of functions, loops, or other programming constructs.</li>
</ul>
</li>
<li>
Workflow and Maintainability:
<ul>
<li>With Tailwind CSS, since you’re composing your styles in the HTML, your CSS file stays small and maintainable, even for larger projects. It also has excellent customization options, making it easier to maintain a consistent design system.</li>
<li>With SASS/SCSS, stylesheets are broken down into smaller files or modules, making your styles easier to manage, especially for larger projects with complex styles. However, it can lead to larger CSS files if not managed properly.</li>
</ul>
</li>
<li>
Learning Curve and Adoption:
<ul>
<li>Tailwind CSS may initially appear verbose, but its consistent naming convention makes it easy to remember the classes once you’re used to it. It might take time for developers new to this approach to get comfortable with it.</li>
<li>SASS/SCSS has a more traditional syntax which might be easier to grasp for developers with a background in CSS. It’s also widely adopted in the industry, so there’s a larger community and more resources available for help.</li>
</ul>
</li>
<li>
Performance:
<ul>
<li>Tailwind CSS, despite the large number of classes, ends up generating a small production CSS file due to its PurgeCSS feature which removes unused styles.</li>
<li>SASS/SCSS doesn’t come with a built-in solution to reduce the file size, and may require additional setup or tools to ensure that the final CSS file isn’t unnecessarily large.</li>
</ul>
</li>
<li>
Tooling and Ecosystem:
<ul>
<li>Tailwind CSS is growing in popularity and has good tooling available, including plugins for popular text editors, and integrations with frameworks like Vue.js and React.</li>
<li>SASS/SCSS has been around for longer and has mature tooling and widespread support across different environments.</li>
</ul>
</li>
</ol>
In conclusion, both Tailwind CSS and SASS/SCSS have their own strengths and weaknesses. It would be best to choose based on your specific project requirements, team’s skill set, and personal preference. They can also be used together if desired, as Tailwind can be used within SASS/SCSS files.

as backend i wrote flexbox more than my logic in bk 😂