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

81–90 of 246 posts

Re: In defense of functional CSS

#81

Post by blauditore »

darekkay wrote: post #77

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 re…

> 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.

Then you're basically moving re-use from CSS to HTML templates. And if both exist only once, it shouldn't matter where you have to adjust that one line.

Re: In defense of functional CSS

#82

Post by jpetitcolas »

Another interesting CSS framework taking this approach: UniversalCSS: https://github.com/marmelab/universal.css

A few advantages: self-documented classnames, zero dependencies, classnames are reusable across projects, removes the need for a CSS preprocessor or bundler, no need to switch between HTML and CSS file while developing, etc...

Re: In defense of functional CSS

#83

Post by Flenser »

groby_b wrote: post #53
Flenser wrote: post #28

What about theming/branding so that you can make your enterprise web-app fit in with each of your clients other web-apps? If your class names are semantic like profile-card it's easy to have a branding css file for each client. If your class names are functional like m-5 p-5 text-gray-light bg-gray-darker border border-gray-light you're going to... what? make code changes for each client? Obviously if the website is…

Even if you only have one client - do you really want to manually hunt down all profile-card instances and update the styling anytime you need to change the styling? And if you had a bug related to profile-card styling, are you going to find all cards to update the styling? Are you sure you didn't forget some? This approach seems to be based on the idea that design is completely immutable after the initial conception…

It's unclear to me the problem you are addressing. Searching for places to make amendments is an important consideration when naming something. I would have thought that class names like "profile-card" would be easier to search for than "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light". Especially if you have some page elements which may look the same now but are functionally different and could look different in the future. How would you find one and not the other?

Is that the problem you were addressing or did you have something different in mind?

Re: In defense of functional CSS

#84

Post by camgunz »

jonahx wrote: post #63
chrisweekly wrote: post #21

Functional CSS is a terrific approach. Tailwind in particular is exemplary. Absent this approach, in web projects of nearly any size, the CSS inevitably grows and becomes increasingly difficult to maintain. It takes very very few cases of "I'll just write a bit more CSS" as the default solution to bug fixes or changing requirements, before the best-intentioned design system becomes a brittle nightmare. Whereas functi…

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…

From the other perspective, I know what "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" will look like and I can immediately change it. I have no idea what "profile-card" does, and if it's ultimately something I don't like I have to go through the whole asset pipeline to change it.

I'm not saying you're wrong, I think I'm more or less against functional CSS, but just saying there's at least one more way to look at it.

Re: In defense of functional CSS

#85

Post by mcrittenden »

Author here. In retrospect a couple months after writing this post, I don't love it. I still am in love with Tailwind and Functional CSS, but I did a poor job defending it.

I'd suggest that everyone read this post [1] by Adam Wathan, the creator of Tailwind CSS. It does a much better job explaining and defending than I did.

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

Re: In defense of functional CSS

#86

Post by meandmycode »

darekkay wrote: post #77

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 re…

It's a much better article, but really jumps the shark by the end, and the reasoning to convince become very unsound, like suggesting you'd only end up with ridiculous classes like 'image-card-with-a-full-width-section-and-a-split-section' .. but no I wouldn't.. I wouldn't ever put layout in a class name (full width), I'd call it the hero, priority or whatever it was semantically, which is a discussion with the ui/ux members of the team.

Composing utility classes via css (ala, what many have done for years since sass/less) is one thing, but then collapsing the component class all the way back to the html I really can only describe as jumping the shark, it's gone beyond logic.

Re: In defense of functional CSS

#87

Post by DanielBMarkham »

Semaphor wrote: post #59
Flenser wrote: post #39

Earlier quoted context omitted.

You could do this with SASS or LESS. Make all the "functional" classes as abstract mixins or placeholder selectors (in SASS parlance), and then use them to define your concrete semantic classes.

variables and mixins, clean css, readable templates instead of some overloaded hodgepodge of classes.

Yeah. I was reading this thinking "If only we had some way of abstractly creating CSS!"

Which of course we already do. Maybe there's a case that the toolchain or conventions need tweaking. So it's worth the discussion in my mind. Most times you really don't realize what you need from a tool/framework until you've reinvented it, so we need folks like this doing sanity checks on where the rest of the industry is going.

Re: In defense of functional CSS

#88

Post by drinchev »

Using sketch / photoshop these days gives you "Copy CSS Attributes" functionality for most of the elements, which is basically 50% of your CSS, the rest is layouts ( super easy these days with flex box / grid ), media queries and probably some more.

I agree that Cascading part of the CSS is very troubling, but I don't think functional CSS solves it in an elegant way. Actually I think it's hardly readable and confusing :(

As of the argument that you don't need to write CSS properties anymore, I would suggest using a plugin like Emmet [1].

(1): https://docs.emmet.io/css-abbreviations/

Re: In defense of functional CSS

#89

Post by toastercat »

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…

> 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"?

I think it is more comparable to using function composition, hence the whole "Functional CSS" moniker. The idea is using multiple atomic "functions" (in this case, in the form of classes) to transform an element by composing.

Think like the pipe operator in Elixir:

other_function() |> new_function() |> baz() |> bar() |> foo()

Re: In defense of functional CSS

#90

Post by Existenceblinks »

The way people using CSS ties to the way they write markup. I like to think like thinking about Big O; read, insert, delete, update. Database design involves this kind of thinking too. What operation you do most on your data structure (html in this case)

Atomic CSS

What's time complexity for each operation(by human)?

Read: O(sigh)

Insert: O(1)

Delete: O(n)

Update: O(n)

Pre-BEM era CSS

What's time complexity for each operation(by human)?

Read: kinda O(1)

Insert: O(1)

Delete: O(1) without garbage collect (unused css)

Update: kinda O(n^n)

That's a quick thought, maybe your operations are more arbitrary.

Probably when someone introduces new css framework/technique, showing some kind of complexity measurement (if possible) would be good idea?

Post reply on HN