3 ms·

This seems to be a pretty low-effort post without any real substantive details. I'd much rather see discussion of the "Parallel Evolution of React and Web Comp

• andrewchilds 2y ago
  It seems like it was written by ChatGPT.
  • benatkin 2y ago
    Here's my quick rebuttal, as someone who likes/uses parts of Web Components but knows it's no panacea. ChatGPT could improve on it I'm sure. > 1. No Need for Node.js: Keeping Development Simple You can have code that requires a server or build script with and without web components. You can have code that doesn't require those with and without web components. > 2. Native Browser Support: No Server-Side Rendering Headaches This is the point that makes the least sense. You can opt out of server-side rendering when using a non-WC framework, and you lose the headaches. If you don't want server-side rendering and are just glad that Web Components gives you an excuse to not support it, that's silly. If you want server-side rendering, it is possible with Web Components but there's currently a lot more guidance on how to do that with popular non-Web Component frameworks. > 3. No Compilation Required: Write Once, Run Anywhere Duplicate of #1. smh > 4. Universal API, No Lock-In Does Lock-In just mean including an unencumbered open source library? The API doesn't provide a whole lot. That's why a lot of people are using Lit. When you have Lit, you have some of what is called Lock-In. > 5. Smaller, Faster, and More Performant It encourages you to do things that are less performant, maybe only by a little bit, but still. Having a shadow DOM for each item in a large collection means you'd likely have an event handler instead of one that bubbles up. Luckily this is totally optional with Web Components. You can have a Custom Element without a shadow DOM, or you can just create plain elements for items in a large collection and have those bubble up. You can also have your events be composed and they will cross the shadow DOM boundary, though that is tricky in some cases. > 6. Better Long-Term Maintainability If you are using a framework (or library), you have to keep up with changes to the framework. If you aren't using one, you may have to do extra maintenance because you're doing something extra that would normally be handled by a framework (or library). > Conclusion: Embracing the Simplicity of Web Components Some stuff is simple, some stuff is not. Edit: I realized that Lock-In could refer to how frameworks try to manage the child elements by default. This can be disabled, and you can have something manage its own child elements. Otherwise you wouldn't be able to use stuff like CodeMirror inside of React. That tends to be done with a ref.
    • ohlanre 2y ago
      >You can have code that requires a server or build script with and without web components. You can have code that doesn't require those with and without web components. Believe it or not, there are other server-side languages apart from node. Without Node, you can't SSR in any of those frameworks, so i don't know how that changes my point >This is the point that makes the least sense. You can opt out of server-side rendering when using a non-WC framework, and you lose the headaches. But you miss out on performance... without SSR you are bypassing the html parser and just abusing JS to manipulate the DOM. > Duplicate of #1. smh If you insist. > The API doesn't provide a whole lot. That's why a lot of people are using Lit. Oh no, a js library. Your other points aren't even worth responding to.
      • benatkin 2y ago
        Ah, I see the point about SSR. Yes, frameworks like React and Vue make it less obvious how to do non-framework SSR. However, they don't make it impossible. You can have React and Vue render on an individual element and not the whole document. The HTMLElement part of web components are actually a decent way to do that. You can make a thin wrapper HTMLElement that runs createRoot. https://react.dev/reference/react-dom/client/createRoot https://react.dev/reference/react-dom/client/createRoot
        • ohlanre 2y ago
          Do you know what SSR is?
          • deleted 2y ago
            [deleted]
  • ohlanre 2y ago
    How so?
    • lolinder 2y ago
      Was it? I confess that I initially downvoted them on principle but came back to remove the downvote after reading the article because it did have strong LLM vibes. There were lots of turns of phrase that didn't feel natural in a technical blog post but are common in ChatGPT's prose. But honestly the bigger red flag for me was the listicle format, with a numbered 6-point outline fleshed out with a few paragraphs per heading and no transitions or relationships of any kind between sections. It felt like something written in chunks and stitched together afterward, which is a common artifact of a ChatGPT workflow (since it produces small chunks of text at a time rather than whole coherent essays).
      • ohlanre 2y ago
        It wasn't and I'm not particularly fond of LLMs, that's just how i write.
  • endofreach 2y ago
    96.3% confidence score that this post was written by/edited with ChatGPT 4-o.
• ohlanre 2y ago
  I must be missing something. Could you point me to the section(s) in any of those that make the same point I'm trying to? Or, how many more words do I need to use to say 'Web components don't force you to use Node and don't require a build step'?
  • johnny22 2y ago
    Isn't that what people already know about webcomponents? So you'd need to instead write about why that matters?
    • ohlanre 2y ago
      You can't look up web components on MDN? And if not why it matters, what's my article saying?