[jamescostian]

It sounds like you have experience with the string-heavy CSS in JS. Here's some examples showing how this can be achieved using `csstype.Properties` objects: https://emotion.sh/docs/typescript

I'm sure you can imagine how easy it is to compose functions that accept and return `csstype.Properties` objects, and then at the end, you call `styled` with it to make a styled component. You can even pass styled a function, which takes in runtime-adjustable props, and of course, that function can itself use other functions, passing around those same or some derived runtime-adjustable props.

That said, I have no idea what you mean when you talk about ergonomics being better, can you elaborate? I re-read your initial comment but there wasn't anything in it not achievable in TS using the kinds of things mentioned in the "CSS in JS" section, perhaps there's something else I'm just not aware of? I do not know elm, let alone have experience writing it in non-trivial production codebases, so a concrete example would be great

[matsemann]

Thanks for some explanation. And yeah, I'm probably not up to date on CSS-in-JS, just remember it being really clunky to use before I ended up in an elm-shop a few years back. I'd say that emotion does look similar to what I've described, and nearly there. And I don't think there is anything doable in elm that's not doable in TS/React (it's rather the opposite, elm is the restricted one, mainly on purpose). My point about ergonomics was mostly that it's just elm all the way. No strings or objects or new concepts. The CSS you write in elm is mostly indistinguishable from the other elm view code (html etc) you write, it's all the same syntax etc. While for emotion and others, there is a clear divide in what's React and what's styling, and difference in how you do stuff.