Web Components
Tags: webdev, javascript, typescript
Published: 2020-01-24 15:49:17

---
title: Web Components
published: true
description: A review of where we are at with Web Components.
tags: Web Dev, JavaScript, TypeScript
---
The [Web Components](https://www.webcomponents.org/) standard has been blogged and written about many times.  Many suggest the standard is not ready deferring to other popular frameworks.  This may be true for some people/teams - particularly those heavily invested in one framework or another. For new teams and projects I strongly recommend taking another look at native Web Components.  I am going to present a case that the standard is ready.  Remember that Native Web Components are:
1.  Universally compatible with every modern browser. Check the [Browser Support](https://www.webcomponents.org/) here.
2.  The top Frameworks identify them as [complimentary](https://reactjs.org/docs/web-components.html) *(React)* , [partially supported](https://angular.io/guide/elements) *(Angular)*, and support as a [build/render](https://cli.vuejs.org/guide/build-targets.html) *(Vue)* target.
3.  Finally, they are the fastest - nothing can get much faster than using the raw browser APIs.
4.  As I'm going to *hopefully* show you - easy and simple to use.

*What are Web Components*
First, let me clarify what the Web Components standard really amounts to.  It's a [set of APIs to support developing Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components) for Web Applications that run in the browser.  It is not a framework with all the answers - this is just raw APIs.  Don't let this turn you off.  I'm going to demonstrate how you can accomplish the ease of a framework very easily.  

**Why stick to a Framework**
The plus to picking a framework is that hiring is eased as you can find people good at using your chosen framework.  A 3rd party framework also allows your Dev team a resource to look up recipes for how to accomplish a code challenge.

**Why use native Web Components**
Not using a framework opens you up to more understanding, and frees your team to solve problems.  It requires your Architects and Senior Devs to discuss approaches and patterns and practices.  Your dev leadership will have to own the approach and teach the other team members instead of relying on another web site or courses to teach an approach dictated by a framework.

*Ok, convince me further...*
My [didactic project](https://github.com/rposener/didactic) is a learning template for developers.  It solved many of the same benefits that frameworks are offer you.  This goal is to teach you to solve these problems yourself.  In the didactic project I intend to show how we can create [declarative](https://github.com/rposener/didactic/blob/master/instruct/OBSERVABILITY.md) Web Components which are as [isolated](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM) or not as you'd like.  Web Components that are light weight, fast and intelligently update the DOM. Web Components that use clean and concise code patterns that are SOLID and DRY.  Web Components that participate with the HTML and work as an application with visible and observable [application data](https://github.com/rposener/didactic/blob/master/instruct/DATA.md) without the need for custom Dev tools.  Web Components that are easily [bundled and packed](https://github.com/rposener/didactic/blob/master/instruct/MAKEANAPP.md) and work with every other framework (jQuery, Bootstrap, Angular, React Vue, Etc).  

**Now show me the code**
What you will find is about 300 lines of well-documented code spread across 4 files.  That's it and I've created a pattern and solved for many of the same benefits of the big frameworks.  I think a new team could learn and understand a bit of code like this in such a manner that they will be as productive using these native APIs. Learning like this also opens the team to extending and growing parts of the code based otherwise typically off limits.  This in my opinion can be very freeing and empowering.

Starting with no external dependencies and learning modern browser APIs your team is in a very different place than you find with a team that knows a framework and must look up the APIs.  Taking an approach like this will connect the development team with native browser and supports using the tools of your choice.

Didact simply means to teach or instruct.  Take 15 minutes to read the couple pages and view the sample components.  Currently I have 3 example components, and I'm working on adding more samples.  If you have ideas or a challenge in mind for something you'd like to see how it can be accomplished with native Web Component API's - open an issue, clone or fork the code, or send pull request and let's give it a try.

Here's the link again in case you missed it: [github.com/rposener/didactic](https://github.com/rposener/didactic/blob/master/README.md)

Thanks for reading my article.  I look forward to your feedback on my GitHub project site.  Maybe you can create an even better approach or something amazing.  If you do, share it!  I encourage you to review, learn and share these APIs.