4 ms·
i know it's in semi-jest, but what a non-argument lol. 44 util classes just to not learn the one line on which those utility classes are based on? if you want
by ookblah 3y ago
i know it's in semi-jest, but what a non-argument lol. 44 util classes just to not learn the one line on which those utility classes are based on? if you want to hate on these types of things you can at least have a point of view that makes sense.
tired of people who've never seemed to use CSS beyond some pet project or stuck in early 2000s (all frameworks are dumb!) mindset make the wrong arguments over and over again.
- sirsinsalot 3y agoNot defending OPs POV but you're reading between the lines an awful lot and making value judgements. Perhaps they use frameworks and write CSS at scale. You don't know and failed to enquire, instead becoming defensive and robbing the circumstance of the chance for productive conversation. Shame.
- ookblah 3y agolol what? op is the one insinuating anyone using utility classes are ones that don't bother to learn a line of CSS which is untrue, so I find it curious your criticism is directed solely at me. Value judgement for value judgement, I'd say the snark both ways is pretty fair. More than welcome to explain their pov.
- toastal 3y agoUtility classes are meant for utility purposes, not to replace CSS, but you see so many projects out in the wild now terrified to have a classname that’s relevant to the topic which makes it harder to organize, but also harder to select for userStyles, filter lists, etc. (i.e. if you make a FooWidget, add the .FooWidget class so real folks can read/parse thru the code easier for their needs …or just for their knowledge of what others are doing, and maybe actually put some styles on that bad boy instead of every property being behind a util). I have spoken with some engineers that only know how to speak Bootstrap or Tailwind, & not a lick of CSS. This isn’t just 2000s thinking to consider pumping the brakes a little as utilities at this point have definitely blown out into ‘overuse’ & ‘overreliance’, but these things come in cycles with a new idea taken to an extreme before we swing back to only semantic markup & selectors on element names again before the next pendulum swing. Even still, utilities aren’t a new idea, but just part of how reusable classes in CSS can just work – and rolling out with massive block of utility CSS that are mapped one-to-one with a single property is in the ‘smell’ territory.
- bijuice 3y agoIf you know how to write tailwind, you know how to write CSS. The utility classes it provides are just a sort of shorthand form of CSS. With component based frameworks there isn't much of a need to define CSS classes in my opinion.
- toastal 3y agoIf you know CSS, you can write CSS. Sometimes utilities add indirection that’s harder to follow in the long term—especially with folks that aren’t already using these utilities. In 10 years, will it be easier to follow `mb-5` as medium border 5, middle box-shadow 10, margin block 5rem, min-block-size 10, mix-blend-mode 5, mild black version 5? If the utility has many properties tied to them (e.g. those softer shadows of layered box-shadow) named .stackedShadow--depth3 this sort of utility has earned its value that will be easy to understand why it exists vs. .pt-6 when an explicit value or CSS variable could have sufficed. This doesn’t apply to all cases, or all projects, but I would predict in 5 years the fad of pushing everything into a utility will be dead in favor of moderate usage.
- Kiro 3y agoYes, I also agree that we should use inline styles for everything. The problem with CSS is the C. I don't want to come up with class names or put styles in a separate file or even a separate section in the same file (Vue). I want to look at the tag and immediately see how it's styled. No hidden or indirect styling whatsoever.
- toastal 3y agoMy CSP won’t be happy to include unsafe-inline. Inline styles are hard to override. Not overthinking but I try to put some consideration for the folks using userStyles for their accessibility. Naming things is often hard, but at least with UI you’re usually building something concrete so there should be some name—if not a wrapper that holds more loose parts you can’t easily control (like a #Content element around some reStructuredText output). The cascading part is a double-edged sword tho. It can be used to great effect for good, but it can be unweildy with a disparate or undisciplined team. But it’s often better to work with it rather than fight uphill against the only style engine we have in browsers (if feasible)—the output will generally be smaller & easier to follow with less to know or maintain.
- pessimizer 3y agoI'm tired of people who throw generic garbage on other people's opinions without any explanation. If you have to pretend like you know who other people are and what they've done, you're literally making up evidence for an ad hominem argument against a stranger. If you weren't full of it, you'd defend your position rather than wasting your time denigrating strangers. Even worse, smart people are going to reply to you in order to make your argument for you. So then people to try to have a real discussion within this poisonous context. All over the internet, over and over again.
- ookblah 3y agovalid point, and to be honest i'm tired of reading the same argument over and over about utility classes and having to write out my "defense" over and over, sometimes it's easier to be snarky. to be fair, his initial point didn't make any sense to me and was also of the same flavor of assuming something about people (equating utility classes with people not knowing CSS) and prompted my knee-jerk response. i clarified my point to him in a later reply. seems we did have a fine discussion? but thanks for assuming that i'm full of it lol. ironic in a way that you'd criticize me while throwing the exact same ad hominem when you literally also know nothing about me.