Replace runtime with emotion.js

[roman01la]

CSS-in-JS libraries in JavaScript world are mature enough already so it makes little sense to ignore them. I'd propose to replace library runtime with existing JS library, like Emotion, and make cljss essentially a thin wrapper on top of JS library.

[mattly]

I came here looking for any issues about performance, since a tool I'm using makes heavy use of dynamic styles and I noticed cljss was slowing down the repaints quite a bit.

Replacing cljss with emotion for a single heavily-used dynamic style (that often had to change at least 15 instances on a repaint) took my repaint times from 175ms to 13ms.

[knubie]

@mattly Would you mind sharing how you're using emotion in your cljs project? Are you using the "vanilla" emotion package, or @emotion/styled or something else?

[roman01la]

I've used the one which is published to cljsjs, guess it's vanilla. The only issue with js lib is that it won't work with SSR on JVM

[knubie]

I was just wondering if it needed to be used a certain way to take advantage of the performance benefits, but it doesn't seem like emotion/styled is doing anything special over vanilla emotion.

For example I was surprised to see it wasn't using CSS variables, since I figured swapping out css vars would be more performant than generating entirely new classes each time a prop changes.

[mattly]

I'm using it from npm under shadow-cljs. I replaced my cljss defstyles with a function that called emotion/css in a js primitive, with values determined at call time. My use-case for this particular style could require over 100 variations of it at once, with about 1/5th of those needing repaint on the change of a single value.

[khmelevskii]

FYI, I created a tiny wrapper for emotion https://github.com/khmelevskii/emotion-cljs and maybe it can be useful