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

121–130 of 246 posts

Re: In defense of functional CSS

#121

Post by collyw »

lucideer wrote: post #19
collyw wrote: post #8

Earlier quoted context omitted.

I often wonder how useful this septation actually is. Most of the apps I have worked on seem to be horribly coupled despite separate css.

You can introduce implicit coupling in any app (i.e. in a non-CSS programming language). It's bad practice in both cases. This kind of separation doesn't magically make your frontend code good, it just gives you the freedom to architect it well. Whether you do is up to you. Admittedly it is very difficult to find an example where this has been done well, but this is I guess why we have abominations like AMP.

Sure it is bad design, I won't argue with you on that.

But the other thing is that we rarely upgrade just CSS, usually we get a whole new front end, or even more likely a whole new app.

Re: In defense of functional CSS

#122

Post by Rumudiez »

I moved away from “utility-first” CSS in favor of heavy usage of SASS mixins. If you can modularize your CSS to the degree shown in Tailwind, then you can get the best of both worlds by keeping your class names in BEM while the underlying SASS is primarily composed mixins.

Referencing the OP’s example in short:

  #m-5 {
    margin: 20px;
  }
  .card {
    @extend #m-5;
    /* custom styles */
  }
Edit: formatting

Re: In defense of functional CSS

#123

Post by yakshaving_jgt »

bootsz wrote: post #70

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…

This was my first thought too.

There's nothing novel here. There's just a misunderstanding of how CSS works, an over-engineered solution to a non-existent problem, and then a misused name added for a veneer of sophistication.

Re: In defense of functional CSS

#124

Post by ryanto »

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 think for css classes like ".profile-card" this approach makes a lot of sense. Tailwind has @apply, which is a great way to turn these utility classes into named css classes.

However, after a while your app will end up with classes like .profile-card--inner, .profile-card__wrapper, and .profile-card__inner__wrapper--horizontal. When that happens it's usually easier to use those utility classes directly in the HTML template. You'll end up with something like:
It's quick to write and requires no context switching!

Re: In defense of functional CSS

#125

Post by darekkay »

yakshaving_jgt wrote: post #110
darekkay wrote: post #78

Earlier quoted context omitted.

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

Open up Vim, and do a global find and replace with a simple regex. That's 100 or even 10,000 button changes in a minute. That's not really related to "functional CSS" though.

Your simple regex will take you 1-2 additional minutes to deal with prettified code like this:

  Button
And when you start fixing more complex components and HTML edge cases, you will have a lot of fun [0]. This is fine for legacy code. But I don't want to deal with this in modern projects, if I can just change a single file and be sure all components are updated. As you said, this is not related to functional CSS, but it solves many disvantages of it.

[0] https://stackoverflow.com/questions/1732348/regex-match-open...

Re: In defense of functional CSS

#126

Post by komali2 »

every_other wrote: post #71
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…

We do this with less + bootstrap. So we'll have have something like

.button-critical{ .btn .btn-red }

Re: In defense of functional CSS

#127

Post by Zelphyr »

Oh God. Please don't let this be a thing. I hate to be negative but this is a bad direction for a set of technologies (HTML/CSS/JS) that have already veered heavily down a miserable path.

Re: In defense of functional CSS

#128

Post by WorldMaker »

have_faith wrote: post #57
dsego wrote: post #31

Earlier quoted context omitted.

In my experience, more often than not, the opposite is happening. The designer wants the same widget to have a slightly different style in different places. Then you either give it some additional class for context or use helper classes. Benefits of either approach seem to be moot. Reusability suffers in any case.

I've found this is (usually) solved with soft skills. I just talk to the designer and explain we have all these very similar components already and it will help with the visual consistency if we follow an existing convention OR update the existing convention to use the new style (giving them the option to choose let's them stay in control of the design). They are usually very understanding as they don't always consid…

It's also rarely a surprise that if you ask "why did you special case this particular [button/widget]?" to some designers the answer turns out to be "I didn't have a good template and just redrew it" or "I don't know, I was just freehanding that because I was in the flow".

Re: In defense of functional CSS

#129

Post by dagenix »

SamuelAdams wrote: post #111
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…

100% agree with you. I stopped reading after this statement: >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. It's easy to fix in "regular" css too: just add style="margin-top: 10px;" to the button. If this is really a one-off situation, then that is totally fine. Functional CSS feels like over-engineering an already-solved problem.

I really hate the phrase "over-engineering". My oppinion is that at this point, its is nothing more than a fancy way to say - "I think this is bad" (or sometimes worse: "I don't understand this, and since I don't understand it, it must be bad").

And this is a great example of that theory. If one had to apply the terms "over" or "under" to describe the engineering of the practice the article describes, it seems like "under engineered" would be the more apt description. This is pure brute force programming and design.

Re: In defense of functional CSS

#130

Post by tambourine_man »

Problem is, defining quantity in the class name doesn’t work.

.m10 may be fine for desktop but not for mobile.

Then you’ll have media queries which define .m10 as margin: 5px or something, which is nuts.

You could go for unspecified .mSmall etc, but in real life, things tend to be more specific and messier, in my experience.

Post reply on HN