Breaking away from framework lock-in with Web Components

— 4 minute read

The problem

Imagine a company where you have different domains with different teams, that are working on different applications using different frameworks (eg. Angular, React, Vue).

Each domain has a domain manager with their own experiences, personality and opinions. Together with a domain architect, decisions will be made that will impact every single member within the domain. Those decisions define the use of a certain technology, which methodologies and workflows to follow, whether or not the team will work agile, and so on. When working in their own domain bubble, the chances are fairly high the team will act like a well oiled machine. Work will be delivered on time, there will be no discussion about the chosen approach and everyone including upper management will be happy.

This is what we call a siloed approach and is something you’ll want to consider breaking out of. A siloed approach doesn’t stimulate the sharing of information with employees of different domains in the same company.

Imagine that upper management has requested the domains to have a bi-weekly get-together to discuss what they are working on and how they are approaching their projects. After a few get-togethers, it becomes clear that there is a huge amount of discrepancies between the different domains that have impact on: budget, productivity and portability of team members.

One thing that stands out is the list of frameworks that is used: Angular, Vue, React, Svelte and even server-side rendered applications with Java and .NET. Every team is writing everything from scratch based on the wireframes they receive or if by any luck designs are delivered.

The solution

Say hi to Web Components. Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps.

Web Components have been around for quite some time but today there is no reason not to use them, since every mayor browser supports it.

There are four main specifications:

Sharing Web Components between domains and projects:

  • Facilitates reusability
  • Makes maintenance easier
  • Makes it approachable
  • Makes it cross-disciplinary

You can write your own Web Components from scratch, but this can be quite hard to do. So why not use a third party library? There are plenty of them such such as Stencil, Polymer, LitElement, and so on.

Personally I’m a big fan of Stencil. Stencil is a compiler that generates Web Components (more specifically, Custom Elements). Stencil combines the best concepts of the most popular frameworks into a simple build-time tool.

Things that make the developer experience great with Stencil:

  • Built-in dev-server for hot module reloading
  • Screenshot visual UI diffs
  • Auto-generate component documentation

When deciding on which third party library to use, it’s important to make a decision that fits your needs. Does the library cover the features you want? Will the Web Components generated just work like a regular HTML element? What is the size of the library and elements created?

Now you might be thinking: “So you are ditching frameworks in favor of using Web Component libraries? Doesn’t that create a lock-in?” Yes and no. You are indeed dependent on a specific library for creating your Web Components, but once generated they can be used in whichever framework you would like. So sharing between projects is perfectly possible.

Conclusion

I really think Web Components are the way to go. Using Web Components doesn’t imply a complete company culture overhaul since you can start small. Over time components can be distributed over different domains, teams and projects which allows them to be more productive. In return the time and budget saved can be used to create better user experiences and even better services.

Resources