3 ms·
You can tell a framework by the "Hollywood Principle" (don't call me, I'll call you). A framework is the component host. It's responsible for defining the compo
by spankalee 6y ago
You can tell a framework by the "Hollywood Principle" (don't call me, I'll call you). A framework is the component host. It's responsible for defining the component model and calling the component lifecycle.
Since frameworks define their own component model, components are typically incompatible between frameworks. You can't use an Angular component in React because React defines a different model.
This leads to huge fragmentation across the ecosystem and internally within large companies, and a waste of effort to reimplement components in each framework.
Web components are a standard component model where the _browser_ is effectively the framework. It calls the component lifecycle, and to other userland JS code, or HTML markup processors, web components act like any other HTML element. It's like being able able to add your own elements to the HTML spec.
Web components only specify the interface between the components and the DOM, they don't specify how the components are implemented. So you see several libraries that help implement web components. These libraries usually do a subset of what a framework does: main templating and reacting to state changes. They don't do the component model part of a framework.
Fast is another library that helps you build web components. Polymer was probably the first, and currently there are Polymer's LitElement, Ionic's Stencil, Salesforce's Lightning, and many more. They're all compatible with each other and with frameworks because the libraries only manage the internals of the components, the externals are standard.
- deleted 6y ago[deleted]