Embracing Web Components

I have been working with the web for a long time now. And like every other developer, I use frameworks and libraries to build most of my web applications. Over the years as web standards have emerged and solidified over the years, the web platform has become much more capable. One such standard is Web Components.

The ability to natively create components using APIs that ship in all modern browsers without needing build tooling or npm installation. I have been diving head-first into Web Components lately, thanks to my friend Rob Eisenberg (notably known for this work on Durandal, Aurelia and FAST at Microsoft).

I am not nearly doing anything as exciting as Rob is with Web Components, nor am I as experienced. But his passion for driving Web Components forward ignited me to try them out. Keep an eye out for what Rob has in store around Web Components. He is working on some exciting stuff that he will be announcing soon.

Web Components offer a way to create reusable and encapsulated custom elements for any web page or application. With the ability to define your HTML tags, attributes, and functionality, Web Components provide a level of modularity and flexibility unmatched by traditional frameworks and libraries. They’re faster and more efficient for most use cases because they don’t require a runtime or build step.

Before diving in, I thought Web Components were much less capable than they are. The syntax might be more verbose than working with React or Aurelia, but that’s nothing a good abstraction cannot solve. Lit is a popular library for working with Web Components with a nicer API. But, I wanted to experience Web Components to understand the native features.

I have already started building some of my components and abstractions around them to make working with them a little nicer. I could use something like Lit, a popular choice for Web Components, but I wanted to learn the underlying APIs before opting for an abstraction library.

It’s a nice feeling to feel like I am writing code again. Not that I already wasn’t, but I am not working with native APIs all that often beyond the standard querySelector and so on.