--- title: Why we're bad at CSS | daily.dev description: 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.... canonical: https://daily.dev/posts/why-we-re-bad-at-css-xay7hnmqw twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Why we're bad at CSS | daily.dev og:description: 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.... og:url: https://daily.dev/posts/why-we-re-bad-at-css-xay7hnmqw og:image: https://api.daily.dev/og/posts/xay7hNMQW.png og:image:alt: Why we're bad at CSS og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why we're bad at CSS **[Community Picks](https://daily.dev/sources/community)** · 10 min read · 212 upvotes · 19 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community discussion Top comments from developers on daily.dev. **@ghost** · 10 upvotes > 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 `style` 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.... **@machy8** · 8 upvotes > 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 `cool-text-interactive`, which is a completely meaningless class name. It's not shorter then `color:$text-color`, 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... **@tabascoweb3** · 4 upvotes > chatgpt has fixed all of my CSS struggles haha **@bigjpg** · 3 upvotes > 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: > > 1. **Utility-First vs. Traditional CSS:** > - 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, `"text-sky-500 dark:text-sky-400"`, is a clear instance of this utility-first approach. Each... **@abdulali** · 2 upvotes > as backend i wrote flexbox more than my logic in bk 😂 ## Similar posts on daily.dev - [Don’t just attend KubeCon \+ CloudNativeCon, Merge Forward your experience\!](https://daily.dev/posts/don-t-just-attend-kubecon-cloudnativecon-merge-forward-your-experience--l0rpp73x8) · CNCF · 1 upvotes · 0 comments - [Announcing H2 2026 KCDs](https://daily.dev/posts/announcing-h2-2026-kcds-m96goajm1) · CNCF · 1 upvotes · 0 comments - [Two months of Open Community Groups](https://daily.dev/posts/two-months-of-open-community-groups-asf52zhbs) · CNCF · 0 upvotes · 0 comments --- Tags: [#css](https://daily.dev/tags/css), [#tailwind-css](https://daily.dev/tags/tailwind-css), [#design-systems](https://daily.dev/tags/design-systems) [View this post on daily.dev](https://daily.dev/posts/why-we-re-bad-at-css-xay7hnmqw) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Why we're bad at CSS","url":"https://daily.dev/posts/why-we-re-bad-at-css-xay7hnmqw","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/why-we-re-bad-at-css-xay7hnmqw"},"datePublished":"2023-05-24T18:09:10.593Z","dateModified":"2023-12-07T12:02:45.284Z","description":"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....","image":"https://mikeaparicio.com/images/pain-box.gif","thumbnailUrl":"https://mikeaparicio.com/images/pain-box.gif","isAccessibleForFree":true,"articleSection":"Community Picks","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Community Picks","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1655817725/logos/community","url":"https://daily.dev/sources/community"},"commentCount":19,"discussionUrl":"https://daily.dev/posts/why-we-re-bad-at-css-xay7hnmqw","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":212},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":19}],"keywords":"css,tailwind-css,design-systems","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Community Picks","item":"https://daily.dev/sources/community"},{"@type":"ListItem","position":3,"name":"Why we're bad at CSS"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/why-we-re-bad-at-css-xay7hnmqw","comment":[{"@type":"Comment","text":"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…\nbut although the concept is interesting, I would still avoid that myself… I worry that using the style 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.\nusing 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.\nstill… that was a very interesting read, good food for thought. :)","datePublished":"2023-05-24T18:44:49.163Z","url":"https://daily.dev/posts/xay7hNMQW#c-tQWUxJfq6","author":{"@type":"Person","name":"Deleted user","url":"https://daily.dev/ghost","image":"https://media.daily.dev/image/upload/s--hNIUzLiO--/f_auto/v1705327420/public/ghost_vlftth"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":10}},{"@type":"Comment","text":"I love these articles about a single component Utilities vs Vanilla CSS comparison.\nThey make no sense what so ever.\nThey often end up with something like cool-text-interactive, which is a completely meaningless class name. It’s not shorter then color:$text-color, nor more maintainable.\nYes, CSS, is the most “future-proof” way to write CSS.\nYes, frameworks add complexity and dependencies to your project.\nBut… try to make comparison for a project with hundreds of pages.\nI 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.\n:D. But hey, le’ts write the css correctly, it’s simple… No, it’s not. (even a CSS for a small blog can turn into a mess)\nThe 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”.\nBut with frameworks like Stylify CSS 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).\nThe 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.","datePublished":"2023-05-24T19:44:23.345Z","dateModified":"2023-05-24T19:54:23.363Z","url":"https://daily.dev/posts/xay7hNMQW#c-mq52FwGrs","author":{"@type":"Person","name":"Vladimír Macháček","url":"https://daily.dev/machy8","image":"https://avatars.githubusercontent.com/u/14016808?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":8}},{"@type":"Comment","text":"chatgpt has fixed all of my CSS struggles haha","datePublished":"2023-05-24T23:02:12.962Z","url":"https://daily.dev/posts/xay7hNMQW#c-LQ3MoWM5j","author":{"@type":"Person","name":"TABASCOweb3","url":"https://daily.dev/tabascoweb3","image":"https://avatars.githubusercontent.com/u/84655644?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}},{"@type":"Comment","text":"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:\n\n\nUtility-First vs. Traditional CSS:\n\nTailwind 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, "text-sky-500 dark:text-sky-400", 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.\nSASS/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.\n\n\n\nWorkflow and Maintainability:\n\nWith 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.\nWith 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.\n\n\n\nLearning Curve and Adoption:\n\nTailwind 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.\nSASS/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.\n\n\n\nPerformance:\n\nTailwind CSS, despite the large number of classes, ends up generating a small production CSS file due to its PurgeCSS feature which removes unused styles.\nSASS/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.\n\n\n\nTooling and Ecosystem:\n\nTailwind 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.\nSASS/SCSS has been around for longer and has mature tooling and widespread support across different environments.\n\n\n\nIn 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.","datePublished":"2023-05-26T02:24:39.589Z","url":"https://daily.dev/posts/xay7hNMQW#c-iMmjJvvkJ","author":{"@type":"Person","name":"Ross Farrell","url":"https://daily.dev/bigjpg","image":"https://avatars.githubusercontent.com/u/56429528?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"as backend i wrote flexbox more than my logic in bk 😂","datePublished":"2023-05-24T20:42:19.509Z","url":"https://daily.dev/posts/xay7hNMQW#c-V4eP9mvtN","author":{"@type":"Person","name":"Abdulali","url":"https://daily.dev/abdulali","image":"https://avatars1.githubusercontent.com/u/29580490?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}}]} ```