How we chose to build our Design System using StencilJS Web Components
By Dan Bellinski, 84.51° Application Developer
Design Systems take many shapes and sizes. Here at 84.51°, we firmly believe that a Design System is not a Design System without reusable, ready-to-use code. Having pre-built components made of CSS, HTML and JS that developers can use and instantly be in compliance with our Design System is crucial, both for speed of delivery and consistency in user experience. The technology we chose to become the foundation of our Design System, Meridian, was critical to the success of our system.
As our Design System team formed, we took a three-step approach to choosing our technology:
- Audit our organization’s technology needs
- Research our options
- Evaluate frameworks with proof of concepts (POCs)
Auditing our organization’s technology needs
As we began auditing our technology needs, we asked ourselves two questions:
What are our current technology needs?
Our major products are built using the latest versions of Angular. We also have some teams doing POCs with Vue.js, and a few static sites using React.
What are our future technology needs?
This was a little more difficult to answer, but Angular continues to be our technology of choice for new applications. While we don’t have any plans to switch, we didn’t want to be locked into Angular because of our Design System choices.
Researching our options
Knowing our technology needs allowed us to start evaluating our options. We landed on 2 major paths with a few different technologies we could use to fulfill them.
Option 1: Build Native Angular Components and support our major applications in Angular
Pros: Our company is invested in Angular, we hold experience in the technology, so building native Angular components would have been the quickest way to get started. It would have also given us first-class support for our Angular apps, ensuring no hiccups by introducing other technologies.
Cons: This approach would alienate teams building POCs with Vue.js or the teams building static sites with React. It would also prevent teams that wanted to use a framework other than Angular from using our Design System without a large investment in rebuilding our components to support the new framework.
Option 2: Build Web Components and support any framework built on JavaScript
Pros: All of our applications, static sites and POCs could leverage our Design System. This would mean faster building of POCs by leveraging our Design System, and more consistency of user experience across all the products we build. This also allows us to shift our technology of choice for new applications to anything built on JS and still get all of the benefits of our Design System.
Cons: The idea of web components was around for a few years but an agreed upon spec wasn’t finalized until 2019 (Custom Elements v1) — this meant it was a newer technology and that introduced risk for us. How much support would our supported browsers and our chosen JS frameworks offer and where would it break? Building with web components also meant spending time learning a new technology, giving us a slower start.
To help make our choice, we consulted internal leaders and engineers and asked the Design Systems community questions on Slack and Twitter. We built a few POCs to test web component support in different frameworks to determine what was feasible.
Evaluating Frameworks with POCs
We had already been building Angular components for years, so there was no need to prove out Option #1; we knew it would work. We looked at several options to build out web components including building web components from scratch, Angular Elements, LitElement and StencilJS. We asked questions like:
- How many other companies are using the framework?
- What is the framework’s documentation like?
- How long has the framework been around?
- How active is development on the framework and what is the company supporting it?
- How much custom development is needed to build a component?
- How easy is it to build a web component with this framework?
- How easy is it to use a web component built with this framework in Angular, React, and Vue.js apps?
We built a few POCs, evaluated the answers to questions above, and ultimately decided to build our Design System’s foundation on StencilJS.
Why StencilJS?
- StencilJS documentation is robust
- There are great code examples on the web, including many Ionic components built on StencilJS
- StencilJS is specifically built for building Design Systems
- StencilJS has been around since 2017, proving a long track record of success
- StencilJS’s testing suite worked great for our way of working — they provide support for unit, E2E and snapshot testing
- The web components we built in our POC were easily pulled into Angular, React and Vue.js apps
It has been six months since we made the choice to use StencilJS. We’ve been happy with our choice to use StencilJS as our Design System’s foundation and now have StencilJS components deployed to production in our two major products. We’ve learned a lot along the way and will be sharing in future posts!
Appendix — Other Frameworks
Why not web components from scratch?
There is a large amount of code required to make a web component interact with the browser, and we determined it wasn’t the best use of our time when other options existed requiring less time investment.
Why not LitElement?
LitElement is a popular option and seems very robust. As we compared it to StencilJS and Angular Elements, it provided less abstraction to build a component, which meant us writing more code. We probably would have been happy with LitElement but StencilJS felt easier to use.
Why not Angular Elements?
On paper, this was the most appealing option for us, which would have allowed us to build native Angular components and then convert them to web components. Unfortunately, the documentation was severely lacking and the technology was fairly new. It also required that the Angular framework be bundled with each exported component and without Ivy, this meant big JS files.
