That said, this and many other webcomponent articles mischaracterize usage cases of webcomponents:

1. Being "Framework-free"

Frameworks can mean anything from something massive like NextJS, all the way to something very lightweight like enhance.dev or something more UI-focused like shoelace. To suggest being completely free of any kind of framework might give some benefits, depending on what kind of framework you're free of. But there's still some main benefits of frameworks, such as enforcing consistent conventions and patterns across a codebase. To be fair, the article does mention frameworks have a place further down the article, and gets close to articulating one of the main benefits of frameworks:

"If you’re building something that will be maintained by developers who expect framework patterns, web components might create friction."

In a team, any pattern is better than no pattern. Frameworks are a great way of enforcing a pattern. An absence of a pattern with or without webcomponents will create friction, or just general spaghetti code.

2. Webcomponents and the shadow DOM go together

For whatever reason, most webcomponent tutorials start with rendering things in their shadow DOM, not the main DOM. While the idea of encapsulating styles sounds safer, it does mean parts of your page render after your main page, which can lead to DOM elements "flashing" unstyled content. To me, this janky UX negates any benefit of being able to encapsulate styles. Besides, if you're at a point where styles are leaking onto eachother, your project has other issues to solve. The Shadow DOM does have its use, but IMO it's overstated:

https://enhance.dev/blog/posts/2023-11-10-head-toward-the-li...

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.

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.

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?

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.

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

    someMethod(x) {
      this.innerHTML = `
${x}
`;
    }
  }

  // ignore registry stuff

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

  customElement.someMethod(42);

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.

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

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

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!

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.

I'm not sure about AGI, but for specialized jobs/tasks (ie having a marketing agent that's familiar with your products and knows how to copywrite for your products) will win over "just add more compute/data" mass-market LLMs. This article does encourage us to keep that architecture simple, which is refreshing to hear. Kind of the AI version of rule of least power.

Admittedly, I have a degree in Cognitive Science, which tended to focus on good 'ol fashioned AI, so I have my biases.