How does it interact with Polaris React?

[bakura10]

Hello,

First of all, congrats for the release, this is such a major achievement. I have a few questions though:

• Where is Polaris React going? Is it going to be deprecated, or will it become a simple wrapper around web components?
• While admittedly good, Polaris web components lacks too much things for now. Things like popover, autocomplete fields, option list… which makes it impossible to use for any thing non-trivial. Is the recommendation going forward to use both? From a performance perspective, Polaris React still ships ton of CSS, so using both will probably impact performance negatively. Is there a roadmap on the future web components? Do we have a way to contribute to it?
• Is there a repo to report bug?

Thanks

[alex-page]

Where is Polaris React going? Is it going to be deprecated, or will it become a simple wrapper around web components?

We will have more news on Polaris React in the future. As for right now it’s the stable version of the Admin Design System built with React.

Is the recommendation going forward to use both?

No. Using both adds additional bundle size and performance issues to applications that need to load fast for merchants. Polaris Web Components is a Release Candidate. We agree that there are missing components that are critical for App Developers so please continue to share gaps like this so we can prioritise our current work.

Is there a repo to report bug?

We might have one in the future but for now please report issues in the community forum.

[Clement_BR]

@alex-page can you provide more info though so we can plan?
Should we migrate to using the web components? Will you provide react wrappers ?
If we had know about the web components coming up, we would have planned differently. We would much prefer if you shared your plans more openly rather than dropping bombshells when we’ve already invested so much in the react polaris components (as we migrated from angular to react for that reason).

[alex-page]

@alex-page can you provide more info though so we can plan?
Should we migrate to using the web components? Will you provide react wrappers ?

@Clement_BR I hear you. I would love to be able to share details about what is next for Polaris React but we are not ready. I’ll be sure to share this feedback with the team and see if we can be more transparent with our plans moving forward.

Currently we are focused on getting the web components into developers hands, listening to feedback, challenges and addressing gaps.

[_dan]

Hi Alex,

1. Could you provide more information about the plans for the Polaris React package? We’ve been waiting for updates for over 8 months. There’s an issue in the GitHub repository from October, but no one from Shopify has responded to it - link. After reviewing a few internal Shopify packages, it appears that Shopify is using the @shopify/polaris-internal package, which seems to be on the 16th or 17th major version, while the open-sourced version remains locked at version 13.
2. Web components are cool, but I don’t see clear advantages over first-class React components. Simple components like s-icon are likely to work well, but what about more complex ones like Autocomplete, Popover, or IndexTable with bulk actions? For now, I see only a very limited number of components, which are fairly easy to implement since there’s no complex state logic behind them—just banners, text, text fields, buttons, and icons. I’ll be ready to jump in with web components once I see the Orders table in Shopify built with them, not with React.
3. Internally, Shopify is using React components extensively. I’ve checked several places and noticed that Shopify hasn’t migrated from LegacyCard or LegacyStack components, which have been marked as deprecated for about 2 years. However, Shopify is encouraging app developers to migrate to web components. I’m open to starting the migration to web components once I see that Shopify is using them internally. It seems Shopify is still relying on React components, including the new AlphaTable component.
4. @shopify/polaris is currently locked to React version 18, while React 19 has been available since December 2024. Could we consider upgrading? Also, there are bugs in the components, and it seems like no one is maintaining them.
5. If Shopify decides not to abandon the @shopify/polaris package, could we please continue to have it available via npm? Please don’t force all users to migrate to the CDN version—it likely comes with many drawbacks and gives off strong jQuery-CDN-in-the-2010s vibes. Also, tree shaking doesn’t work at all with the CDN-based version.

[Anthony_Frehner]

@_dan

Web components are cool, but I don’t see clear advantages over first-class React components.

We’ve put in a lot of work to ensure that React devs can just use these components just like the React-specific components. Let us know if you run into problems, though!

Making web components, however, opens the door to ALL the other devs that don’t use React. It’s great!

@_dan

For now, I see only a very limited number of components, which are fairly easy to implement since there’s no complex state logic behind them—just banners, text, text fields, buttons, and icons. I’ll be ready to jump in with web components once I see the Orders table in Shopify built with them, not with React.

Don’t worry, more complex components are on their way.

@_dan

it likely comes with many drawbacks and gives off strong jQuery-CDN-in-the-2010s vibes.

Can you give specific examples of drawbacks you’re running into? Thanks!

@_dan

Also, tree shaking doesn’t work at all with the CDN-based version.

True, but there are a ton of benefits of the CDN version as well; the components are always up-to-date and will always match Shopify’s own styling. As an app dev, you will hopefully never have to update a package and do migrations for new styles, features, etc. Yay!

Also, since we don’t enforce React usage anymore, we can literally cut out React + React-DOM which is a large chunk of KBs just at a base level. This should help a ton!

[_dan]

Anthony,

It seems that web components are the way forward, with no apparent drawbacks—placebo effect aside.

However, I’ll only consider migrating to them once Shopify’s Orders page is built using web components. As of now, I only see Shopify using web components for <s-icon>. Around 99.99% of the frontend at Shopify is still built with React, and you’re using new React components that aren’t present in @shopify/polaris version 13.

