The Anatomy of Web Components(itnext.io)
itnext.io
The Anatomy of Web Components
https://itnext.io/the-anatomy-of-web-components-d6afedb81b37
5 comments
I have long been a supporter of Web Components over non-native libraries. Recently I tried to put together a native only site with them and it was a lot of fun. It's not without it's quirks or concerns, but for a smaller, non SPA site I would pick it over React or others just to cut out the tooling chain and node ecosystem cruft. It would save me some headspace at the very least.
I worked with early Polymer versions for about a year on a pilot project and loved the technology and implementation. Conceptually, I think its superior to lots of the alternatives.
Fact of the matter is that the javascript/nodejs (e.g. React) hordes shouted down a really fine set of ideas.
its a sad loss, IMO.
Shocker: https://micro-frontends.org/
That article seems to confuse project management issues with architecture I think. Who in their sane mind would recommend using three different frontend frameworks living in one codebase? Who inevitably wraps it all together, Team Mop Bucket? What would the build pipeline look like and who maintains and fixes that?
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.
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.
Did you use anything for rendering templates?
I wrote a small helper class that I extend my components from https://bitbucket.org/polylab/polyblocks/src/master/polybloc...
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.
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.
Wow the one webcomponents blog that doesn't mention Polymer or Lit.
Not being familiar with "Web Components" (vs. web components), could an expert chime in with thoughts on why they don't appear to be catching on? That is, why are frameworks like React and Vue not leveraging this native browser capability?
Because there's essentially nothing to leverage. The one thing that they promise (interoperability between frameworks) is both not true in my experience and not compelling enough to warrant the massive amount of complexity required to work around their shortcomings. If you want nightmares go read Polymer or Oracle JET's source code, both are WC based frameworks, both had to go to extreme lengths to offer a semi-reasonable end user API.
They solve the wrong problem the wrong way. The creator of Ember recently tweeted about this: https://twitter.com/tomdale/status/1153309794226147330
They solve the wrong problem the wrong way. The creator of Ember recently tweeted about this: https://twitter.com/tomdale/status/1153309794226147330
> The one thing that they promise (interoperability between frameworks) is both not true
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.
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.
> Who is promising that?
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?
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 a very good solution if you're YouTube or Twitter and you want to let people embed your content while providing your own styling/behavior for it. It's basically a lower-overhead version of <iframe> that can set its own dimensions.
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.
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.
You could use WCs for that stuff, but WCs aren't best for those purposes.
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.
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.
I think web components fall back to regular elements if JavaScript doesn't run. So <twitter-tweet>Cats are the best!</twitter-tweet> and <button is="very-fancy-material-design-button">Click here!</button> would still show up for JS-disabled users, they just wouldn't have the extra JavaScript functionality.
In practice this would be
<twitter-tweet id="424242424242"></twitter-tweet>
They lacked native support at first, and the spec wasn't (and isn't) complete. Even though they had polyfills, Web Components were being promoted at a time where not many understood the benefits of component based development. It was too niche, and the idea of SPAs or single page applications was just catching on. They broke the ground, but it wasn't until other frameworks made it easier and popular that the idea caught on and the tool made sense to more people.
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.
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.
There's that, and the fact that web component technology is really a set of convenient primitives that don't do anything better than libraries and frameworks, besides the fact that they come built in to the browser. Then of course there was the rash of bloggers who were huffing and puffing over how inferior web components are, despite how their existence and even the ability to define custom elements alone are a pretty good idea. From what I've read over the years, I think that there's been a lot of bad press early on, and perhaps there were some very misguided individuals who think that web components "fail" because they don't live up to React. The point was never to replace React. A lot of people are still complaining about the polyfills, even though the only thing it says about web components is that they will eventually have full support and not need polyfills. Above all, all the polyfills combined aren't even half the size of a lot of app builds in the wild.
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.
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.
> Then of course there was the rash of bloggers who were huffing and puffing over how inferior web components are
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".
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".
Vue and Angular are leveraging them. Given that some older browsers do not support the full spec, it is up to you to choose how the code gets generated.
https://vuejs.org/v2/guide/#Relation-to-Custom-Elements
https://angular.io/guide/elements
React community is kind of hostile to the WebComponents idea.
https://vuejs.org/v2/guide/#Relation-to-Custom-Elements
https://angular.io/guide/elements
React community is kind of hostile to the WebComponents idea.
> Vue and Angular are leveraging them. https://vuejs.org/v2/guide/#Relation-to-Custom-Elements
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).
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).
Being interoperable is one way of leveraging another tech.
I guess it’s the subtle shades of meaning. Dictionaries disagree on what leverage is :) I’ve used the relevant definitions below:
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 :)
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 :)
As European I tend to speak her Majesty's English.
Initially, Web Components were put forth as a way to replace JS UI frameworks like React, Angular, and Vue. But it turned out that WCs don't solve the same problems as frameworks.
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.)
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.)
Long story short: They solve a problem that is attractive to solve in a way that is not super useful for how most people want to develop an application. They're client side only (in practice) and poorly compatible. The developer problem they set out to solve is mostly solved elsewhere, better, by other frameworks. What those frameworks don't solve is usually not the parts that are useful about Web Components.
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.
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.
They totally changed the API once already, renaming their initial implementation "v0".
They should have made a way for simple web-components to declared and defined without any Javascript. Simple static HTML.
Should turn solid green.