[blog] Add video to the Pigment CSS blog post #42500
Conversation
Netlify deploy previewhttps://deploy-preview-42500--material-ui.netlify.app/ Bundle size report |
| Emotion made a lot of sense for Material UI v5 in late 2021, but so much has changed in the React ecosystem since then. | ||
| Emotion made a lot of sense for Material UI v5.0.0 in late 2021, but so much has changed in the React ecosystem since then. |
There was a problem hiding this comment.
To be clear that we talk about the initial release.
| <a href="https://github.com/mui/pigment-css"> | ||
| <img src="/static/blog/introducing-pigment-css/card.png" alt="Introducing Pigment CSS: the next generation of CSS-in-JS" width="1280" height="640" /> | ||
| </a> |
There was a problem hiding this comment.
Add a link on the image. I tend to try to click those.
|
|
||
| Pigment CSS is MUI's new in-house styling solution: a zero-runtime CSS-in-JS package that generates colocated styles to their own CSS files at build-time. | ||
| With Pigment CSS you get RSC compatibility, _plus_ significant performance improvements when compared with Emotion, the styling engine used in Material UI v5. | ||
| That's where [Pigment CSS](https://github.com/mui/pigment-css) comes in. |
There was a problem hiding this comment.
Link the first reference of it.
There was a problem hiding this comment.
Mixed feelings about this — it invites people to click on a new thing right at the beginning of the post, getting them effectively out of it. I'd prefer to do it later in a more contextualized way (keep it as it was—without the link). (Benchmark: Adam did this in the Tailwind v3 introduction post, too)
There was a problem hiding this comment.
Agreed, would rather not steer the reader away from the blog post before they've read it.
There was a problem hiding this comment.
I have added this here to solve the frustrations I too often feel on blog posts: read the beginning, and it's enough for me (the video in our case). At that point, I'm out of time, I want to play with it, maybe star it. I might come back to it later.
| To learn more about RSCs, we highly recommend reading [Making Sense of React Server Components](https://www.joshwcomeau.com/react/server-components/) by Josh Comeau. | ||
| To learn more about RSCs, we recommend reading [Making Sense of React Server Components](https://www.joshwcomeau.com/react/server-components/) by Josh Comeau. |
There was a problem hiding this comment.
I don't get why "highly".
| While those breaking changes did bring many benefits overall, they unfortunately came with a notoriously painful migration experience. | ||
| While those breaking changes did bring many benefits overall, they unfortunately came with a painful migration experience. |
There was a problem hiding this comment.
I think we can simplify this without losing important information;
oliviertassinari
force-pushed
the
pigment-css-blog-post
branch
2 times, most recently
from
36136c3 to
d8347cd
Compare
| We like the DX of colocated styles, and we'd rather not bloat the DOM with atomic class names—so Tailwind CSS, StyleX, Panda CSS, and other solutions that have cropped up in recent months just don't match up with our preferences. | ||
| We like the DX of colocated styles, and we'd rather not use atomic class names to support nested selectors at scale—so Tailwind CSS, StyleX, Panda CSS, and other solutions that have appeared in recent months didn't match up with our ambitious goals. |
There was a problem hiding this comment.
I don't think DOM size matters much in here.
There was a problem hiding this comment.
other solutions that have appeared in recent months didn't match up with our ambitious goals
What ambitious goals, though? I appreciated how in the original version, we were clearly stating "our preferences", which I think it's an important thing to highlight, given there are already tools that solve problems CSS-in-JS still doesn't, and we're not adhering to them due to preference (perfectly fine reason).
There was a problem hiding this comment.
"ambitious goals" also reads oddly to me, as this is a matter of preferences.
There was a problem hiding this comment.
Ok fixed. I have simplified the content. Atomic class names !== can't support nested selectors at scale.
| Pigment CSS is a zero-runtime CSS-in-JS library: This means it doesn't have access to the end user's browser runtime, which would be necessary to generate and insert authored CSS at run-time. | ||
| Pigment CSS is a zero-runtime CSS-in-JS library: This means it doesn't have access to the end user's browser JavaScript runtime, so it can't use the runtime to generate and insert CSS. |
There was a problem hiding this comment.
Tried to simplify this sentence. I was confused.
| :::info | ||
| To learn more about runtime performance improvements, [check out this app](https://pigment-css-demo.vercel.app/perf) that compares Pigment CSS, Emotion, and styled-components across a variety of tests. | ||
| **Reproduction**. Because you should only trust numbers that you can reproduce, we've shared below how we found these numbers. |
There was a problem hiding this comment.
This wasn't enough to be able to trust the data. I have added what I could find to reproduce this.
oliviertassinari
force-pushed
the
pigment-css-blog-post
branch
2 times, most recently
from
fb39704 to
84088be
Compare
| | First Contentful Paint | 503ms | 455ms | 9% | | ||
| | Time To First Byte | 447.5ms | 381.5ms | 15% | |
There was a problem hiding this comment.
I removed these two rows, they look too flaky to be conclusive. At least, testing with https://www.webpagetest.org/, I saw no real differences.
In theory, FCP should be slower with Pigment CSS per vercel/next.js#59989 (comment) since we our test doesn't inline. But it's because the HTML page is smaller, so an irrelevant row too, removed.
oliviertassinari
force-pushed
the
pigment-css-blog-post
branch
3 times, most recently
from
ab6f50b to
c07b82e
Compare
| | Metrics | Emotion | Pigment CSS | Change | | ||
| | :-------------------------------------- | ------: | ----------: | -----: | | ||
| | Create and mount a new button | 17.3 ms | 10.1 ms | -42% | | ||
| | Change a variant on a mounted component | 14.0 ms | 9.13 ms | -34% | | ||
| | Change a value inside a CSS prop | 13.6 ms | 8.63 ms | -37% | |
There was a problem hiding this comment.
It's not that significant. https://stitches.dev/docs/benchmarks claims almost more. I would want to see how Linaria performs, CSS Modules, Tailwind CSS, I think it would be great to cover those @brijeshb42. I suspect we can get more performance out of this approach.
I have removed the other perf tests as we were not faster, similar to https://github.com/brijeshb42/pigment-css-bench where I couldn't really see performance improvements.
It will be key to validate that it's possible. Now, from my test in https://github.com/oliviertassinari/react-conf-2024-pigment-css/tree/master/benchmark, the performance gain was significant during the runtime: https://react-conf-2024-pigment-css.netlify.app/?slideIndex=34&stepIndex=0.
Sure, I'll do it! |
| ### Better performance | ||
| ### Better page load performance | ||
|
|
||
| When comparing the same Material UI app built with Next.js and either Emotion or Pigment CSS, we've observed the following page load performance gains using the same code, but powered by different style engines: |
There was a problem hiding this comment.
| When comparing the same Material UI app built with Next.js and either Emotion or Pigment CSS, we've observed the following page load performance gains using the same code, but powered by different style engines: | |
| When comparing the same Material UI app built with Next.js and either Emotion or Pigment CSS, we've observed the following page load performance gains using the same code: |
I feel like we can cut this given we're already saying "... either Emotion or Pigment CSS". The table makes it clear the diff in results based on the used engine.
|
|
||
| <!-- vale MUI.CorrectReferenceAllCases = YES --> | ||
|
|
||
| :::info |
There was a problem hiding this comment.
I don't see the need for this to be inside an info callout—it's not extra information. It's directly related to the table above.
There was a problem hiding this comment.
It's meant to allow people to skim read. I have tried without, it felt worst.
| ### Better performance | ||
| ### Better page load performance | ||
|
|
||
| When comparing the same Material UI app built with Next.js and either Emotion or Pigment CSS, we've observed the following page load performance gains using the same code, but powered by different style engines: |
There was a problem hiding this comment.
This sentence has some redundant clauses.
| When comparing the same Material UI app built with Next.js and either Emotion or Pigment CSS, we've observed the following page load performance gains using the same code, but powered by different style engines: | |
| When comparing the same Material UI app built with Next.js and either Emotion or Pigment CSS, we've observed the following page load performance gains: |
I don't think it's reasonable to extrapolate from one post on Twitter that the community isn't interested in this.
I don't think it's especially useful to try to seriously revamp the content of this blog post—it already went through many rounds of drafts, reviews, and edits. What would be better is to continue to create more content as a part of a larger marketing plan to raise awareness about the product. I would rather see the video as its own blog post, for example—even better would be a written transcription to accompany it. The video could serve as the basis for a Twitter thread that outlines the key points. The additional performance benchmarks could form a third blog post, as well as a Twitter thread breaking each of these down one by one. The larger point I want to make is that we can't expect a single blog post to be the final word that convinces anyone to use the product. A common rule of thumb in marketing is that the average consumer needs to see a product name at least seven times before they'll even consider trying it. The purpose of this post is a high-level introduction, and I think it does that well. We should continue to delve deeper into the key selling points in subsequent content, and experiment with different messaging angles to find what works best. For example, if we had one blog post that was purely about performance benchmarks, and another post with lots of code snippets showing how similar Pigment CSS is to Emotion, then we'd be able to directly A/B test the effectiveness of these two angles to determine what resonates more with users. |
oliviertassinari
force-pushed
the
pigment-css-blog-post
branch
from
6a5671d to
5d4ad7e
Compare
@samuelsycamore The main conclusion I landed on is that it seems that it's important to work with the influencers before an announcement, they are the ones who will truly give it an amplification chamber.
We retweeted it from https://twitter.com/MUI_hq, does it mean it's equivalent to a tweet from it? For me, it was about the virality of the tweet, at which rate it gets amplified (retweeted) by the people who can see it.
Agree, my initial objective was to get the benchmark in a state of coherence. I could only see two paths: either we remove the performance section or we fix it (because it didn't feel technically credible so didn't build the brand of technical excellence). I used the opportunity to do small side quests 😁.
Agree, there are a lot of ways we could do more product marketing work on this. Now, at this point, we might have already enough, today our bottleneck feels more product engineering bandwidth (it's a hard problem to solve): e.g. https://x.com/sephster/status/1820833213842936304, a good flow of new GitHub issues. |
Follow-up to #42198.
I have seen https://remix.run/blog/merging-remix-and-react-router add their React Conf talk after publishing their blog post. While in the case of MUI, I think we should have done this in the first place, before posting the blog post. But it's not too late. So I'm taking action. Can someone add this to https://github.com/mui/pigment-css/blob/master/README.md? Thanks
I also used the opportunity to change what I felt could be improved. Especially, I focused on the performance part of the blog post as I felt it wasn't something developers could take seriously. It feels like it missed the points. Hopefully, it's fixed now.
Preview: https://deploy-preview-42500--material-ui.netlify.app/blog/introducing-pigment-css/
On the announcement, it performed poorly https://x.com/MaterialUI/status/1791227802542338332 - 49.6K Views. For example vs. https://x.com/thesegunadebayo/status/1669732623994834946 - 399.8K Views. or https://x.com/naman34/status/1732140580342509622 528K Views. Another interesting thing here is that not all likes and retweets are equal, StyleX got fewer retweets but a lot more views. So working with the influencers is key.
It should almost make us wonder if the community is ready for this, if we shouldn't focus on something else. (I don't think so). Now, arguable, there is a LOT missing before the community can consider Pigment CSS as a serious option, e.g. we don't talk about bundler integration in this blog post, there is no real docs, Turbopack support doesn't work, we have no comparison with other solution, no serious (technically deep) why page.
In light of this, hiring for https://www.notion.so/mui-org/0ea5085349464aefa17a6f56a6e25c2c?v=30c98295e2da46ca90b275ac27996401&p=59c0dd1517ef4db9b10b430f61de4dcb&pm=s feels like a must, I don't see how this can work without this role.
I think that posting from Material UI Twitter account didn't help either, I find it strange it doesn't come from either a personal account or https://x.com/PigmentCSS as a fallback. The timing of the post probably didn't help either: Midnight Europe time, evening New York time.