There was even a recent UI redesign—for example, the Page component got a fresh look with updated breadcrumbs, which looks great. But why was it still redesigned using React? Why not create a new internal web component instead?

The downsides of CDN-based versions are obvious to any engineer:

1. No tree-shaking. If you provide 500 components but my app only uses 50, why should I load the remaining 450? Or do web vitals no longer matter?
2. Prop names and backward compatibility. I’ve been working with Polaris since 2019, and it’s evolved a lot. For instance, the “Green Polaris” had a Stack component, now replaced by BlockStack and InlineStack. Would a CDN serve deprecated components like Stack indefinitely? Migrating from Green to Black Polaris was challenging—though automated migration scripts did help. As I mentioned earlier, even Shopify itself struggled to migrate from LegacyCard and LegacyStack for over two years.

The problem is that you’re still maintaining the React version of Polaris internally, while requiring all partners to use web components. In my opinion, Shopify should go first—we’ll follow. Once Shopify migrates to web components, we’ll be ready to migrate too.

Drop React and publish an article on the Shopify Engineering blog titled “How We Migrated from React to Web Components in 2 Months”. Use that migration to catch all the real-world issues and drawbacks, and showcase them in the article.

Based on your reply, it seems React components might be deprecated, which is disappointing.

P.S. I get the same feeling with Remix. It’s been two years + since the acquisition, but Shopify still hasn’t migrated to it. If Remix is the best framework for React and is built on web standards — and since Shopify follows these web standards — why doesn’t Shopify use SSR and instead renders the admin UI using client-side rendering?

[Anthony_Frehner]

@_dan

• No tree-shaking. If you provide 500 components but my app only uses 50, why should I load the remaining 450? Or do web vitals no longer matter?

Agreed! We’re very conscious of the fact that every component adds to the bundle size. We have processes in place that ensure that we’re not adding hundreds of components. But if we somehow do end up doing this, please call us out on it! It’s a very valid concern.

@_dan

• Prop names and backward compatibility. I’ve been working with Polaris since 2019, and it’s evolved a lot. For instance, the “Green Polaris” had a Stack component, now replaced by BlockStack and InlineStack. Would a CDN serve deprecated components like Stack indefinitely? Migrating from Green to Black Polaris was challenging—though automated migration scripts did help. As I mentioned earlier, even Shopify itself struggled to migrate from LegacyCard and LegacyStack for over two years.

Part of the work we’ve done in establishing these web components includes a new team whose purpose is to ensure that the APIs we’re building out right now withstand the test of time. Every attribute, component, value, and name you see has gone through a vetting process through this team to make sure that all Shopify app surfaces (checkout, admin, customer accounts, etc.) thinks that it makes sense, is valid, and won’t be changed in 7 months.

One of the biggest outcomes from this is that you’ll see a lot fewer changes to properties/attributes, component names, etc. Fewer breaking changes. Fewer older components.

I understand your skepticism; it’s up to us to prove that to you. I hope that we can over time.

[_dan]

I don’t understand why most of my points are being ignored—especially the fact that Shopify still uses (and invests in on a daily basis) React internally and will likely continue to do so for years. It seems that any detailed information about React usage within Shopify is under NDA.

The “unified components” slogan appears to be more of a marketing phrase than a practical benefit for partners. For example, there are approximately 10,000 apps in the Shopify App Store, but according to SASI, only 264 fall under the Checkout category. That’s just 2.64% of all apps. This means that 97.36% of apps will not benefit from unified components. Despite this, you’re deprecating the @shopify/polaris package, which is potentially useful for every app in the store.

Skepticism will subside only when you demonstrate, through real examples, how these components can be used effectively. Shopify itself has several public apps—I suggest starting with migrating Shopify Email or at least the Online Store Sales Channel to web components. Based on the complexity, your team might not finish such a migration until 2030. Don’t forget to migrate the @dnd-kit package

The CDN-based approach for the component library is a poor technical decision. Anyone using the CDN tag will experience degraded performance in core web vitals, yet you seem to overlook this problem.

You assume that all edge cases—names, props, etc.—can be accounted for and that backward compatibility won’t be an issue. Alex maintained Polaris for years and likely knows it inside out, yet poor decisions were still made. For instance, I’ve attached a screenshot showing that a new prop was introduced in v11.23.0 and deprecated just a few days later in v11.25.0. While this isn’t a major issue with version-controlled packages, in a CDN-based setup, such changes are a ticking time bomb. The bundle size of the CDN version will continue to grow because it needs to maintain backward compatibility for months.

When I use the CDN, I lose control over the component library. Imagine I’m working on a new feature: I open a PR, the E2E tests pass successfully, and I deploy a new release of the app. During that deployment, you release a new version of the component library that introduces a bug—like a button not rendering at all. I can no longer guarantee to users that the release is stable and tested. What am I supposed to do in that case? I can’t simply downgrade the package version. I have to wait for a fix from your side, and in the meantime, users will, of course, blame the partners.

Even if you believe technology A is better than technology B, it’s still better to provide options for developers to choose between A and B, rather than aggressively forcing them to use technology B with no alternatives.