image created by Margaux Peltat for the Chilled Cow YouTube channel
Time for #DEVDiscuss — right here on DEV 😎
Inspired by @mapleleaf's Top 7 post, tonight’s topic is...CSS libraries, frameworks, and engines! 🏗️
There are so many different ways to implement CSS, thanks to frameworks such as Tailwind, Sass, Bootstrap, MaterialUI, and more. From the above post, I learned that UnoCSS is unique to these in that it's an engine, not a framework—there are no core utilities. 💡
Questions:
- Do you prefer a CSS framework or a CSS engine?
- What are the advantages (and disadvantages) of your preferred approach?
- Which are your favorite CSS libraries, frameworks, and engines? Why?
- Which are your least favorite, and why?
- And if you prefer vanilla CSS...why? 🍦
- Any triumphs, fails, or other stories you'd like to share on this topic?
Top comments (8)
I keep having discussions about CSS frameworks (or whatever category Tailwind falls into) and recently decided to stop using SCSS at least in my personal projects, now that we even have native nesting.
It depends on the use case how to use CSS best.
Developers and webmasters with little knowledge and practice can benefit a lot from functional class likes like Tailwind provides, but only if they can control the HTML markup. WordPress, its block editor, and its plugins often produce markup lacking class names, but adding inline styles, and lacking the option to change their markup without hackish PHP hooks, making it hard to apply styles in any way. WordPress setups are also notorious for using jQuery in 2023.
There are many other reasons to functional CSS, but I won't go into details, as I still tend to the opposite view, as I like to write minimal, elegant, vanilla CSS to apply to semantic markup.
Without any concept, this can lead to a unmaintainable chaotic legacy code soon, so I try to adhere to ABEM and apply a more modular ("atomic") approach to web development, but everything with a pragmatic "grain of salt".
I think it depends on the size of the project structure. As CSS layers aren't production ready, we still benefit from Sass @use / @forward scoping and namespacing, also with Sass we can benefit from file componentization but without having to request every file.
Tailwind solves the overhead of developers having to take design decisions, every tailwind class lives within its design system, making it very straightforward to make design tokens changes and cleanup with JIT. But as we can benefit from this, we lose the hability to create a CSS architecture, making us hostage of tailwind directives.
IMHO there is no perfect solution for CSS scalability problems other than having a team with good CSS knowledge and taking time to analyse the pros and cons of the available CSS tooling and taking an informed decision.
I've never tried CSS engine before. So I will stick with framework.
I'm currently still a college student and my schedules are quite busy. A fast and reliable CSS framework is what I need. Until now, Bootstrap 5 still fulfill my needs. It has many components to use to make UI. Some basic things like color palette and fonts can be customized easily with SASS.
Sometimes people differentiate framework as component-based and utility-based. But in my opinion, we cannot easily categorize as component or utility-based because Bootstrap itself has a plenty of utility classes that can be used to make a UI. And that utility classes is what makes me still comfortable with Bootstrap.
But I know there's limitation to Bootstrap. However all of its component is not completely customizable. Because of that, currently I'm also learning Tailwind CSS. I found that Tailwind is very convenient to make a UI that's fully customizable as I'd like because basically Tailwind is just CSS that's integrated with class name.
I'm currently falling in love with Tailwind, TBH. I've done a lot of work with Zurb Foundation and Bootstrap in the past, but I'm really digging Tailwind's way of doing things.
I prefer libraries, as apposed to frameworks or engines.
It's easy to use in conjunction with HTML, and integrate into webpages (both hosted and client-side).
I have no favorites (that aren't my own).
(Though, I do hope Spark could become someone's favorite.)
None.
... Because I don't have much experience with any libraries, frameworks, or engines.
I like CSS libraries, which are basically just collections ov vanilla CSS files.
I prefer vanilla CSS because it just works with the browser - no compilation or interpretation required.
This was a triumph.("this" is referring to the Spark CSS library.)
I prefer frameworks. It gives you more options than engines.
Quicker front-end development, giving more time to make it look way better before deployment.
Tailwind. It's the GOAT🏆
Sass, because you actually have to write everything yourself.
If I can get away with it, I like classless CSS, e.g. a stylesheet that I can just drop into my markup without adding additional classes. For a few examples, see: cssbed.com/
This works reasonably well for smaller, more document-oriented websites. With web application the markup soon needs to play multiple roles (for example: a ul can be a bulleted list or can represent breadcrumbs, or a progress can either be displayed as linear or circular) and the classless approach reaches its limits.
If CSS engine means I need javascript to write my styles, then it's a hard pass on CSS engines (but I always thought a CSS engine is the part of a browser that interprets the stylesheets it found and adjusts the layout)
As a principle: the fewer moving parts in the build, the better.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.