Use emotion instead of glamor as the backing library

[wegry]

The last commit for glamor was over a year ago..

In the issue thread linked above, the maintainer mentions that emotion has mostly the same API. This mostly seems to be true, the differences being stuff around rule insertion and @fontface.

[giraud]

it seems to be a big change, forcing users to change their dependencies.
what emotion do that is not working in glamor ?

[wegry]

Hi @giraud. thanks for the work you've done on this project. This project is the biggest css in bucklescript project right? It's been a dream to work with. I think it's important to rally around the existing project instead of forking.

The switch is easier to sell because the interface doesn't change, #92 is largely quality of life changes.

• Emotion is actively maintained and largely identical interface wise. Use emotion instead of glamor #92 is a drop in replacement for [email protected].
• Browserslist support (don't use ancient vendor prefixes). Working with grid, glamor uses a lot of the old -ms-grid and -webkit-grid prefixes. With emotion, and the same interface to bucklescript consumers, only the legacy prefixes that are requested are used. Browserslist's defaults still contain IE11.
• Fixes Losing styles when merging nested selectors #86. Merging styles works as expected with subselectors. And styles that the order of application matters for are picked up correctly[*]. For example, border followed by border-left doesn't work like it does in regular CSS. This might work in glamor too, but I'm going from memory on that.

[giraud]

These are good arguments.

Are you aware of any performance differences between the two libraries ?

I'm thinking that there might be a way we could have a functor to create a Glamor module and an Emotion module from the same interface and keep some backward compatibility.

[wegry]

Are you aware of any performance differences between the two libraries ?

I might dig in between the two on the weekend over this.

I'm thinking that there might be a way we could have a functor to create a Glamor module and an Emotion module from the same interface and keep some backward compatibility.

At least for now, for webpack users, aliasing emotion -> glamor would work for those continuing using glamor. The one spot where it would not work is the merge function. That's probably critical though. #92 potentially could be reworked to support both emotion and glamor's style merging (i.e. not using cx in emotion).

[giraud]

I played with the idea of having different backends : I pushed that test in the backend branch.
I played with functors : it creates a contract for css backend libraries.
In that case, the Css module doesn't seem impacted (I didn't tested toroughly) and we can propose a Css.Emotion, or swap them in future.
But the thing is I don't know the downsides of using functors, does it make sense ?

[baldurh]

@giraud I think that’s unnecessarily complicated. The author of glamor seems to now recommend using emotion (threepointone/glamor#360 (comment)) so I think the maintainers of bs-css should just make a desicion to move away from glamor and do a major release since it might have breaking changes. I believe it’s a good step moving forward.

[baldurh]

And if we do a major release we could also do a breaking change to the merge functionality in the same release—If you think that is a good idea, that is. Personally I think the current merge functionality is broken and does not make sense in this context since it’s just concatenating the lists and we know it produces unexpected results.

[giraud]

ok, I'm with the move to emotion with a major update.

[wegry]

Since #94 has been merged in, I'm going to close this.