Yeah that'd be really something. If you could just pay the cost up-front, rather than worry about how much every newer request cost, that really changes the game. There's still many other issues to worry about, like security. But as the author points out, we might be much closer than we think.

Artifactory works fairly well. Although admittedly, when a user grabs a new dependency, they're downloading from the npmjs registry like anyone else.

Really, the killer combo would be to have some kind of LLM-based tool that would scan someone's artifactory. Something smart enough to notice that code changed, and there's code for accessing a crypto-wallet, etc. This would be too expensive for npmjs to host for free, but I could see this happen to hosted artifactory dependencies.

I really wish web components weren't promoted as a "framework alternative" and more of a standardization of custom display components. Frameworks like enhance.dev and lit.dev are good examples of this.

Great resource! I particularly like the fact that their web component section doesn't use the shadow DOM. It's really too bad custom elements got associated with shadow DOM, as they're so useful beyond the more niche usage cases of the shadow DOM.

> It's really too bad custom elements got associated with shadow DOM

Because it was heavily pushed, advertised, and is the default way of writing web components (you have to explicitly specify mode: open)

> you have to explicitly specify mode: open

The mode does not toggle the shadow DOM on and off. It just specifies whether or not the element's shadowRoot object is a public property. An open mode makes this possible: `document.querySelector('my-component').shadowRoot`.

You have to explicitly opt-in to the shadow DOM either imperatively by calling `attachShadow`, or declaratively in HTML by giving the element a template child element with a `shadowrootmode` attribute.

I stand corrected!

You can invoke custom methods and pass in any kind of data into them. As in

  class SomeElement extends HTMLElement {
    constructor() {
      super();
    }

    someMethod(x) {
      this.innerHTML = `<h1>${x}</h1>`;
    }
  }

  // ignore registry stuff

  const customElement = document.getElementById('custom-element-id');

  customElement.someMethod(42);

But you won't learn that from most mainstream custom element tutorials though, for whatever reason.

I'm late getting to this but someone emailed us to point out that your attempt at code formatting didn't quite work, so I fixed it, using the formatting markup documented here: https://news.ycombinator.com/formatdoc. Hope that's OK!

> <h1>${x}</h1>

Fine for x:string, but what about w:WebWorker?

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.

That doesn't look like it even has anything to do with custom components, that's just adding a method to a class. OOP 101.

>just adding a method to a class. OOP 101.

You're right, it is just a method call from a class. Nothing interesting or new. And that's exactly why I like it! I like me FE code as boring, unimpressive and as simple as possible.

And custom elements are just classes, so you can do that.

>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.

I feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to use when they were initially created. Since then, I've become burned out from the constant churn of new frontend frameworks to learn. Even within the world of React, there's different ways of writing components, and different state managers.

I wanted to refute the "the constant churn of new frontend frameworks to learn". If you just stuck with React since 2015, they've only had 4 major versions since then and every ver they deprecate only a few things and then you have a full release cycle to migrate to the new hot thing. It's probably the best upgrade paths of any of the libs I work with.

But you're not wrong about there being many ways to write components and manage state.

And RSC is a mess. But thankfully you can keep pretending that doesn't exist.

> I wanted to refute the "the constant churn of new frontend frameworks to learn". If you just stuck with React since 2015, they've only had 4 major versions since then and every ver they deprecate only a few things and then you have a full release cycle to migrate to the new hot thing.

Contrast that with non-framework JS/HTML, where _you_ decide how long it lives and how often you need to upgrade (or not). Having to rejigger a web app every 2-3 years because someone outside of your organization changes something is not only unappealing, but it's horribly expensive for large-scale businesses and possibly prohibitively expensive for small-scale businesses or solo developers.

It happened to me with a personal project, I abandoned it for about 2 years and one day I decided to take it up again to add some features and when I did npm install I almost died.

The nice thing about the plain "vanilla" approach is it can be used to enhance a more traditional SSR-rendered site. And it doesn't need a complete rewrite in React or whatever.

The author of this article blog is describing some more advanced SPA-like scenarios, but those are completely optional

React aficionados will disagree though, and tell you to move your logic into the React framework using code.

> It’s doesn’t have to be especially onerous discipline if you embrace it, but it becomes considerably more onerous as it becomes more social: if some members of a team/contributors to a project embrace it more/less than others, that difference in commitment becomes a constant source of friction.

That's one of the stronger arguments for opinionated pre-processors/frameworks/libraries like Typescript/TSX/JSX/React in general. Because it abstract away those things that only some team members would embrace, you effectively make everyone embrace them. That leads to less friction.

But this reduced friction comes at a cost: more complex abstractions and incidental bugs related to that complexity. And as far as the procedural vs declarative: after a certain degree of complexity, I find myself introducing procedural codes within useEffects, useMemos anyways

I've been using Zed for a few months now. One thing I really like about Zed is its relatively discrete advertising of new features, like this edit prediction one. Its just a banner shown in the upper-left, and it doesn't block me from doing other stuff, or force me to click "Got it" before using the application more.

This definitely counters the trend of putting speech balloons/modals/other nonsense that force a user to confirm a new feature. Good job, Zed team!

I read this wrong initially — I thought you said one thing you __dislike__ about Zed.

I read the whole thing thinking, __oh my god they do exist__

How would plumbing and wiring work? The article states that the wall is a semi-hollow, corduroy pattern, so do the printers leave openings in the walls so pipes/wiring get shoved into them after?

Yes. I visited that site and examined some of the partially constructed buildings, and talked to a couple of the workers.

They have videos discussing how you would add a light switch or remove one -- basically a mansonry hole saw, and matching grout to fill in.

It seemed slightly more trouble to do modifications than a cinder block wall, but the quality and strength was much higher. I went with low expectations but I was impressed.

I didn't see any walls at the stage of construction where I could see what the insulation was, whether is was expanding foam or fiberglass.

> It seemed slightly more trouble to do modifications than a cinder block wall, but the quality and strength was much higher. I went with low expectations but I was impressed.

So the electricians and plumbers would all come in after the wall was printed, and saw through it all? Sawing, adding and then filling it back in sounds like lots of work to me. With stick-frame, wiring and plumbing are still a significant cost, but the actual hole-making part would be a small proportion of it.