It's slow and unusable, not unstable. The one benefit of WC is that it's going to be stable for the next hundred years, just like <marquee> still works in 2020. It's unusable because of all the boilerplate it requires and doesn't provide the most important thing of all which is data binding. So you have to bring in some other support code to do data binding such as the Rx/Observables or Redux patterns, but since this can't be shared with other shadow-rooted WCs, the cost of that bloat is multiplied by the number of different WCs you have on a page, which could be hundreds.
In benchmarks WC scales very poorly compared to React. It just wasn't designed for performance. I could go on.
- strings as the only native serialization format
- templates are also strings
- messages are passed to children as attributes which are strings
- no way to take advantage of efficient tree algorithms (virtual DOM), just manipulate a giant string every tick like a caveman
There are many reasons for that. `element.html =` is implemented as single update transaction, JS function call is significantly more expensive then HTML parsing of single element, etc.
This is thanks to how extremely optimized V8 and Chrome is for string manipulation. It is faster in the small cases but doesn't scale to, say, 10000 rows in a table. Then it becomes several orders of magnitude slower than React and virtual DOM. On low memory devices it could crash and never render. This should just be kept in mind when choosing WCs. WCs are perfectly fine for the Settings page in Edge, for example.
In benchmarks WC scales very poorly compared to React. It just wasn't designed for performance. I could go on.
- strings as the only native serialization format
- templates are also strings
- messages are passed to children as attributes which are strings
- no way to take advantage of efficient tree algorithms (virtual DOM), just manipulate a giant string every tick like a caveman