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

141–150 of 246 posts

Re: In defense of functional CSS

#141

Post by darekkay »

beaconstudios wrote: post #131
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…

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

Exactly. The same applies to CSS when using the functional CSS approach. It's basically: if anything changes, I need to update my Button component.

Re: In defense of functional CSS

#142

Post by every_other »

arkh wrote: post #134
every_other wrote: post #71

Earlier quoted context omitted.

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…

Yeah, think that's everyone's first reaction (you shouldn't mix style and markup) but with a component centered development pattern, those concerns largely become non-issues. `card-wrapper` becomes a component and you update your styles there.

I will just say theory aside, in practice, this has worked out great for our team. In my 5+ years experience, I've constantly run across the issue of legacy code with thousands of classes, referencing potentially non-existent markup and countless one-off tweaks. You can start with the best intentions and organization in your SASS files but eventually things start to get really crufty. Keeping everything in components and keeping styles in the markup alleviates a lot of that.

Re: In defense of functional CSS

#143

Post by andrewingram »

darekkay wrote: post #141
beaconstudios wrote: post #131

Earlier quoted context omitted.

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

Exactly. The same applies to CSS when using the functional CSS approach. It's basically: if anything changes, I need to update my Button component.

Right. With the surge in popularity of components architectures, the maintainability concerns of inline styling methods are much less applicable. Perhaps there are other legitimate problems, but this one should be put to bed.

Re: In defense of functional CSS

#144

Post by pknopf »

mcrittenden wrote: post #100
DevX101 wrote: post #98

Earlier quoted context omitted.

To be clear, you don't love the post, or you've changed your mind on functional CSS?

Ah sorry, I just meant I don't love the post (and I just updated my comment to make that more clear). If anything I am even more a fan of functional CSS now than I was when I wrote this. But my post is just a bad defense of it. The section about the separation of concerns is especially unconvincing, and I spent almost no time talking about the benefits of it. I'd like to rewrite it at some point.

Well, hey, I dig the honesty.

Re: In defense of functional CSS

#145

Post by sam0x17 »

every_other wrote: post #142
arkh wrote: post #134

Earlier quoted context omitted.

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…

Yeah, think that's everyone's first reaction (you shouldn't mix style and markup) but with a component centered development pattern, those concerns largely become non-issues. `card-wrapper` becomes a component and you update your styles there. I will just say theory aside, in practice, this has worked out great for our team. In my 5+ years experience, I've constantly run across the issue of legacy code with thousands…

On that note, would love to see developer tools in the major browsers complain with warnings about missing CSS classes :/

Re: In defense of functional CSS

#146

Post by dwaite »

achairapart wrote: post #137
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.

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.

Could you elaborate on this more? All three of these points seem counterintuitive to me.

1. "profile-card" takes fewer bytes than "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light", so the space-savings of not defining profile-card within the CSS seems to be lost the more you reuse semantic styles within your HTML.

2. "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" and "profile-card" should amount to the same CSS styling applied at the same level of specificity in an apples-to-apples comparison, so I'm unsure about side effects. Are you saying that using exclusively functional styling you can count on naming conventions to know if two styles would conflict?

3. "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" looks a heck of a lot harder to maintain than "profile-card" once I have 50 profile cards in my application styling, spread out across multiple app development teams (and even development languages).

Are you saying it provides other maintainability benefits which are cross-cutting improvements that outlay the ability to think of your HTML as being made up of semantic components? Or are you saying that you are relying on component frameworks which make component definition in CSS a duplication?

Re: In defense of functional CSS

#148

Post by cphoover »

I really hate this style.

I think the solution is using elements/components as the means of sharing styles. If you need a slightly different style you extend and modify an existing component. This can be achieved using libraries like `styled-jsx`, `styled-components`. Or hopefully as the shadow-dom spec progresses this will take care of this issue. I also think doing a way with the `scoped` attribute on the style tag was a dumb idea. As it made compartmentalization way easier.

Re: In defense of functional CSS

#149

Post by sam0x17 »

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.

The point of this, imo, though, is instead of having a designer design a bunch of components, you have a designer design a bunch of functional styles that can compose components and still be on-brand. So say you have a component, and you want to add an on-brand/in-style shadow to it, you just add the small-shadow class, instead of digging through the css of other components and copy-pasting their lengthy shadow css. I would use this mainly for shadows, fonts, and margins.

Re: In defense of functional CSS

#150

Post by sam0x17 »

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…

That said, there is nothing saying you can't combine this with some higher level classes when you need to DRY things up.
Post reply on HN