Optimizing render performance

I’m noticing some sluggishness when there are many list entries with (complex) individual list items and if values need to rapidly update.

Might be able to improve render performance by optimizing how components like Flex enhance (clone) and render children. Perhaps something can be done with the Context mechanic (connect and ComponentProvider)

[ItsJonQ]

@diegohaz Thank you ❤️!

I wonder if using Object.assign instead of object spread has any impact on performance.

I’m not sure either 🤔 . I wanted to try it out based on your findings. I just ran some tests, with Object.assign vs {...spread}.

Assign vs Spread.

PerformanceTest story. Pressing tick 10 times. Once every second.

I honestly can’t see a difference in their performance 😂 .

For the sake of making the component layer code easier to work with, I think I’m going to use {...spread}.

---

P.S. In terms of perf, memoization has made biggest impact so far 👍

[ItsJonQ]

⚖️ Comparing Libraries

I just added 2 new performance tests using the initial one as the “control”.

These 2 new tests have the exact same setup. However… they use different UI libraries!

One is Shopify Polaris, the other is Material UI.

Below are screenshots of the results.

Running “Autopilot”. Leaving it running for a bit. Screenshot’ing the average FPS.

G2

https://g2-components.xyz/iframe.html?id=designtools-performancetest--default&viewMode=story

72% frames preserved Total HTML Node count: 344 (lowest)

Polaris

https://g2-components.xyz/iframe.html?id=designtools-performancetest--polaris&viewMode=story

68% frames preserved Total HTML Node count: 371

Material UI

https://g2-components.xyz/iframe.html?id=designtools-performancetest--material-ui&viewMode=story

71% frames preserved Total HTML Node count: 457 (Highest)

I’ve also included the HTML node count. That is… the amount of HTML DOM elements rendered by each library in order to re-create this particular UI.

In terms of performance… They’re all very close. The differences my be negligible.

There are some interesting difference. At least, in terms of how the UI “feels” to interact with.

---

Note: These results were from production builds of the test. During local development, Polaris performed the fastest. Followed by G2, then Material UI.

---

✨ UI Feels

I tested the various pieces by attempting to interact with them as quickly as possible. For example, spamming letters into the search input (by holding a letter down).

Autopilot OFF

I performed these actions with Autopilot turned OFF.

G2

• SearchInput: Fast
• Sliders: Fast
• NumberInput: Fast

Polaris

• SearchInput: Fast
• Sliders: Fast
• NumberInput: Fast

Material UI

• SearchInput: Fast’ish
• Sliders: Fast’ish
• NumberInput: Fast’ish

Autopilot ON

I performed these actions with Autopilot turned OFF. I excluded the SearchInput and NumberInput as it was impossible in interact with those with autopilot on.

G2

• Sliders: Fast

Polaris

• Sliders: Fast

Material UI

• Sliders: Slow

Overall, G2 and Polaris feel very similar. There’s a sliver of jerkiness with Material UI compared to the other libraries.

🌳 React Component Tree

Below are screenshots of the different React component trees for the search Text input component. These screenshots were taken from the React developer tools, with memo wrappers filtered out.

G2

Polaris

Material UI

G2 is the lightest in terms of React component. That is because G2 relies very heavily on hooks for it’s features. From dynamic style compiling, to prop consolidation, to connecting to various internal providers as well as the “Context” system.

Having a light-weight tree was driven by suggestions from folks like @griffbrad and @diegohaz . (Code architecture was inspired by Reakit)

💅 Differences in CSS Architectures

Aesthetics aside, there are fundamental differences between the various UI libraries.

Polaris

Polaris is probably the “lightest” compared to G2 and Material UI. Polaris relies on an external stylesheet for CSS, whereas the other libraries use a CSS-in-JS solution. As such, Polaris is missing CSS-in-JS features like the base “Box” component and JS powered/controlled styles.

Material UI

Material uses JSS for their CSS-in-JS solution. This strategy relies on provider/consumers for their styled components in order to use theme settings and variables.

G2

G2 uses a custom Emotion configuration. Theming and variables are ultimately compiled as CSS variables, bypassing the need for provider/consumers like more traditional CSS-in-JS techniques.

✨ Thoughts

I’m excited to see that the G2 components can perform admirably against these UI libraries. Matching their performance in terms of throughput as well as user interaction and feel. Not only that, it’s able to do it while preserving it’s style system features.

From a polymorphic Box (View in G2), to inline css prop rendering, to provider-less style injection, to mode support (e.g. dark), and theming.