Web components have been around for a while and they've been making the rounds in developer circles, showing off their unique properties and potential. Their application in production has had a slow start as we're all still trying to gain familiarity with this new interface and assess how it fits with our current web development process.
Despite the naysayers, the history of the Internet is tightly attached to markup. As the Web has been maturing we've seen the separation of concerns dominating our methodology with CSS becoming the exclusive moderator of styling, layout structure defined solely by markup, JSON structures moving data and JavaScript used for logic. Custom markup is not a new concept, it's what XML supported since its introduction; although its use in that case is fundamentally different, to describe data rather than layout.
Custom markup tags are as straightforward as markup itself. Every tag is meant to represent a UI element, defining its basic properties and order in the layout. The need for custom markup becomes obvious whenever we have custom UI elements, which is almost for every app. The frequency of the use cases and the simplicity of usage is what makes web components a good idea. Lets scratch the surface...
Markup for describing structure works, mainly because it's easy to comprehend and to edit. Following existing conventions is the best way to keep the bar of entry low, without introducing new practices and processes. Some developers, infused with the "framework mindset", are surprised that web components don't require any dependencies to create. This is a push in the right direction, as Vanilla JS is unanimously the preferred "framework"...
On the other end, the interface to use web components has the right amount of freedom while following set standards and common conventions. There's minimal effort to initiate and customize a custom element on a web page, with an option to even extend it with additional features not made available by the original author.
Cheesy as it may be to state, web applications are "real" applications. Thus, the more moving parts they have the bigger the need for abstraction, which will aid during the development and make maintenance more bearable. This compartmentalization of application logic has other, less obvious benefits; for example it makes the end product more durable during runtime, as elements that are encapsulated in components can be disabled if needed without affecting the rest of the app.
Most frameworks create one codebase for the whole application and have a top-down, all embracing approach. Although that structure may be suitable for smaller apps where the codebase can still be manageable, components offer a greater degree of flexibility and extensibility that can produce bigger scale, high performing applications.
The performance benefits jump to the nth degree when we introduce a "kindred spirit" technology you may know as Web workers. Web workers are vastly supported among browser vendors and although they've been around for years they are rarely used. It's cumbersome to include them in an existing monolithic app and they "spoil" the neat structure. Web workers are an underutilzed "best practice" because they don't fit in with our existing application stacks.
As web components enforce abstraction, there's an open invitation to move logic processes to separate threats. The JIT execution of JavaScript may become indistinguishable to native performance if we let our web apps run multi-threaded...
Forget about conventions and structures enforced by biased decision-makers. Web Components is an agreed open standard, supported by the W3C and part of the HTML5 specification.
Frameworks add sugar that may or may not be helpful but definitely introduce an additional learning curve and dependency overhead during runtime. Companies are known to "invent" products, even when there's already a better alternative available. Plus, existing frameworks with a considerable user base are left with no choice other than to support their users and defend their practices.
Technologies that stand the test of time apply the most obvious, straightforward approach to any given problem; that's exactly what web components bring to the table. As development cycles of this era end, vested interest on existing frameworks will deplete. That's when developers will be most likely open to revisit how they build their UI elements, with a renewed interest towards custom markup. Frankly, it's already been too long. Lets not stand in the way of the evolution of the Web anymore...