Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of functional CSS

mikecr.it

Post reply on HN
Print view View original

71–80 of 246 posts

Re: In defense of functional CSS

#71

Post by every_other »

crazygringo wrote: post #68

How is this any different from saying "don't write functions, just repeat the same 10 lines the function would have in each place you'd use the function"? The real kicker: > "I don't want to have to repeat the same 20 classes on every single button." That's understandable. I will say that there's a chance that repeating those 20 classes can actually be somewhat valuable, because when you get into a situation where on…

I'm not sure why that was suggested. Our team has migrated to utility css (Tailwind) and we never do this. The basic approaches are either to create a component or template for the button and put the utility class there or use Tailwind's `@apply` utility to create a `.button` class with the utilities applied to that class.

I had some reservations at first but in practice it's been pretty much universally agreed to be great for us. It removes a huge amounts of css cruft that happens over time (unable to determine which classes are still being used, where, etc), keeps colors, margins, etc. standardized through a centralized config file and prevents you from constantly bouncing back and forth between style and markup files.

Re: In defense of functional CSS

#72

Post by jonahx »

darekkay wrote: post #67
jonahx wrote: post #63

Earlier quoted context omitted.

so i'm on board with your central concern here. my issue with functional css is that your markup has no semantics. you can't just look at it and know what things are by their names. ie, what the hell is that thing described by all those styles? versus: and i know immediately what it is, and can instantly map the markup to what i see on the page. you just lose too much by not having that imo. i really like composing s…

One possible solution is in the article - nothing prevents you from using: with "profile-card" being use just for identifying the component. Other than that, I rarely go through HTML without Dev Tools, which shows me exactly what a certain div is for.

yeah that's better than nothing, but your markup is still super noisy and hard to scan.

> Other than that, I rarely go through HTML without Dev Tools, which shows me exactly what a certain div is for.

I do all the time. I'd much prefer to work in my text editor, without being obliged to use chrome tools to extract semantic meaning from my code.

Re: In defense of functional CSS

#73

Post by naasking »

nailer wrote: post #38
naasking wrote: post #22

Earlier quoted context omitted.

> If .login-box is now going to be larger but green, you'd normally just edit the CSS to change that. No you don't, you can edit the one LESS/SASS/whatever file, and rebuild to reflect the change in your custom class that mixes in the desired properties, done. Or you do the same in your HTML templating language. All of the code reuse patterns you're used to from regular programming are applicable here, and that's why…

I think you misread my comment. By 'normally' I mean using regular 'CSS controls how something looks' HTML, and not using visual class names (that this author calls 'functional CSS').

I quoted the wrong sentence, I meant to reply to the "you'd have to edit the HTML" aspect. Functional CSS lets you wrap up composite styles in various ways, similar to abstracting a function in normal programming, so you don't necessarily have to do this. You can though, and it's often simpler to do so.

Re: In defense of functional CSS

#74

Post by naasking »

HelloNurse wrote: post #46
naasking wrote: post #20

Earlier quoted context omitted.

> If you have lots of repeated components on a page (comments, thumbnails, tags) then it's difficult to defend repeating, potentially dozens, of the same declarations. That's where you have two choices: 1. Use your HTML templating language to define a dynamic variable representing the set of classes and use that. 2. Like the article says, make use of the functional CSS's tools to create a new class that includes the…

Both "solutions" don't address the problem of repeated class names, they just help repeating them in a correct but not less obscene way. Bloated markup cannot be defended.

Yes they do, at least in a way that's no worse than every other CSS toolkit in widespread use.

And there's nothing "correct" or "incorrect" about it. I suggest reading [1] if you want some real data on the usefulness of functional CSS.

[1] https://hackernoon.com/full-re-write-with-tachyons-and-funct...

Re: In defense of functional CSS

#75

Post by dyeje »

Like most things, the best approach lies somewhere in the middle. I’ve had a lot of success with using component driven CSS (BEM, SMACSS, etc style) in combination with utility classes. The components keep everything consistent and make building pages much faster. The utility classes let you do the inevitable little tweaks without a bunch of one off, weird component modifier classes.

Re: In defense of functional CSS

#77

Post by darekkay »

Wow, this gets some real hate on HN. I highly recommend reading [0] instead (which is by the way linked in the main article).

If you're writing HTML by hand, then yes, it will be a PITA changing all those "bg-blue" Profile Cards using functional CSS (while it's just a single change when using .profile-card instead). In reality, it's not the functional CSS being the issue, but the markup duplication. If I extract a real reusable ProfileCard component, I can apply functional CSS to it exactly once. If the color changes, it's just a single place I need to look into.

There is no silver bullet. If you design web sites, try some templating language to extract your components. If you develop web apps, take any modern framework like React, which enforces using reusable components. If you still prefer writing HTML by hand, then yes, functional CSS is not for you.

[0] https://adamwathan.me/css-utility-classes-and-separation-of-...

Re: In defense of functional CSS

#78

Post by darekkay »

crazygringo wrote: post #68

How is this any different from saying "don't write functions, just repeat the same 10 lines the function would have in each place you'd use the function"? The real kicker: > "I don't want to have to repeat the same 20 classes on every single button." That's understandable. I will say that there's a chance that repeating those 20 classes can actually be somewhat valuable, because when you get into a situation where on…

> Because then every time you want to tweak all buttons on the site, you tweak it in one place.

What do you do, when the button markup changes? Let's say you need to make all links open in a new window? Then you still need to change 100 buttons. It's even more common for bigger components, like the ProfileCard example. What if the markup of your ProfileCard changes?

Instead of using CSS to define your components, I suggest using some real reusable components, either using templates or JS frameworks (depending on your use case).

Re: In defense of functional CSS

#79

Post by realusername »

cfv wrote: post #62

But wait, what exactly is so hard about doing something like // _profile.scss .profile-card { @extend .m-5; // several more lines of extending @extend border-gray-light; } and just get the best of both worlds? That variant also has the advantage of letting us JS folk use element classes for useful stuff, and makes changing all instances of "profile-card" simultaneously a lot simpler.

I don't get it as well, I just looked at Tailwind which is mentioned and it just seem to be a collection of css soup which don't mean anything, I think I would be lost quickly in a codebase with only this css soup.

Re: In defense of functional CSS

#80

Post by dangerface »

This is really bad advice.

You reduce errors by reducing code by wrapping your code in functions, thats functional and its how classes work. This article suggests the opposite just write everything from scratch perfectly, not going to happen.

> there's nothing stopping you from continuing to add those semantic classes, even if they're irrelevant for styling If they are irrelevant to style then it could be applied to anything, it has no meaning and is not semantic.

They don't know what separation of concerns is, or why its a good thing.

>when you get into a situation where one of the buttons needs to have slightly more margin-top than the others

Yea just break your designs consistency im sure your users will love that.

Post reply on HN