66
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Aug 2023
66 points (100.0% liked)
Programming
13361 readers
45 users here now
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
That's actually my intent with using a CSS framework. A personal project of mine reached minimum viable product ~~statud~~ status (phones...) recently, I included bulma, and used some of its components for stuff like menus and modals. It was definitely faster than writing everything by hand early on. But I also ended up writing my own CSS anyway, especially with the grid, which is the foundation on which my app works on (it's a grid-based colour mixing app).
I agree, I think CSS frameworks have a place for prototyping and we shouldn't rely on them as a project moves towards a proper release 🤔
Then again, some people might think the obfuscation in 20+ classes is somehow a good thing...frankly, I think it's worse than inline styles. It's basically obfuscated inline styles!
I'd argue that CSS is itself an obfuscation (read: abstraction), and isn't even implemented consistently across browsers. If the abstraction results in less duplication, more consistency across the website, and higher productivity, then I don't think that's a bad thing. (Of course, the flip side is that if using the abstraction results in the same learning curve with less transparency, then the benefits might not outweigh the cost.)
Having never used tailwind, I can't give a personal opinion on that, but I find it hard to work on any decently sized project without SCSS. Sure I can write pure CSS, but SCSS provides so many QoL features over raw CSS that it's hard to pass it up, and it's easy enough to get setup.
I mentioned some of this in another comment in this thread[^1], but CSS has gotten tremendously better since Sass was first introduced in the 00s. Many features we used are now native to CSS, and can be used in your browser, today. Some of them are even better than their sass variants, or at least have special abilities sass doesn't.
calc()comes to mind, as it can mix and match units in a way a preprocessor just cant. You can docalc(100% - 10px), which is good for all sorts of stupid corner cases.And native CSS nesting is basically 1:1 with how Sass does it:
I still use Sass or Stylus[^2] on virtually all of my projects, but its nice to not have to when you just need to get something out or write a userstyle or something.
[^1]: Not sure how to provide an instance agnostic link, the few things I've seen people attempt didn't work, but here's the lemdro.id link [^2]: I'm largely giving up on Stylus, its sadly unmaintained. My favorite preprocessor though; takes
.sass(indented) style to a whole new level on what you can omitWait CSS supports nesting? Since when?
Also, SASS's mixins, variables (CSS has variables too but they work differently), and many of the other features are hard to beat, which is why I feel like it's almost never a negative to get it up and running on any project I work on (unless the project is a tiny one-off, then it's probably not worth it). One thing I like is that it's close to CSS - increasing the transparency - while still providing abstractions that let you save time and increase consistency across the project.
Landed earlier this year :D
I used to really use mixins a ton, but these days I haven't really written any in a good long time. Still useful, still something plain-ol-css can't do, but I've found autoprefixer has managed to handle most of my mixin needs.