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

61–70 of 246 posts

Re: In defense of functional CSS

#61

Post by jasim »

koboll wrote: post #9

Most of the "a lot to love" points are also hit by BEM/SMACSS. In regard to this point: >You never have to deal with one instance of a thing needing a slightly different style than the other instances, which screws up your reusable classes. ...what I found was that just as often, I'd need a new Atomic class different in a subtle way from existing ones, and this was annoying to implement because a) it expands the klud…

Tailwind takes care of this. You just need to define your spacings, colors, typography, and a few other details like borders and shadows, and all the classes you'll need are all there. You can use PurgeCSS to trim down the final CSS size to just the classes you use.

Re: In defense of functional CSS

#62

Post by cfv »

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.

Re: In defense of functional CSS

#63

Post by jonahx »

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 styles out of small little semantic utility classes as in the first example above, but you can do that and still have semantically named classes easily enough with a preprocessor.

i'd be curious to hear your thoughts on that. when i've discussed this concern with functional CSS purists they usually just shrug and say something like "you get used to it" or "you just don't need those semantic class names" but i find that response unsatisfactory.

clean, readable markup is so much more pleasant to work with.

Re: In defense of functional CSS

#64

Post by sephware »

hownowbrowncow wrote: post #36

Yikes. I agree that this might help you move quickly when starting a project and might be a fine approach for a small prototype or personal site (or, more unkindly, in a consulting project). But you pay a huge cost: maintainability. There is no encapsulation at all, not to mention the pain of having all these generic classes floating around, colliding with anything that might accidentally match. I’ve worked on projec…

One thing I think CSS frameworks got wrong is mixing layout with style. At the time, maybe it was justified due to lack of layout options. But today, especially with grid, but even flexbox, layout can entirely be done by the framework's consumer, and should probably not be done by the framework itself, which should focus probably mostly on style. Unless of course it's a layout framework, but grid is so flexible and easy to work with that you probably don't need a layout framework. I'll just leave this here https://learncssgrid.com/

Re: In defense of functional CSS

#65

Post by mschaef »

hownowbrowncow wrote: post #36

Yikes. I agree that this might help you move quickly when starting a project and might be a fine approach for a small prototype or personal site (or, more unkindly, in a consulting project). But you pay a huge cost: maintainability. There is no encapsulation at all, not to mention the pain of having all these generic classes floating around, colliding with anything that might accidentally match. I’ve worked on projec…

> Yikes.

Agreed. Wholeheartedly.

> I agree that this might help you move quickly when starting a project

I don't even see this... at least I can't imagine a case where I'd want to replace "background: #333;" with "bg-gray-darker". The CSS has at least been well established for years/decades, and it'll be much easier to find documentation/support/etc.

> But you pay a huge cost: maintainability. There is no encapsulation at all,

He's advocating that the encapsulation happen at the level of templated markup (or JSX, whatever), rather than at the level of CSS classes.

Re: In defense of functional CSS

#66

Post by mschaef »

sephware wrote: post #64
hownowbrowncow wrote: post #36

Yikes. I agree that this might help you move quickly when starting a project and might be a fine approach for a small prototype or personal site (or, more unkindly, in a consulting project). But you pay a huge cost: maintainability. There is no encapsulation at all, not to mention the pain of having all these generic classes floating around, colliding with anything that might accidentally match. I’ve worked on projec…

One thing I think CSS frameworks got wrong is mixing layout with style. At the time, maybe it was justified due to lack of layout options. But today, especially with grid, but even flexbox, layout can entirely be done by the framework's consumer, and should probably not be done by the framework itself, which should focus probably mostly on style. Unless of course it's a layout framework, but grid is so flexible and e…

> One thing I think CSS frameworks got wrong is mixing layout with style.

I think some of this is due to the fact it was originally more about document layout than screen layout. At least the cases where I find CSS (horribly) awkward are cases where I'm trying to do something that falls more into the category of UI layout. For document formatting, it feels like a much better fit.

Re: In defense of functional CSS

#67

Post by darekkay »

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…

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.

Re: In defense of functional CSS

#68

Post by crazygringo »

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 one of the buttons needs to have slightly more margin-top than the others, then it's easy to fix.

That's just... bizarre, sorry.

It's infinitely better programming practice to use a "button" CSS class, because then every time you want to tweak all buttons on the site, you tweak it in one place. With 100 buttons in different places, can you imagine the maintenance nightmare?

The author suggests creating button HTML templates instead... but why? That's what CSS already does. And when one button needs more margin or whatever other unique tweak... you just add an additional class so it becomes e.g. class="button button-extra-spaced".

For the life of me I can't see any advantages to the "functional CSS" described here at all -- it looks like a nightmare programming practice.

Re: In defense of functional CSS

#69

Post by keehun »

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…

It seems like at least his favorite css framework (tailwind) wants you to use @apply instead? https://tailwindcss.com/docs/functions-and-directives#apply

Re: In defense of functional CSS

#70

Post by bootsz »

Everything old is new again (sort of). There was a similar paradigm being promoted several years back that was dubbed "Object-Oriented CSS (OOCSS)": https://www.smashingmagazine.com/2011/12/an-introduction-to-...

It's a little unfortunate that the use of the terms "functional" and "object-oriented" were chosen in these cases as they can easily be confused with functional vs. OO programming, when in reality CSS or any paradigm of writing CSS has nothing to do with this distinction.

Post reply on HN