[kubb]

For the frontend work that I did, Lit was a godsend. It really helps you build components and apps without getting in the way.

In comparison, Angular is a monster, and React is designed for the old browser capabilities, and is now staying around by inertia, not by inherent quality.

[pmg101]

Which old browser capabilities are you referring to? Could you say more, or link to more details?

[kubb]

No shadow DOM, no web components, no template strings, etc.

[troupo]

> No shadow DOM

Funny you should say that when the current advise for web components is to avoid Shadow DOM (almost like the plague)

> no web components

As in?

> no template strings

Why would React need template strings? React is not the only framework that doesn't use template strings for anything (Vue, Solid, Svelte come immediately to mind). And it's hard to accuse those of being behind the times when Solid is literally the reason for the upcoming native signals proposal

[azangru]

> the current advise for web components is to avoid Shadow DOM (almost like the plague)

Could you provide the source for this advice?

[troupo]

It may have actually started with Web Components Community Group report itself: https://w3c.github.io/webcomponents-cg/2022.html

--- start quote ---

It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.

--- end quote ---

And probably continued in HTML Web Components https://blog.jim-nielsen.com/2023/html-web-components/

A more technical and measured take on Shadow DOM is here: https://nolanlawson.com/2023/12/30/shadow-dom-and-the-proble...

[jfagnani]

It's wrong - both that it's general "current advice", and the advice itself when it does pop up.

Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only building leaf nodes so they don't need composition with slots. As soon as they try to build any kind of container element they hit big problems.

[azangru]

In a parallel discussion happening on Mastodon, someone says:

> People coming from React-land can have a hard time reasoning about the difference between a custom element and a template render function and when best to use each

> This abuse of the component system can indeed lead to a massive explosion in nodes on a page and the performance tanks because of that

I know I certainly have that hard time deciding when I need a custom element and when a render function.

[0] - https://front-end.social/@5t3ph/115135994774490769

[brazukadev]

> As soon as they try to build any kind of container element they hit big problems.

That's not true. Web components that render nothing will contain only their children as nodes, that's good enough for a good amount of container use cases.

So you can have something like:

  <uix-modal>
    <uix-button icon="wifi"></uix-button>
    <dialog>
      <div class="flex flex-col gap-4 p-4 w-[640px]">
       ...
      </div>
    </dialog> 
  <uix-modal>

It could be better, but this little annoyance is still better than React, Angular, and the other options.

[troupo]

> It's wrong - both that it's general "current advice", and the advice itself when it does pop up.

Unless you actually care about the web and its users. Then it turns out it's a very wise advice.

https://w3c.github.io/webcomponents-cg/2022.html

Web Components Community Group: 2022. You are one of the authors:

--- start quote ---

It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM.

...

Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality

...

Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM.

--- end quote ---

Those are just the tip of the iceberg as these are very explicitly stated in the doc.

Then there's the issues of shifting the responsibility to both developers and consumers to handle Shadow DOM correctly.

Styling/themeing is still pain despite several different specs like shadow parts.

Don't use styles in your components too much, use Javascript to inject CSS into document and shadow trees or else there will be performance impact https://w3c.github.io/webcomponents-cg/2022.html#constructab...

Don't use too many shadow roots or there will be performance impact https://front-end.social/@5t3ph/115135994774490769 (linked in the sibling comment by @azangru)

You can't participate in forms until you write more JS for it, and still your submit buttons will be broken with no solution in sight.

etc. etc.

You don't have to take my word for it. Here's Nolan Lawson, emphasis mine:

--- start quote ---

https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibil...

Shadow DOM is a kind of retcon for the web. As I’ve written in the past, shadow DOM upends a lot of developer expectations and invalidates many tried-and-true techniques that worked fine in the pre-shadow DOM world.

--- end quote ---

[pmanu]

That’s also why I really like Aurelia framework. Its component model feels very intuitive, and it embraces standards like custom elements and decorators instead of inventing new patterns. Compared to Angular’s boilerplate or React’s hook gymnastics, Aurelia lets you write less code that looks more like plain JS/HTML. Too bad Aurelia never got the same traction as the big frontend names, because the DX is really solid.

