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

91–100 of 246 posts

Re: In defense of functional CSS

#91

Post by lgessler »

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…

Yeah, I really don't get it. As for this part:

> 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

You can have this with semantic classnames. In fact, that's exactly what the "cascading"[1] part of "cascading style sheets" was intended to solve.

[1]: http://cssspecificity.com/

Re: In defense of functional CSS

#92

Post by jonahx »

camgunz wrote: post #84
jonahx wrote: post #63

Earlier quoted context omitted.

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…

Yes, this is valid to point out as a tradeoff.

I weight clean markup and "knowing immediately where i am by looking at the code" more heavily in this particular balance scale, though -- it's a higher-level concern in some sense.

Practically speaking, I'd typically have the markup open side by side with the SASS (or other source CSS) file where "profile-card" was defined in vim, so the lookup process is just moving my eyes across the page.

Re: In defense of functional CSS

#93

Post by risto1 »

I've used BEM, atomic design and functional CSS. I actually like some kind of combination of all three. This is my 2c:

The pros of functional CSS as a replacement for CSS/SASS variables:

- You define your 'palette' up front: which margins, font sizes, colors are acceptable, etc. You could do something similar with CSS/SASS variables, but you'd give up the capability to rapidly prototype on any machine with any browser and you'd need HMR set up everywhere. Also since it's a class you can (de)compose it with other classes and build up 'abstractions'. So I'm really using functional CSS as a better replacement for SASS variables.

- It's easiest to start hacking away at designing widgets without worrying about things looking inconsistent eventually, because you're working with a limited palette

And then what I take out of atomic CSS is splitting up the code into different levels. Instead of atoms, molecules, organisms, I have: palette, abstractions, components. Abstractions are composed of other abstractions and/or things from the palette. Ie: an abstracted class might be like: .center-vertical, .center-horizontal, and then composing those would give the .center class. Components are concrete widgets like buttons, popovers, modals, tables, lists, etc.

And I use the submodule idea from BEM. So if I need to create custom themes, it would be the like .button .button-(theme name) and writing the theme works just like inheritance would here but I'd be using composition instead

Re: In defense of functional CSS

#94

Post by vinceguidry »

I'd call this style "compositional" rather than "functional". You're composing an element's style from smaller chunks.

My main problem with this is that some people like working that way and some people don't. This leads to a mish-mash where you have two completely different places to look for where your styling might be. Since you can't specify all of your styles in this fashion, then in order for there to be one spot where the styles live, putting them in CSS files with semantic classes is the sensible default.

My other problem with it is that it encourages many DOM elements with one style each as opposed to fewer elements with more style rules. I feel like I'm swimming whenever I'm looking through the markup with an inspector.

More ideally what I'd like to see is styled-components, so the entirety of a component lives all in one code file. I don't particularly care for the use of javascript to specify literally everything on the page, from the markup to behavior to styling, but the siren song of having everything there in one place makes up for it. If you want terseness in style definition, which is the main problem this "functional" approach solves, then you can simply invoke short javascript functions.

My ideal approach though actually would lean on a text editor / IDE to keep a list of components, and opening up the markup, styling, and scripting of a component all at the same time, and just using HTML templates, SCSS, and vanilla Javascript, keeping each file unsullied by the syntax and semantics of the other languages.

I'm unconvinced that everything really needs to be Javascript, but I don't mind wandering down that rabbit hole with everybody else until the React fascination passes. It's not the worst way in the world to specify UI.

Re: In defense of functional CSS

#95

Post by DevX101 »

This thread is why I love HackerNews. I'm in the middle of considering something like this w/ Tailwinds and share some of the concerns expressed in some comments here, but I'm still keeping an open mind.

Is there anyone who's tried it for a project and still hated it? Seems like a lot of the detractors haven't actually used it yet.

Re: In defense of functional CSS

#96

Post by Spivak »

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…

> The author suggests creating button HTML templates instead... but why? That's what CSS already does

I think this is really the core of it, because CSS is kind of bad at it, and just about every project ships with more powerful HTML templating anyway.

Re: In defense of functional CSS

#97

Post by ravenstine »

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 was wondering that as well. By that point, though, I've never found a point in using utility classes when I can just go to the file for my current component and edit it directly. Just writing specific CSS for my components and page-layouts while using shared variables has saved me way more time than any CSS library I've used. 99% of CSS libraries are full of problems

Re: In defense of functional CSS

#98

Post by DevX101 »

mcrittenden wrote: post #85

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

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

Re: In defense of functional CSS

#99

Post by darekkay »

blauditore wrote: post #81
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.

You're right. My main point was to separate your code by purpose instead of technology. That's where component-based development is heading to. If you're using components, then you're still free to choose one or another CSS aproach, but most functional CSS downsides don't apply anymore.

My team in fact combines both approaches. I don't need to define a CSS component just to add some margin, but I am also free not to use 15 functional classes to clutter the HTML.

Re: In defense of functional CSS

#100

Post by mcrittenden »

DevX101 wrote: post #98
mcrittenden wrote: post #85

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

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.

Post reply on HN