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 p

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.