[SebastianKra]

I thankfully migrated or left all Aurelia projects, but every time someone mentions it, I remember new horror stories.

Its .html temples were shipped unmodified directly to the client (yes, including comments). Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template.

Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch for mutations). It would frequently resort to polling on every tick or break completely.

DI used TypeScripts experimental decorators, even long after it was clear that it would never become stable.

On the other hand, templates weren't type checked.

[pmanu]

Never had issues with the HTML. Templates sometimes showed comments in dev mode, but in production builds they were stripped and everything minified. I never used Webpack or other bundlers, only the "dumber.js" from their CLI, so maybe was something related to that?

And yeah, probably they monkey-patched arrays and such, but that was just the way of the world before proxies and native signals. The cool part is Aurelia stuck to web standards, and those “weird mechanisms” were basically polyfills, so even old versions still run solid today, sometimes even faster by leveraging native features.

[SebastianKra]

> Never had issues with the HTML

https://github.com/aurelia/binding/issues/108

> I never used Webpack

That has little to do with Aurelia, and Aurelia itself integrates with Webpack: https://github.com/aurelia/webpack-plugin

> The cool part is Aurelia stuck to web standards, and those “weird mechanisms” were basically polyfills

I could agree that Aurelia looks like you’re sticking to standards¹. If you don’t think about it, then everything kinda works 90% of the time.

But when you actually try to understand what goes on behind the scenes, like you can with React and Angular, there are just so many footguns, especially around composition and reactivity.

Even simple things like passing optional props² or detecting if a <slot> is occupied involved depressing amounts of reverse-engineering.

I’ve heard that Aurelia 2 supposedly fixes many of my issues, but I believe the core idea is beyond fixing. React, Solid and others have more powerful approaches that require fewer concepts to understand.

¹ Although there are still tons of custom concepts and syntax to learn.

² https://github.com/aurelia/templating-binding/issues/106

[SebastianKra]

I thankfully migrated or left all Aurelia projects, but every time someone mentions it, I remember new horror stories.

Its .html temples were shipped unmodified directly to the client. Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template.

Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch for mutations). It would frequently resort to polling on every tick or break completely.

DI used TypeScripts experimental decorators, even long after it was clear that it would never become stable.

On the other hand, templates weren't type checked.

[iamsaitam]

"React is designed for the old browser capabilities and is now staying around by inertia, not by inherent quality." this makes me feel old and I guess React is famous for supporting Internet Explorer /s

[kubb]

React is 12 years old. That’s a significant chunk of anyone’s life.

[troupo]

Web components are 14 years old, and still have the most basic issues and problems that even a 6-month-year-old framework would ashamed to have.

[kubb]

I await your in depth critique on the front page.

[troupo]

You think that in 14 years many critiques from many authors didn't appear on the front page? It's not a big deal to reach the front page of HN.

No worries, web components themselves have a very nice critique in the form of their own community report https://w3c.github.io/webcomponents-cg/2022.html listing all the issues that many people had been taking about for literal years before this report.

[evilduck]

There have been many that have hit the front page over the years. If you're not aware of a technology's shortcomings then you're a bad proponent of said technology. They're also almost the antithesis of what the HTMX crowd also preaches as "the one true way" and meanwhile, Wordpressers will continue developing the majority of the world's websites blissfully unaware that either technology even exists.

https://dev.to/ryansolid/web-components-are-not-the-future-4...

https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

https://daverupert.com/2023/07/why-not-webcomponents/

https://paularmstrong.dev/blog/2023/03/11/why-we-do-not-writ...

https://nolanlawson.com/2024/09/28/web-components-are-okay/

https://www.zachleat.com/web/good-bad-web-components/

https://mayank.co/blog/web-components-considered-harmful/

https://adamsilver.io/blog/the-problem-with-web-components/

https://web-highlights.com/blog/are-web-components-dead/

along with some criticisms from very knowledgeable people:

https://x.com/youyuxi/status/1839833110164504691 (author of Vue) https://x.com/Rich_Harris/status/1839785839036887361 (author of Svelte)

Web Components solve a few problems and introduce a few others, use them when they make sense for your needs.