Web components are objects and they have properties that can be set. The entire web components community - which includes the developers of apps like Photoshop, Reddit, Chrome, Firefox, and a lot more - passes properties down through trees of web components _all the time_.
Maybe a bit verbose, but here is an example https://jsfiddle.net/8kvucm9f/5/ in the context of the blog post (and with my preferences of doing things; there are just many different ways of "writing web components", and can adapt many use cases).
Also, by using their HTML attributes (id="", name=""), it is possible to make really nice features with CSS.
Finally, they can offer a clear API (just like the <img/> or <video/> or <input/> elements), to the users of these elements.
They can be inserted, to give "markdown" documents (or .org mode etc. if it is converted to HTML), JSX like features, by being "just embedded HTML text".
It is super powerful, maybe feels a bit scary at first, but all problems seems to get solvable with clean patterns.
You can declaratively pass objects between web components in every web components library out there like Lit or Stencil.
Now, you may claim that that doesn't count because the declarative part is implemented in non-standard userland libraries, to which I would reply:
1) So what? React is a non-standard userland library. You can't pass data declaratively between React components without React. At least with web components there's a standard _interface_ for the components so that many different libraries can implement the declarative parts in a completely interoperable way.
2) Yes, you can't pass objects around in plain HTML because plain HTML doesn't have references to the objects in the first place. Even if you did add a way to set properties in HTML, what would you set them to?
2b) This is actually likely changing as the Template Instantiation proposal moves along and possibly gets the ability to make property bindings. This will be useful for declaring custom elements that accept properties. But the question remains: where do those properties originate from? Most likely JavaScript, because HTML doesn't have any.
They capitalized Web Components, I think they're talking about what browsers natively support and not a library or framework.
This makes it a non-standard library-specific method of passing things.
I have no idea what you're arguing against.
There's literally no way to pass objects as attributes to web components. Web components had a great opportunity to get rid of attributes/properties dichotomy, but they doubled down on them.
> At least with web components there's a standard _interface_ for the components so that many different libraries can implement the declarative parts in a completely interoperable way.
Of course there's nothing standardised, and nothing interoperable. Because if one web component exposes its API through attributes, and the other one through properties, and a third one through both, never the three shall meet. Without library-specific hacks.
There's a reason the "standardized" lit uses a custom DSL to distinguish between things:
`<some-component
attribute="string only"
?boolean=${boolean}
.property=${any_js_variable}
@event_name=${callback_function}
>`
Edit:
Stencil uses JSX (non-standard), so it doesn't care and probably sets properties directly, skipping attributes. For object props and HTML it says it explicitly that you cannot set them (of course): https://stenciljs.com/docs/properties#object-props
> But the question remains: where do those properties originate from? Most likely JavaScript, because HTML doesn't have any.
Indeed. That is another issue with anything web-component-related. Moar Javascript. As if we don't have enough. There are now dozens of more JS APIs existing just because of web components, and even more are incoming: https://w3c.github.io/webcomponents-cg/2022.html
This is so very much not true. On what basis do you even claim this?
Web components are JavaScript objects that extend from HTMLElement. They all share a common interface of attributes, children, events and properties.
You can get a reference to any web components any set a property on it:
document.querySelector('my-element').someProp = {};
> There's literally no way to pass objects as attributes to web components
How do you even get a reference to an object in HTML to pass as an attribute, if you could?
And who cares? You can pass objects as properties to web components. Attributes are string-valued, why would you want to pass an object to them?
I worte the basis, and you completely ignored it.
> And who cares?
Ah yes. The mantra of all web-component zealots. "Who cares".
How it started [1]: "we have too much Javascript, we rely on too much Javascript for all our functionality, empty body tag is the bane of web sites" etc.
How it's going: Who cares? Dozens of new JS APIs! More JS APIs coming every month. Why would you want to do anything with web components outside of Javascript? Declarative? Oh, in any of the Javascript libraries. Javascript Javascript Javascript Javascript Javascript.
> Attributes are string-valued, why would you want to pass an object to them?
That is not what anyone wrote. Literally not a single person.
Anyway, this is hopeless. Web Component zealots are absolutely deaf and blind to anything outside of their world where goals shift faster than grains of sand in a hurricane.
[1] The original pitch for Web Components: https://fronteers.nl/congres/2011/sessions/web-components-an...
If you start with such a statement, it would be best to follow up with proof instead of something unrelated.