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

211–220 of 246 posts

Re: In defense of functional CSS

#211

Post by wvenable »

aphextron wrote: post #208
wvenable wrote: post #198

Earlier quoted context omitted.

> Then when the next PM wants this button to be blue, you make another utility class and end up editing HTML. So you're suggestion that when the PM wants this button to be blue, you make another component for that button? You haven't changed the problem, or the amount of work, you are just using a different layer to implement it.

> You haven't changed the problem, or the amount of work, you are just using a different layer to implement it. Changing the layer you're implementing on is the whole point. It's about maintainability and keeping things encapsulated. Now when someone comes back to look at this button a year later, they're not left wondering why this usage of "Button" is colored blue, and tracking down the utility class. They will kno…

How is a component called BlueButton more informative than ? The information content is exactly the same.

Now, more than likely the component isn't called BlueButton and the CSS class isn't called "blue" but rather both would have a name more semantically appropriate.

Re: In defense of functional CSS

#212

Post by bennofs »

mschaef wrote: post #65
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 encapsulati…

The big difference between this and "background: #333" is that in the later case it could also be "background: #334" or "background: #435". The functional framework approach forces a minimal amount of consistency.

Re: In defense of functional CSS

#213

Post by mind-blight »

I've been a semantic CSS proponent for years, but I'm intrigued. CSS puts everything in a global namespace, which is an anti-pattern everywhere else. Most modern approaches have been moving towards limiting the scope of Cascading (CSS Module, Styled Components).

The semantic approach forces you to generalize your HTML up front and leads to over-engineering styles. Plus JS component libraries make refactoring across a project a lot simpler.

Re: In defense of functional CSS

#214

Post by tracker1 »

I think, in the end, I'd much rather use JavaScript + React + react-jss for this kind of work. It's actually really nice with material-ui and re-using most options from the theme and/or existing components. yeah, 2/3 of my app come from react-dom and material-ui, but at the same time it's very consistent, easy to inherit from and easier to comprehend.

Web-Components may help someday, but so long as component properties are effectively strings, and hard to pass in from the outside, same for events, it makes it harder to manage discreetly.

Re: In defense of functional CSS

#215

Post by swaggyBoatswain »

criswell wrote: post #109
meandmycode wrote: post #47

As a frontend developer of 15-20 years now I've been pretty dumbfounded and unconvinced by any arguments for this style of css, I think it's especially hard for frontend developers of such duration because this is effectively the first ever style of css you write, and then you were force fed xhtml, semantic web and then later responsive became the "Told you so!" of the methodology. Despite my scepticism of extremes o…

I'm a frontend developer of about 15 years as well and I think functional css makes a lot of sense. My biggest argument for it is not having to name every thing. You know how many times I've had to think of a name for a random container that exists simply to align some crap? Then if you need another wrapper or something for that for some reason? It eliminates the name game (whenever you want it to).

this sounds like me. I spend more time looking at a thesaurus than I do CSS articles

Re: In defense of functional CSS

#216

Post by achairapart »

dwaite wrote: post #204
achairapart wrote: post #167

Earlier quoted context omitted.

1. Think about this: You have to write or customize .profile-card for every project, with "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" you're writing 0 lines of CSS. Zero. All your CSS will be your utility framework (sizes around 5~15kb) and it will never increase in size. Now, tell me you never seen a two year project where CSS alone reached 2+Mb because at every edit someone added another class…

> At the end, I don't want to defend to death this practice. I tried to phrase things such that I didn't seem to come across as aggressive. We all have such limited views of the world, and opinions are an expression of those views. I found attempting to understand other opinions can widen your own viewpoint, sometimes in surprising ways :-) My expectation of what people would give as their three benefits are as follo…

I'm sorry, didn't want to appear aggressive either. Maybe when I wrote my comment I was influenced by the great number of negative comments here, but obviously, nothing personal!

Maybe there is a lot of confusion also because the naming of this methodology. The whole "functional" thing. It's funny that the very same practice has also been called "Atomic CSS" and "Object-Oriented CSS (OOCSS)"(!).

I would name it "Non-Cascading Style Sheets" because the whole point is actually giving away most of the "C" in "CSS".

I was also thinking that another point of such negativity may be that to use it you have to somehow master all the CSS rules, where not-so-experienced developers may rely on some "trial and error" or some bad pratice (eg. adding many nested selectors) to achive the same result. I might be wrong.

I remember that there are tools that throw a warning when a class is mutated (ie. overwritten by another rule) because you don't really want to - let's say - add a border when using something like "bg-gray-darker".

Yes, this practice can be a great choice for component frameworks. But it's also great for rapid prototyping and designing UI components or whole web pages directly in the browser.

And for templated HTML pages you can be more expressive using something like

    "profile-card: m-5 p-5 text-gray-light bg-gray-darker border border-gray-light"
Where the "profile-card:" bit has no effect on the presentation but gives the code reader an insight of the markup.

I actually used to do something like this at first during prototyping/designing, but then I stopped. Maybe just because at some point I became so accustomed that I was able to catch every part of the page at first sight.

Re: In defense of functional CSS

#217

Post by swaggyBoatswain »

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

Great article. The author mentions all the pain points I went through designing a mid-sized sass base... there's just too many ways to do things and it gets messy fast. It's hard to be both semantic and DRY at the same time.

Might as well just treat everything the same across the board, e.g. tailwinds and reduce the overall complexity of naming

I read many functional CSS articles but this one has convinced me to try it out

Re: In defense of functional CSS

#219

Post by Semiapies »

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…

Personally, I like a compositional approach, but the "text-color-white" business is just cringeworthy. There's nothing about compositional/functional approach that requires someone to use silly just-above-an-inline-style classes.

    
        Warning: frobnitz is dangling.  Please address.
I gather it's because ridiculously literal styles are the only thing you can offer in an "un-opinionated" functional framework, because you'd otherwise have to engage in some styling.

ETA: And even "alert-colors" could probably be "alert" or the like, if I saw the consistent need to bold the text or whatever in alerts.

Re: In defense of functional CSS

#220

Post by rhizome »

Izkata wrote: post #168
ashelmire wrote: post #155

Earlier quoted context omitted.

> - How many times do I have to change all the buttons on my app? When making a styling change like this, it's typical to change it app-wide. > - 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? I can change the border-radius on all of my buttons, and they will all change, and still have their color-specif…

> Phew! A component just for a button. What a twist! I don't think most people are making components for each html element. In fact, I'd say this is pretty redundant and overengineering things in a bad way. Welcome to the world of web components. This is actually really common, especially in React with css modules - this way you can use your custom button without even having to think about the CSS (or any extra compl…

I want to call this "transverse encapsulation."
Post reply on HN