The Anatomy of Web Components
itnext.io
itnext.io
Should turn solid green.
Monoliths still work if managed correctly. You can even organise code to get similar isolation as a microservice but still in the same codebase and tooling. If you find yourself looking into "micro services but it's frontend components" then I think you need to look at hiring a technical lead who can see a bigger picture architecture for everyone to work in.
One of the benefits of consistent tooling and frameworks is knowledge sharing and mastering your tools as a company. If everyone is using different tools then you have created fragile knowledge silos throughout your company and you don't get that hive mind mastery of the tools, where there is always someone who knows what the right approach is.
I have changed the details a bit since this but the approach is the same.
The readme of that repo explains how I approached working with them, I tried to keep the process simple.
They solve the wrong problem the wrong way. The creator of Ember recently tweeted about this: https://twitter.com/tomdale/status/1153309794226147330
Who is promising that? Web components are just a set of APIs in the browser. All they can really do is make the same promise of all the other browser APIs, which is availability.
This was very much the narrative back when WCs were first announced / released. If that's no longer a focus then what is their selling point now?
Web Components are probably also a good solution if you're a news site that serves 90% static text but occasionally wants to embed an interactive chart or something. It's basically a slightly more standardized, isolated version of the `<div id="chart"></div> <script>$("#chart").makeInteractive()</script>`-style code that sites like that normally use.
They might also work if you're trying to build a library of standard components (like "toggle switch" or "stepper control") to be used in apps written with a variety of different UI frameworks. Although this depends on good "cross-framework" support which hasn't really materialized yet.
Web Components might not be the best solution if you want to render your entire site in client-side JavaScript, SPA-style. But on the whole, there aren't many websites that want to do that—remember, 30% of the Internet is WordPress blogs!—and there are even fewer where it's actually a good idea.
1) YouTube/Twitter widget: Use an iframe, because WCs don't render at all with JS disabled.
2) Interactive chart: You don't need WCs for this case; they make nothing easier and many things harder. Just use DOM APIs directly if your requirements lightweight, or use a popular framework if you need more support.
3) Standard library: That's the interop problem they're talking about up thread. That's literally the only thing WCs are good for, and even then, the fact that they don't render at all with JS disabled means that they're never going to be better/faster than rendering UI server side.
<twitter-tweet id="424242424242"></twitter-tweet>
In other words, the timing was off and now everyone is using React instead. To gloss over some of the technical details like state management, ES6 out of the box and how JSX probably made sense to some people more than the Web Components spec.
Why React and Vue aren't leveraging it is probably because it's easier to roll their own than keep up with the living specification, and because the way they approach components is a bit different.
To expect web components to "catch on" in the same way that React and Vue have is a bit dumb, but I would like to see them adopted in a way where there's a good story around their use in frameworks, rather than a replacement.
Well, actually ©™️ ;) There was a rush of bloggers who claimed this was the glorious future available now, that you don't need any extra frameworks, and how everything is in the browser now.
But then people actually tried to use them. And found them, well, lacking.
So over the past few years the narrative shifted to "oh, web components is just a set of primitive APIs intended for library and framework developers only".
https://vuejs.org/v2/guide/#Relation-to-Custom-Elements
https://angular.io/guide/elements
React community is kind of hostile to the WebComponents idea.
It literally says that Vue doesn't leverage Web Components. It is, however, interoperable with them.
> React community is kind of hostile to the WebComponents idea.
It's not. It's just more pragmatic. I've seen way more hostility from web component community towards React (and frameworks in general).
Google (top of search results, source unknown, most likely New Oxford of American English): use (something) to maximum advantage.
Merriam-Webster: to provide or supplement with leverage (implies financial support to gain power/effectiveness) or to gain or exploit
Cambridge: to use something that you already have, such as a resource, in order to achieve something new or better.
So, I guess Vue isn’t leveraging web components in New Oxford sense (they are not using WCs, they are incidental), but it can be argued they are leveraging them in the Cambridge sense. And definitely not in the Merriam-Webster sense :)
Frameworks solve three problems:
1) Encapsulation. The DOM APIs don't make it easy to encapsulate reusable UI components. WCs help here.
2) Efficient re-rendering. The DOM APIs don't make it easy to manage client-side state variables, re-rendering just the UI parts that need changing. Unfortunately, WCs don't solve this problem; Shadow DOM slots (sub-components) render eagerly, whether you like it or not. https://twitter.com/tomdale/status/1153309794226147330
3) Quirks. DOM APIs are quirky; they were developed organically by web standards committees. They have a bunch of (well documented) gotchas that you have to work around, making them inconsistent and clunky. WCs don't smoothe over any existing quirks; it just adds more of its own. https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
(My favorite WC quirk: WCs don't render at all if the user disables JS. [])
As a result, most WC advocates today recommend using a lightweight framework on top of WCs, e.g. Lit.
In fact, most modern frameworks do allow you to use WCs transparently. (React makes you jump through some hoops, but you can* do it.) https://custom-elements-everywhere.com/
Why bother using WCs if you're using a framework? Because WCs can allow you to use the same component code in multiple different frameworks. Despite triumphalist anti-framework rhetoric when WCs launched, now the claim is more modest: WCs solve the problem of interoperability between frameworks.
But if you're using exactly one framework, you don't need interop. Using multiple frameworks is an inherently unusual problem to have; big corps have this problem, but they're not proud of it, because each framework slows down the page.
In conclusion, WCs are less popular than frameworks because frameworks solve more problems than WCs, and the interop problem that WCs do solve is very rare.
[*] If the user disables JavaScript, WCs don't render at all. Traditional frameworks would render UI on the server side using plain old HTML and CSS, running JavaScript on the client-side to attach behavior after rendering. (Modern frameworks allow you to run the same UI code on the servere side and on the client side, re-running the UI code on the client to attach behavior.)
But encapsulated WCs with Shadow DOM fundamentally change the web platform. WCs allow you to have multiple elements on the same page with the same ID (inside encapsulated containers). They prevent external styles from cascading into your component, and prevent your component's selectors from leaking out into the rest of the document, and they can do this in a hierarchy of sub-components. Cool stuff, but none of it works at all without JS, and trying to transmogrify Shadow DOM elements into non-Shadow DOM elements simply can't be done 100% of the time. (If you're careful, you can get it to work on carefully written WCs, but now you have new gotchas.)
Which is a shame - as there are some genuinely good ideas in the set of tech that makes up Web Components. They just aren't very attractive to work with.
I kind of feel they need to scrap it and come up with a compelling v2 that uses what we know now.