Building web applications with longevity through web components
When starting new projects, the first question web developers often ask is “what framework are we using?” For example, ZapLabs manages several websites, some of which have been around for decades. It’s no surprise that our business often outlived the community support of these sites’ underlying frameworks. This adherence to a single framework is no longer a necessity.
Web components work everywhere
We can use web components without additional supporting code in 93% of user's mobile browsers today. The supported browser share is increasing as new features land in Firefox; when we include polyfills, they can work everywhere.
This browser support matrix for the Custom Elements specification from caniuse shows full support from the most used browsers.
...and will continue to work everywhere
We’ve seen that once browser vendors have shipped a popular feature, they bend over backwards to preserve that functionality in future versions. Web components adhere to W3C standards, which were developed to promote consistency in the design code behind a web page. There are a large number of elements available for reuse, and the custom element part of the specification is quickly becoming a lingua franca of higher-level libraries. You can build and output a web component from Angular, Vue, Stencil, and Polymer.
Focus on business value, not technology
At ZapLabs, we aim to provide a fast, functional and engaging experience for our visitors. We’ve been delivering real estate information online since the turn of the century. Since then, the web platform has changed radically. Previously, we’ve been forced to invest engineering effort to preserve existing functionality, even as frameworks we committed to were abandoned by the community and became a liability.
As the web platform continues to evolve rapidly, we gain productivity by embracing new features with wide adoption like ES6 modules, flexbox, and CSS grid. We can improve the codebase while we ship new features, without the need to rewrite everything to conform to a new structure. By embracing web components we can chip away at legacy functionality, creating modern, reusable widgets that should stand the test of time, while eliminating the need for supporting code to be updated to run on the same framework.
Freedom within limitations
When we write our code and deliver it as a custom element, the HTML layer of our application becomes more powerful. We define new tags that encompass features. We can now include whole widgets with single tags like <zap-header>, <zap-recently-sold-homes>, <zap-agent-reviews> and compose these out of lower-level custom elements we define. Because the code for each of our web components is encapsulated inside its own package, it is less likely to cause problems in other parts of our application. Even more importantly, since the HTML, JS, and CSS is inside the component, it’s easier to refactor or totally delete any single component in the future.
Web components have a small set of interface points. They give you instantiation and attribute change callbacks; you can pass in string attributes or hang complex objects on the custom element object. This small API allows for creativity and the ability to take this in different directions. We can build simple components with no dependencies or we can take advantage of libraries like StencilJS which offer advanced developer features, but still compile down to very small web component deliverables we include in our application the same way as our vanilla web components. Large frameworks are a lot of fun. Deciding not to adopt React or Vue doesn’t mean we don’t need to roll our own higher-level functionality; there is a wealth of smaller modules providing all the benefits we need without converting wholesale to an Angular/React/Vue lifestyle.
How we use web components:
Our yeoman generator gives us a quick scaffold for new components when we type yo @zaplabs/web-component on the command line.
We use the template literals for our HTML templating needs
We avoid using shadow DOM at the moment because we heavily theme all our components for use in branded sites.
We isolate our component’s CSS by using the custom-element name as the top level selector in our component's SASS file.
We publish our component as private npm packages.
The desired versions of our component packages are imported in the client side bundles in the sites using them.
When necessary we render web components server side using jsdom with a custom elements plugin
Ship light sites
All of the developers whose faces you see above are shipping web components and helping refine the process of making fast, easy-to-maintain web properties for future team members.
It’s a privilege to be part of this amazing team!
As Lead Front End Engineer at ZapLabs, Aaron modernizes legacy codebases by figuring out the fastest way to ship the most user features with the smallest page weight. In his free time, he’s either skateboarding with his kids or swimming back to shore after another disastrous attempt at kiteboarding.