Karl Herrick

A technologist and web developer | Posts about technology encountered along the journey.

Web Components

Screenshot of x-weather Web Components

When I first started learning HTML I remember the delight I had after applying only a little markup and seeing the results after reloading. Even as new techniques were developed to manipulate the page, elements being created and then falling out of usage, and other ways of representing tags emerging, the platform’s ability to organize a large amount of content in a friendly way remains a key feature. With Web Components now, designers and developers are given a unified way to create and consume new HTML.

Their viability on the evergreen Web increased when a unified way to share presented itself after industry favored ES6 modules over HTML imports (similar functionality is being rethought) and an NPM packaged frontend showed itself more appealing. Polymer moved in this direction also. Templates are now fairly ubiquitous, and the main API used to build modern Web Components has shipped to production.

So what is a modern Web Component?

They consist “of three main technologies, which can be used together to create versatile custom elements with encapsulated functionality that can be reused wherever you like without fear of code collisions.” – MDN web docs.

These three are listed as, Custom Elements, Shadow DOM, and HTML templates. When used by the consumer of the Web Component, the tag essentially has to be lowercase, contain a hyphen, can contain custom attributes, and cannot be self closing. For example:

  location="San Fransisco, California"
  <x-current scale="F"></x-current>
  <x-forecast days="2" scale="F"></x-forecast>

For my own experimentation I wanted a reproducible way to view on non-native browsers, so I put together a small project that can include the required polyfills and transpile back to ES5 for a starter site (or singular component). It isn’t intended for use in a production setting but I did end up building a small set of weather components with it. Other than that, I’ve been reading on best practices and learning more about Shadow DOM.

While I’m hopeful for better server side rendering support and will continue to watch how the future looks in regard to React, the thought of composing a site with a text editor, a few tags, and the F5 key sounds a bit refreshing. 🙂

Testing a PWA with Lighthouse

Screenshot of audit tab in Chrome of Lighthouse performance testing

Adding the Audits panel and powering it by Lighthouse was a good move by the Chrome team. It is easier than ever to get a basic check on how well web apps are performing according to pre-defined settings for network and cpu throttling. It also has general mobile emulation. Although there is certainly room for improvement on this site (hosting it closer to where it gets the most traffic from and work on optimizing images would be logical next steps for more performance gains) the initial results seem promising.

You can also run it from the command line, so I thought it might be interesting to get it setup on top of the minimal continuous integration pipeline I have implemented on Docker and Travis CI.

On Google Developer’s Progressive Web Apps Training site, it is explained that Lighthouse tests if your app:

  • Can load in offline or flaky network conditions
  • Is relatively fast
  • Is served from a secure origin
  • Uses certain accessibility best practices

For more information, a good resource to start learning is the Introduction to Progressive Web App Architectures on Google Developer’s Web Fundamentals page.

Going offline with HTML

The time I’ve put into developing postpress seems like it has been well spent. I have enjoyed working with the code and appreciate the experiences gained in going through the various exercises.

For example, after applying a web app manifest to the project and implementing a service worker, web development seems fun again. Not that I wasn’t ever into it, there’s just something exciting about seeing your hard work yield new and interesting results.

The project now has a fast initial render from a blank cache (using server side rendering), and the articles and portfolio components have offline capabilities, as well as near instant loading on a repeat visit to a page. The “Add To Homescreen” functionality varies between browser and OS, but I can see how vendors might utilize this feature in the future to promote PWAs that conform to a high enough standard.



Most importantly in my mind is that it is all working right now. It behaves as a web app when it should, and just like a traditional website when it counts. Combined with what seems like an eventual adoption of WebAssembly and Web Components as a standard part of the Open Web Platform, it’s a really awesome time to be developing against it, as it feels more alive than ever. 🙂