Live data from Hacker News

In defense of functional CSS

mikecr.it

131–140 of 246 posts

Re: In defense of functional CSS

#131

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

> What do you do, when the button markup changes?

hopefully you'd have a Button component in your preferred UI framework, and you'd change it once there.

Re: In defense of functional CSS

#132

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…

This has essentially been my experience with using this. I don't see how it even comes close to 'functional' in style, it just feels like it makes CSS even more painful to deal with than it already is.

Working with CSS is fairly unglamourous. These functional frameworks don't really appear to be a solution to me. What they've done is basically take CSS and create a DSL that has to squeeze into a `class` attribute, without actually adding any extra value than what you would get from writing raw CSS. You don't really get consistency out of it. Just terseness.

This becomes even more bizarre when you see these frameworks used with preprocessors like postcss, because what you end up with then is basically spaghetti.

    .some-button {
      @compose mt-2 my-4 p3 border-radius flex align-bottom;
      margin-right: 32px;
      border-radius-bottom-right: 2rem;

      &:disabled {
        display: none;
      }
    }
At what point did all of this become an advantage?

Re: In defense of functional CSS

#133

Earlier quoted context omitted.

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

It's actually nothing to do with the pipe operator in Elixir. In any programming language, the order in which you compose functions is important. In CSS — and in keeping with your analogy — the order in which "functions" are defined is important.

> In any programming language, the order in which you compose functions is important.

Not really

    [3,2,1] |> map(x => x * 2) |> sort
is the same of

    [3,2,1] |> sort |> map(x => x * 2)

Re: In defense of functional CSS

#134

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…

First line of the first example you get in "what is Tailwind":

  
Just accept the fact your HTML contains your styling and go with:

  
There was a time when people thought CSS could be used to style some logical HTML:

  
So the day you want to change the color of your card-wrapper from white to green you can change a line in some CSS and not have to go around all your HTML or end with a with a green background.

CSS frameworks feel like a "let's get all the shit CSS was meant to help remove and just put it in divs".

Re: In defense of functional CSS

#135
As usual maybe it is wiser to take the good parts from different approaches, rather than going "all in" with one ideology / methodology.

For my sites I find it useful to have a small collection of very generic classes. One common case that was annoying is how the spacing keeps changing as you move text and components around a page, and you end up fiddling with the rules all the time to adjust for how the top/bottom margins merge. No matter how "logical" it is, from a graphic design pt of view, the spacing is right when it looks right.

So I have a few very generic classes like this:

    .mb-0   { margin-bottom:0; }
    .mb-1   { margin-bottom:1em; }
    .mb-2   { margin-bottom:2em; }

     /* text */
    .txt-lg { font-size:1.4em; }
    .ta-r   { text-align:right; }
    .ws-nw  { white-space:nowrap; }
These are useful for making small adjutments to the layout. That said, going all in with atomic css doesn't make sense to me.

Re: In defense of functional CSS

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

You're changing the source order doing this which can get messy plus generating a lot of long selectors. Example:

  .m4, .profile-card, .other-card,
  .header, .foo, blah {
    margin: 4em;
  }

Re: In defense of functional CSS

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

Most of the people commenting are missing one of the major point in "functional CSS": Keep specifity low = lower code size, less side-effects, higher maintainability.

Yes, you add bits of complexity in the HTML, but you also gain almost no specifity on the CSS side.

Re: In defense of functional CSS

#138

As usual maybe it is wiser to take the good parts from different approaches, rather than going "all in" with one ideology / methodology. For my sites I find it useful to have a small collection of very generic classes. One common case that was annoying is how the spacing keeps changing as you move text and components around a page, and you end up fiddling with the rules all the time to adjust for how the top/bottom m…

I do the same. I have a scss file with a few margin and padding mixins that I can throw into the dom when I need to. Otherwise, I'll stick with updating all my buttons at once in my css `button` class.

Re: In defense of functional CSS

#139

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…

Disclaimer: we have been using functional css for about 2 years.

Let's review the main use case you present "I want to tweak all buttons on the site, I tweak it in one place":

- How many times do I have to change all the buttons on my app?

- Does changing one class work to change all buttons in practice? Don't I end up having the color overloaded 3 times, cascading over and leaking in 5 others spots?

- Are most of my edits in CSS tweaking existing rules, or piling up more CSS? Usually, in a large codebase, I end up just adding a class instead of tweaking one and figuring out if I broke anything anywhere.

- If I use a component-based approach, like Angular or React, do I really have to change classes everywhere with functional css, or just in the button component?

- Is styling "functional"? Can I always change the styling of a class without changing its semantics - like if I put the primary button the same as the secondary, did the naming help?

Your case may be different and our point of view may also evolve. With functional CSS + component-based approach, I rarely have to use the style inspector - and produce beautiful, maintainable app with 14KB of CSS and no styling bug. All my other attempts using CSS "the right way" lead me to 1MB+ of CSS.

The benefits of CSS to factor style by function seems very infrequent compared to the problems they introduce.

Re: In defense of functional CSS

#140
That seems much more procedural than functional. There's nothing functional about "set this element a 5px margin and a light gray text and a darker background and a light gray border" which is quite literally the statement of the first snippet's @class.

Composing .profile-card out of these could be a functional approach, but you're just writing @style via @class.

Post reply on HN