41–50 of 246 posts
My experience with functional CSS was skepticism followed by delight. Reading BEM style actually makes me more skeptical now. A class of "Button Button__Primary" tells me much less about the styles of that button than a string of functional CSS classes would.
What about theming/branding so that you can make your enterprise web-app fit in with each of your clients other web-apps? If your class names are semantic like profile-card it's easy to have a branding css file for each client. If your class names are functional like m-5 p-5 text-gray-light bg-gray-darker border border-gray-light you're going to... what? make code changes for each client? Obviously if the website is…
It's all about tradeoffs, there are no silver bullets. If your class name is like profile-card then it could be simpler... until it's not. Because it turns out that one of your client profile-card needs to behave slightly differently on hover or whatever. In theory, profile-card is a great idea, in practice it can be a headache
Why is this named "functional" CSS? Something like "const FIVE = 5" doesn't seem to capture the essence of functional programming either?
I mean, the ONE BEST THING about CSS is its ability to promote consistent styling across a site by creating REUSABLE, NAMED styles that are SEMANTIC and applying them consistently.
Let us run through the author's claimed list of advantages:
> You don't have to write any CSS of your own (which, to me, is fantastic)
This one is an obvious troll.
> You can likely build things faster (obviously non-scientific, but anecdotally I've seen many people confirm this)
The combination of "likely" and "obviously non-scientific" undermines this claim (and rightly so) in the middle of making it.
> You don't ever have to think about naming things
Again, I presume this is a troll. Naming things is hard if you care about having meaningful names. If you don't care, then naming is trivial. This approach eliminates meaningful names so it is hardly a benefit.
> You can tell what something looks like by just reading the markup for it
That one is an actual advantage, and makes me wonder slightly what's going on.
> You don't ever have to worry that changing the styles for one thing will break something else (which may make visual regression testing irrelevant)
Another obvious troll. If you never reuse anything, you'll never have to worry about a change breaking anything else. Also true if you never change anything. Also completely meaningless.
> 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.
True enough... if you never reuse anything, then you never need to worry about the impacts of reuse.
> Your CSS always stays the same size rather than expanding over time
Well, sure! If you move all of the intent out of the CSS file and into longer and more complex style attributes, then the CSS file itself will get shorter (while the length of the CSS file PLUS the style attributes will get longer).
> It's easy to un-apply a style by just removing the class (as opposed to the traditional cascade where you typically have to override, adding even more CSS)
This isn't even well-considered. Using a fixed set of single-visual-effect-not-semantic-intent styles will have no effect on the complexity of cascading. Choosing to apply styles only to individual elements and eschew the use of cascading WILL avoid all the complexity of cascading, but the choice to do that is independent.
> Rendering speed performance is supposedly improved (though I have seen no proof of this)
There is no reason this would be true, and the author isn't even claiming it.
After reading it through, I am beginning to seriously doubt that this was intended as satire. In which case the author is very, VERY wrong. I continue to hope that I am simply missing the joke.
We did this at my last job, but inevitably ended up with a mix of half functional CSS and half component CSS. If you have lots of repeated components on a page (comments, thumbnails, tags) then it's difficult to defend repeating, potentially dozens, of the same declarations. You're better off with the component defined in a stylesheet. I think the real use for functional CSS is for one-off adjustments on those compon…
> If you have lots of repeated components on a page (comments, thumbnails, tags) then it's difficult to defend repeating, potentially dozens, of the same declarations. That's where you have two choices: 1. Use your HTML templating language to define a dynamic variable representing the set of classes and use that. 2. Like the article says, make use of the functional CSS's tools to create a new class that includes the…
Despite my scepticism of extremes of semantic web, I realise now when I read articles talking about switching to this style of css, their problems are entirely unrelatable to me because I implicitly see the conceptual structure of a design vs its visual specifics.
This just feels like a new age of developers don't see the need for the abstraction and so it's a constant mental burden for them without any benefit.. I think what has propped this up is that some of the problems that semantic css has historically only ever been able to solve (such as responsive) are now being solved differently, either through more powerful css layouts that implicitly layout better responsively, or that they rely instead on javascript to switch classes/html/components out with media query listeners.
Ultimately I think whatever you decide should be based on what your team aligns to best, don't feel guilty about 'not getting' this pattern, but I think it's important you pick one way, as mixing these worlds just doesn't work (at a project level), but certainly you should always try new things for new projects or experiments.
I tried using Tachyons for a project and it really broke down when I needed to make really custom components. For instance, one component was a cropping viewport that had to be a set height and width. There really isn't any solution for that other than adding a very specific utility class, or creating a semantic class.
Personally, Tachyons still provides me tremendous value even though I sometimes have to write custom classes. I'm also often surprised to find that something that I thought would need a custom class, could be done with Tachyons when I dug a bit deeper.
CSS has come a long way since CSS Zen Garden.
With CSS grid and flex, you can create components with less markup and small amounts of CSS.
The example on the tailwind site https://tailwindcss.com/docs/what-is-tailwind/ just looks like a steep learning curve to me. I could write that same component with much less HTML and just a few lines of responsive css.