Last month, 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.
Those of us in the web world were thrilled to see Apple embracing the web in a way that we’ve rarely seen from them in the past. And predictably, it took the web community all of a few minutes to dig in and find out exactly which web framework was used to build the app.
The answer was Ember.
Web Frameworks and Ember
For Ember fans, this was a big win. If you’re not fluent in the world of web frameworks, let me explain the significance of this.
Open source frontend technology is sort of a mix between religion and sports. I have never heard a backend engineer identify as an “AWS developer” or an “Azure engineer.” You’re a backend engineer, who happens to be familiar with AWS, Firebase, Azure, or whatever.
But for frontend devs, oh boy. They bleed the colors of their framework. It’s who they are. “I’m a React dev.” “I’m an Angular dev.” “I am more of an Ember person.”
Asking a React developer, “Hey, why not give Angular a try?”, is like asking a Manchester United fan, “Hey, why not cheer for Liverpool this weekend?” Not on your life.
So back to Ember. The news that Apple released their new music app on Ember was a really big deal for that community.
Behind the scenes: Web components
But there was something else exciting in Apple’s announcement. Something few people noticed. Along with the Music app, Apple quietly shipped over 40 custom Web Components.
For those of us paying attention, this was a landmark moment. Web Components have been around for years now, ushered through the web standards community as a way to create and share UI components - the basic building blocks of a user interface (think buttons, toggles, sliders) - and run them entirely in the browser, without the need for frontend framework and without a hefty runtime required to make it work.
The benefits of Web Components seemed obvious to many of us. Because they work entirely in the browser, there’s no additional runtime required (which means they’re about 100x smaller than a typical UI component package). And because they depend only on the browser, you can use them with any web framework.
As a longtime champion of the web platform and cross-framework compatibility, I was thrilled to see Web Components gaining traction as browser support became more widespread and the standards community started rallying around the concept.
But many in the industry… were not. In fact, it didn’t take long for detractors to point out the shortcomings of Web Components. They’re dependent on JavaScript. They make browsers even more complex and increase the surface-area for defects. Older browsers don’t support the WC standards and require polyfills. And at the end of the day, aren’t the UI components we can ship with frontend frameworks good enough? Is this really a problem that needs solving?
And then came the biggest retort of all: “No one’s using Web Components!”
Alas, for awhile they were right. There was little evidence that Web Components were being widely adopted, and those of us who saw and believed in their potential were becoming disheartened.
But then something changed. There was a noticeable groundswell of Web Component adoption among some of the biggest brands in the world. Companies like Porsche, Panera, Mastercard, Cisco, Volkswagan, and many, many more.
Why are so many of the Fortune 500 adopting Web Components?
For Fortune 500 and other multinational enterprises, Web Components hold the key to a promised land that they’ve been chasing for years: a single UI library (more recently called a “design system” in the UX world) that works across all of their development projects, all of their teams, throughout the organization.
You see, because frontend developers identify personally with the frameworks they use, you can’t just impose a single framework - like React or Vue - across an entire enterprise. They’ll be sharpening their pitchforks and chasing you out of town.
That’s where Web Components come in. Because they can work with any framework, a central UX or design team can standardize on a single set of fully-custom, fully-functional UI components, and share them throughout their entire org, without having to persuade any teams to give up their religion.
Here’s how Marcel Bertram, Design Systems Lead at Porsche put it:
“At Porsche, we have a heterogenous ecosystem of products built with Angular, React or without any framework. As a design system team with a small number of developers, to give us the flexibility we needed and keep pace with our development roadmap, we wanted to standardize on one set of UI components that would work across any product. Building a custom design system based on Web Components has enabled us to do that.”
Another reason big companies like Web Components is that they’ll work just fine with your existing legacy code. Have a legacy app with 1 million lines of jQuery code? Moving to a new framework like React or Angular would require a total rewrite.
But with Web Components, you can build custom Web Components using Preact, Svelte, Stencil, or Lit Element, and generate new, modern interface for your legacy app, without doing a rewrite.
Why Apple’s Use of Web Components is Important
We knew they were being used heavily, but more often than not Web Components were being used for internal projects - supporting these company-wide design systems initiatives. There still weren’t many major public apps in production that we could lay claim to.
Which brings us back to Apple. Apple, of all of the tech giants (not exactly the most web-friendly of the bunch) embraced Web Components in one of their most visible announcements of the year. Finally, you couldn’t really say “No one is using Web Components”. Because hey, this little company in Cupertino seems to think they’re alright.
Why Web Components
So what does all this mean if you’re a UX designer or a frontend engineer considering Web Components?
Here’s my advice.
For companies that have standardized on a single framework -- or even for one-off projects in larger organizations -- Web Components can be a nice, easy way to add in a custom component here and there to augment your UI and improve app performance, which is what we see Apple doing. Even if you only have one site or web app to manage, having a single component that you can reuse and repurpose throughout the site is a win.
The benefits of Web Components multiply quickly when you have a wide range of teams working on dozens of applications (or more). This is why they have become so popular in the enterprise. If you’re part of a large business and are trying to bring some consistency across teams and development preferences, Web Components are a great low-risk, high-reward option.
Most of all, Web Components might finally liberate us from the perpetual framework wars.
If you’re a gamer, think about it like the console wars. You want your console to win the market, because if your console becomes dominant, you’ll get all the best games. Every game studio will want to build apps for the console that you spend hundreds or thousands of dollars on.
The framework world is quite similar. You’ve invested countless hours learning React or Angular, and you want your framework to “win”, so that you’ll be able to work on all the best projects. Well, the great news about Web Components is that they work with every framework. Sticking with our analogy, that’s like having a console that will play every game on the market. And if that’s true, who cares which framework wins?
If you’re ready to give Web Components a try or want to learn more, Mozilla’s documentation on Web Components and the Custom Elements API are a great place to start.
Coming to a Website Near You
Taking all this into account, my prediction is that Web Components will become the de-facto way to enable cross-platform design systems in large businesses. Nothing comes closer to solving the multi-framework problem.
Whatever the future holds, though, the last few months have indeed marked the unlikely ascendance of Web Components - eight years after they were introduced - and we’ll be watching with excitement to see where they go from here.