Deprecate glamorous 💄 in favor of emotion 👩‍🎤

[kentcdodds]

For a long time now I've been considering deprecating glamorous (NOT glamorous-native) in favor of emotion.

Here's my reasoning:

1. Emotion can do everything glamorous can do
2. Emotion can do more than glamorous can do
3. Emotion is faster than glamorous
4. Emotion is smaller than glamorous
5. It's good for the community to consolidate and rally around using and improving a single solution

I would not recommend people spend a bunch of time migrating to emotion. glamorous isn't bad, it's just not as good as emotion and I don't think it would be worth the effort to manually migrate. That said, I'm fairly confident that a codemod could be written to automatically migrate your glamorous code to emotion.

What a deprecation would mean:

• I would add a notice to the README and website indicating that this project is no longer maintained and encouraging people to use emotion instead.

What a deprecation would NOT mean:

• glamorous-native is still the best-in-class for styling native applications and is entirely separate from glamorous. It would NOT be deprecated. It is an entirely separate project with no shared dependencies anyway, so a deprecation of glamorous wouldn't impact glamorous-native directly.

What I want from you:

Please give this a 👍 if you agree or a 👎 if you disagree.

If you disagree, please list reasons why and whether you would be willing to assume the maintainer role.

Thanks friends!

[kentcdodds]

Things are looking very positive for this. If someone would like to help a LOT of people here are a few things you could do:

1. Write a migration guide. It could be a simple markdown file here.
2. Write a codemod. If you don't have any experience with ASTs then this might be a bit of a challenge for you. I have some resources for you though:

• Writing custom Babel and ESLint plugins with ASTs: A 53 minute talk by @kentcdodds
• babel-handbook: A guided handbook on how to use Babel and how to create plugins for Babel by @thejameskyle
• Code Transformation and Linting: A workshop (recording available on Frontend Masters) with exercises of making custom Babel and ESLint plugins

A good starting point for the codemod could be the one I wrote for upgrading people's version of glamorous due to the theme breaking change we had a few months ago: https://github.com/paypal/glamorous/blob/master/other/codemods/theme-move.js

I don't think that I'll have time to do either of these things any time soon, but I'd love it if anyone would like to pitch in to do it :)

I'm 99% certain that we'll be doing this.

[morajabi]

I can think of one concern, this move can confuse people (like some already asked) and raise this question that what would happen to glamorous-native again and again. Adding a notice mentioning "This is actively maintained" or something like that in that project's readme would be helpful :)

[rob-swu]

nice! I recently migrated our entire codebase from glamorous to emotion. I'll see if I have some cycles to write up some of the things I did to migrate and any gotchas I ran into

[Ailrun]

One thing that can (probably) confuse people is TS support. Emotion's TS support is quite immature compared to Glamorous. It does almost nothing with CSS typing, does not have proper plugin type, ...

[kentcdodds]

@Ailrun, that is a very valid concern and I'm sure it would be frustrating for folks like you and others who have poured a TON of effort into making glamorous as great as it is with regards to TypeScript. Hopefully by switching to emotion we can combine efforts with other folks to take the things we've learned from glamorous to improve the Typings in emotion.

[Ailrun]

@kentcdodds Hm... then, I should spend some time on emotion typing to move there safely. Thank you for kind comment.

[quicksnap]

Does anyone have a react+emotion demo repo/codepen or something I could test a few things with?

My primary use case with Glamorous has been css-object composition+ThemeProvider--nested arrays of objects or functions-returning-objects. I'd like to validate that emotion can work with some of those patterns.

Soon enough I'll test it out, but if there's already a codesandbox or something I could test things very quickly.

@kentcdodds You're making a very awesome decision to rally around a single solution. Love the direction here.

[brentertz]

@kentcdodds Emotion does not seem to have any notion of prop filtering, and the associated API's rootEl, filterProps, forwardProps, like Glamorous does. Was this a difficult thing to maintain in Glamorous? Any thoughts on how to approach if migrating to Emotion? The library that I work on relies on it pretty heavily at present.

---

Update: Apparently Emotion supports a shouldForwardProp option and also has a @emotion/is-prop-valid package. Investigating further...

---

Update: Emotion has similar capabilities, but as usual, the devil is in the details. It does not appear that this will be a simple migration. Need time to investigate further, but unfortunately don't have it at present. Issues documented in mineral-ui/mineral-ui#692

[kentcdodds]

Interesting. Could you file an issue on emotion @brentertz? Let's see if this is something they'd be willing to implement. Either that or we could implement a small layer on top of emotion that could do this.

[Andarist]

@quicksnap

My primary use case with Glamorous has been css-object composition+ThemeProvider--nested arrays of objects or functions-returning-objects. I'd like to validate that emotion can work with some of those patterns.

Emotion should handle all that jazz just fine. We use it on production and receiving serializable theme objects through the wire + ofc we use some local functions etc to style based on props.