
The Anatomy of Web Components - onig1990
https://itnext.io/the-anatomy-of-web-components-d6afedb81b37
======
taf2
The cool thing about edge switching to chromium engine is the compatibility
table here:
[https://www.webcomponents.org/?source=post_page-------------...](https://www.webcomponents.org/?source=post_page---------------------------)

Should turn solid green.

------
ehnto
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.

~~~
krasicki
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.

~~~
krasicki
Shocker: [https://micro-frontends.org/](https://micro-frontends.org/)

~~~
ehnto
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.

------
rajasimon
Wow the one webcomponents blog that doesn't mention Polymer or Lit.

------
CharlesW
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?

~~~
phpnode
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](https://twitter.com/tomdale/status/1153309794226147330)

~~~
ravenstine
> 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_.

~~~
phpnode
> 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?

~~~
csande17
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.

~~~
dfabulich
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.

~~~
csande17
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.

~~~
phpnode
In practice this would be

    
    
        <twitter-tweet id="424242424242"></twitter-tweet>
    
    

What you're saying is true only for the simplest of components.

------
lenkite
They should have made a way for simple web-components to declared and defined
without any Javascript. Simple static HTML.

