Presumably I've defined a .toString() method on w that will behave as I wish when implicitly invoked to perform this coercion.

If I haven't, then presumably I'll be satisfied with the inherited default behavior, which will probably look something like "<h1>[object Worker]</h1>".

If I care about this extremely contrived example case, in other words, I'll do something to handle it. If I don't, I won't. If I do, it's been easy for at least 25 years now; iirc .toString() was specified in ES3, which was published in March 2000.

Yeah sorry I meant how would you pass it to another GUI component like we can in React.

If I want in the general case to append a child node to a parent (as here with the h1 as parent and the stringified interpolated value as child), I will in almost every case call parent.appendChild(child), where parent and child both implement Node, which is the parent class of Element. The result will correspond closely to the element tree which would be constructed by assigning a string like your example to some other element's innerHTML. (You are essentially using the browser DOM implementation as a templating engine. As sugar over a lot of createElement calls and piecewise tree construction, this isn't a terrible strategy! The JSX with which you're familiar is a more elaborate and more typesafe solution for essentially the same problem.)

Similarly, these references would be from the JS perspective a POJO with lots of seriously heavy implicit "render magic," so you can use them, as with any first-class Javascript value, as function arguments parallel to but a superset of what React does with its props. See the MDN documentation on Node.appendChild (and Node, Element, HTMLElement, etc) for more: https://developer.mozilla.org/en-US/docs/Web/API/Node

If I want to represent the state of a worker thread in the UI, a problem I first recall solving over a weekend in 2016, the way I do it will end up closely resembling the "MVC pattern," with the Worker instance as "model," the DOM element structure as "view," and a "controller" that takes a Worker and returns an element tree. Even if I'm using React to build the UI - which I have also been mostly doing for about as long - I am still going to handle this translation with a library function, even if my component actually does accept a Worker as a prop, which it actually very likely will since that will enable me to easily dispatch effects and update the UI on changes of worker state. I might define that "business logic" function alongside the component which uses it, in the same module. But React or vanilla, I won't put that logic in the UI rendering code, unless it is trivial property mapping and no more (unlikely in this case, since any interesting worker thread state updates will arrive via message events requiring the parent to keep track in some way.)

Does that help clear up what I'm getting at?

What would you expect that to do, in any framework?

In React, say, I might write

    <MyComponent worker={worker} />

and expect the worker instance to be passed as an object to `MyComponent` as a prop. But with webcomponents, I can't do something like that.

    this.innerHTML = `<my-component worker="${worker}">`

will just stringify the worker and pass that string to the `my-component`. To get the worker instance to be passed correctly, I'd need to do something like

    this.innerHTML = `<my-component>`
    this.firstChild.worker = worker;

With any web component you could assign the worker to a property, either imperatively:

    el.worker = worker

Or declaratively:

   html`<my-component .worker=${worker}></my-component>`

That's using lit-html syntax, but there are a lot of other rendering libraries that work similarly.

Every time I go back to give Web Components another 5 minutes, I hit this point where using lit or a lit-like would take a lot of the pain of the problems Web Components don't solve and have no planned solution for away.

But once I decide to cross the "no dependencies" line, using something like Preact + htm as a no-build solution would also take the most of the rest of the pain away, and solve many, many other problems Web Components have no solution and no planned solution for.

So this isn't even a question about web workers, it's a question about how to prop-drill non-string/number data through multiple layers of web-components.

Tbh, I'm not sure there's a way for that. But why not just define a method in your target child component and pass the worker in there?

Yeah, I think the original question was a bit weirdly worded which made people focus on web workers rather than complex data in general.

You can use properties (as opposed to attributes) as I demonstrated, and you can use methods like you suggest, but these are both verbose and limited, and add an extra "the component has been created but the props haven't been fully passed" state to the component you're writing. Imagine a component with maybe five different props, all of which are complex objects that need to be passed by property. That's a lot of boilerplate to work with.

In what way are properties verbose and limited in your view?

You can set them declaratively with a template binding in most template systems.

I showed earlier how it takes multiple lines and some fiddling with DOM to set a simple property with vanilla web components. Sure, if you're using a framework like lit, you have access to template binding, but at that point you might as well use an equivalent framework like SolidJS or Svelte which just skips the web component layer.

Bringing it back to the site, the author does describe implementations of context providers and signals:

https://plainvanillaweb.com/blog/articles/2024-10-07-needs-m... https://plainvanillaweb.com/blog/articles/2024-08-30-poor-ma...

I haven't tried signals yet, but I couldn't see why you could pass in an object with multiple values.

Skipping the web component later would skip then interoperable component part.