Yesterday Apple announced the release of the new beta Apple Music Web Client, giving Apple Music customers the ability to listen to their favorite music from the web instead of only through an installed native app.

I was following the conversation on Hacker News, and many were excited to see Apple embracing the web and bringing parity to other music apps like Spotify that have had rich web experiences since the early days. That Apple still cares deeply about the web was encouraging and exciting for many to see.

Predictably, HN readers were curious about the tech stack behind such a huge release from such a huge and influential company. Curious readers quickly figured out a huge portion of the app was built on Ember, and most of the technology conversation focused on this:

However, a few careful readers noticed something interesting: Apple also shipped over 45 Web Components to power many corners of the Apple Music web experience (which they built using StencilJS, a detail no one else noticed but can be seen by inspecting the component bundles being loaded). These components are focused around the new Video player for music videos, podcast playback control, notifications, and more. My read on the situation is that Apple will deploy a lot more features with Web Components over time, and the ones we see today are for the burgeoning features they are being tested on.

I found the fact that the Web Component usage went over nearly everyone's heads on HN hilarious, given that the conversation around Web Components on HN so often devolves into passionate exasperation that Web Components aren't solving unique problems teams actually have, and that real-world usage at scale has been scant. At this point you can expect to see a comment that Web Components are just a poor replacement for popular 3rd party component models like React and that web standards folks should just give up, in nearly every HN post on the topic.

Given that Apple has huge sway over whether modern web standards like Custom Elements and Shadow DOM get implemented (and correctly!), the fact that they have embraced these new APIs and deployed major implementations with them to a massive consumer app, should be the biggest news of the day.

Let that sink in: Apple just deployed into production nearly 50 web components powering a major app they have a significant amount of revenue and strategic value riding on. You can't say that "no one uses Web Components" or they are "solving problems that don't exist or have been solved better in user land" with a straight face anymore.

And the fact that they are mixing in Web Components with a framework like Ember is huge validation for Web Components. They co-exist with popular frameworks and often solve different technology and team culture problems (such as a diversity of frontend stacks in active use across teams), but can bring some really unique benefits especially around performance. It's not an either-or and they can be easily incrementally adopted!

Oh, and if you're curious how the Apple team built these Web Components, turns out they used our open source project Stencil JS. Stencil was built to power the popular cross-platform UI framework Ionic Framework, and provides a View layer similar to React and Angular, but focused on generating Web Components with features like automatic polyfill delivery, highly optimized lazy loading, native binding generation for popular frameworks, and a toolchain built around TypeScript. If you're curious, we go into detail about Stencil and how it's leading the frontend view/framework market in terms of performance for modern web apps on our v1 announcement blog.

We're absolutely thrilled Apple is shipping Web Components to production and even more that they are using our project Stencil to do it. We can't wait to see what else they build in the future!