Breaking away from framework lock-in with Web Components

mrt 20, 2020.java, .script, frontend, Technology

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.

Jan De Wilde

Jan De Wilde

Craft Lead Frontend

Jan is een doorgewinterde ontwikkelaar met +10 jaar ervaring. Zijn professionele bagage bestaat momenteel uit twee grote onderdelen: enerzijds zijn technische kennis en anderzijds zijn liefde voor het werken met mensen. Zijn technische specialiteiten zijn allemaal gerelateerd aan het domein van front-end ontwikkeling. En hij houdt van het delen van zijn kennis, het coachen, het leiding geven aan en opbouwen van een team.

Meer lezen?

Aanverwante  Berichten

Tribe Reads

Tribe Reads

Tribe Reads zijn binnen onze Tribe een succesvolle manier om kennis te verwerven. Maar naast kennis, is het ook een ideale gelegenheid om elkaar beter te leren kennen en om van gedachten te wisselen met collega's.   Wat zijn Tribe Reads? Tribe Reads zijn...

Tribe Read: Fundamentals of Software Architecture

Tribe Read: Fundamentals of Software Architecture

Continuum reading groupsAt Continuum, continuous learning and knowledge sharing are highly stimulated because we believe they are the key to our success.  One of the ways to put it into practice is by organizing reading groups.  A group of 5 to 10 colleagues with a...