Thread

1. jchw · 1791089619 · focus · HN ↗

   For one thing, I just genuinely think WebComponents are a badly designed API that is weird and hard to use (how many people are using WebComponents without at least Lit, if not something much bigger?), and React is a relatively well-designed library that isn't really that bloated. There's not really much of a point in trying to argue since this is inherently subjective and people with different values are going to irreconcilably disagree. But, if you don't respect that some people hold this position, we're not going to make any progress towards a consensus.

   On the note of <dialog>, I recently tried to use <dialog> in a (React) application, and it did work pretty well, but I also found that in Firefox it is only practically possible to do a fade-in animation, not a fade-out one. That isn't really a critical issue for me, it is just an animation after all, but I find it unfortunate. I also find <dialog> to be a weirdly shaped API too: I don't really hate it, but I don't love it either. It feels awkward.

   I find this implicit view that developers that, for example, prefer React over WebComponents are making a suboptimal choice to be rather condescending and not really in the spirit of trying to see things from the other side. Wouldn't you want to focus on the strongest arguments and not the weakest ones? Maybe you've literally never heard anyone complain about WebComponents or Shadow DOM, but if so, I find that surprising. Certainly here on HN, I've seen a fair bit of WebComponents hate.

   I do, FWIW, realize that I've particularly focused on WebComponents, which this article doesn't actually name directly. But, I assume we're not talking about ditching React to implement our own component framework on top of the traditional DOM APIs, because that's what React already does...

   1. mg · 1791094775 · focus · HN ↗

      What do you not like about WebComponents?

      Say we want to make an icon that when clicked shows how often it was clicked. The webcomponent code seens quite sane to me:

         class HelloIcon extends HTMLElement {
            connectedCallback() {
              this.clickCount = 0;
      
              this.innerHTML = `
                <button class="icon">:)</button>
                <dialog>
                  <p>Hello, I was clicked 0 times</p>
                  <button class="close">Close</button>
                </dialog>
              `;
      
              const icon = this.querySelector('.icon');
              const dialog = this.querySelector('dialog');
              const closeBtn = this.querySelector('.close');
              const dialogText = this.querySelector('p');
      
              icon.addEventListener('click', () => {
                this.clickCount++;
                dialogText.textContent = `Hello, I was clicked ${this.clickCount} times`;
                dialog.showModal();
              });
      
              closeBtn.addEventListener('click', () => dialog.close());
            }
          }
      

      Try it here:

      <a href="https:&#x2F;&#x2F;plnkr.co&#x2F;edit&#x2F;0XUOLyM52xfFiIBu?open=index.html&amp;preview" rel="nofollow">https:&#x2F;&#x2F;plnkr.co&#x2F;edit&#x2F;0XUOLyM52xfFiIBu?open=index.html&amp;previ...

      1. kaoD · 1791096614 · focus · HN ↗

         That&#x27;s the best case scenario and already looks like crap. If that looks sane to you, I don&#x27;t know what to say.

         Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You&#x27;re in for a world of pain even for something as simple as this.

         Plus they&#x27;re not declarative: you will only make me use innerText-based updates by threatening me and my family.

         Plus they only work with JS enabled, while I can use JSX in SSR.

         I&#x27;ve worked extensively with Web Components. They suck.

         1. jdkoeck · 1791149245 · focus · HN ↗

            Web components are intentionally low-level, they’re not really meant to be used directly. You should see them more as performant, interoperable building blocks. Have you tried lit?

            1. spiffytech · 1791167200 · focus · HN ↗

               This circles back to the OP&#x27;s point: they&#x27;re not appropriate to use directly, so we layer a framework on top of them (Lit), and now we&#x27;re just using another framework with one small piece swapped out.

               Except for the hyphens, I don&#x27;t feel any closer to the platform when I use Lit.

               1. jdkoeck · 1791176447 · focus · HN ↗

                  You can inspect a Lit component directly in Chrome, it’s just a custom element. No need for a browser dev extension. You can use this custom element from React or any other JS framework. You can also use this custom element in a server-rendered template, no need for any custom SSR setup. Feel close to the platform yet?

Unofficial Hacker News client; not affiliated with Y Combinator.