16 ms·

Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pr

• 90s_dev 1y ago
  Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.
  • kybernetikos 1y ago
    Web Components can have properties too, and in fact this is the norm.
    • skrebbel 1y ago
      Can't put those in templates though. It's a serious pain and completely unnecessary.
      • spankalee 1y ago
        You absolutely can put properties in templates. Web component authors do this all the time. Here's a lit-html template that sets a property: html`<my-element .someProp=${x}></my-element>`
        • skrebbel 1y ago
          Not in <template>s, the vanilla HTML alternative to this.
        • 90s_dev 1y ago
          At that point you're not using HTML anymore, you're just calling html() in a fancy way, and that's the whole point of the complaint, that custom-elements are not good at being plain HTML even though that's like its whole thing.
          • spankalee 1y ago
            Being plain HTML is important for the user of the element. That the element may use a library for its implementation is basically irrelevant.
            • 90s_dev 1y ago
              Hi.
          • kybernetikos 1y ago
            Normal HTML elements don't exclusively use HTML attributes either. Surely you've used button.onclick or element.classList or element.innerHTML?
        • MrJohz 1y ago
          That's not web components, though that's lit-html. That's an additional library you need to pull in to manage your web components. Which kind of ruins a lot of the stated benefits of web components. If I need a framework to write my web components, why not just pull in a different framework that skips the web component level completely and just outputs HTML/CSS directly? What is this intermediate step actually bringing me?
          • spankalee 1y ago
            How does using a library ruin the goals of the components at all? The goal of web components is to enable interoperable, encapsulated, reusable components, where how they're built is an implementation detail. You can use a web component that used lit-html without knowing anything about lit-html, it even that the component uses it.
            • MrJohz 1y ago
              In theory it is completely an implementation detail, I agree. In practice, it's bloat. If every web component I use in my project might pull in a completely different framework behind the scenes (and worse: if those web components depend transitively on other web components that pull in yet more frameworks), then I now have to deal with all of those different frameworks. Each of them will load more bytes and make my page's startup time slower. Each of them will have their own state management systems. Each of them will have their own approach to templating. Each of them will behave subtly differently in practice. Why bother when I can just write everything in a single framework?
  • jakelazaroff 1y ago
    Imagine 50 years ago: “Data passing seems inherently broken in Unix, because all processes must use strings for input and output. Such a model just can't be built on top of.”
    • 90s_dev 1y ago
      Show me a successful GUI made with bash.
      • jakelazaroff 1y ago
        Why is a GUI unsuited to stringly-typed data in a way that a CLI is not?
        • 90s_dev 1y ago
          Just an intuition.
        • jrapdx3 1y ago
          As a matter of fact, Tcl/Tk has been doing exactly that since the 1990s. Of course, Tk has been "borrowed" by other languages, Python's tkinter is well-known. Any language using Tk widgets still has to input options in text form. Obviously that's not particularly difficult to accomplish.
  • mikebelanger 1y ago
    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.
    • hdjrudni 1y ago
      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.
      • spankalee 1y ago
        And custom elements are just classes, so you can do that.
      • mikebelanger 1y ago
        >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.
    • 90s_dev 1y ago
      > <h1>${x}</h1> Fine for x:string, but what about w:WebWorker?
      • throwanem 1y ago
        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.
  • spankalee 1y ago
    This is just a lie perpetuated by the React team 10 years ago All HTML elements are JavaScript objects that have properties. You can pass arbitrary data to custom elements via those properties. Look at any modern HTML template system and you'll see the ability to pass data to properties declaratively.
    • MrJohz 1y ago
      Well it's not a lie, it's how HTML and the DOM work. Attributes are strings, and what you write in HTML will be passed as attributes. You do also have access to properties, but only in Javascript — you can't for example write something like `<my-custom-component date="new Date(2024, 02, 04)">`. That means that if you need to pass around complex data types, you need to either manipulate the DOM objects directly, or you need to include some sort of templating abstraction that will handle the property/attribute problem for you. This is my main criticism of web components. At the simplest levels, they're not useful — you could build this website very easily without them, they aren't providing a particularly meaningful abstraction at this level of complexity. But at the more complex levels, they're not sufficient by themselves — there's no state management concept, there's no templating, there's not even much reactivity, other than the stuff you could do with native JS event emitters. As far as I can tell, the best use-case for web components is microfrontends, which is a pretty useful use-case (much better than iframes), but it's very niche. Apart from that, I really don't see why you wouldn't just write normal Javascript without worrying about web components at all.
      • spankalee 1y ago
        It is absolutely a lie, because web components can handle arbitrary data just at much as any framework. You're holding web components to a higher standard here in expecting them to take arbitrary data in HTML when HTML itself doesn't support arbitrary data. Notably you can't assign arbitrary data to framework components from within HTML either, so how are web components any more limited?
        • MrJohz 1y ago
          The original comment was that "all HTML attrs must have string keys and values", which is completely true. The point of web components is that they create normal HTML elements. So it makes sense to consider what the value of them being normal HTML elements is. You can write them directly in your HTML source code, for example. But if you do that, you only get access to attributes and not to properties, and therefore everything needs to be strings. Alternatively, you can treat them as DOM nodes in Javascript, at which point you get access to properties and can use non-string values, but now you've got to deal with the DOM API, which is verbose and imperative, and makes declarative templating difficult. Yes, we could compare them to components from other frameworks, but that's honestly an absurd comparison. They're simply trying to do different things. Frameworks aren't trying to create HTML elements. They're trying to reactively template the DOM. It's just a completely different goal altogether. The comparison doesn't make sense.
  • WorldMaker 1y ago
    The "old ways" are relevant again here. Just like in the old Progressive Enhancement era (the jQuery/Knockout era) to pass objects/arrays as attributes you use the special data- attributes and the `dataset` property. As the old ways suggest you probably still want to account for strings and serialize/deserialize via JSON for the most compatibility with things like static rendering, but many a jQuery script "upgraded" such things in-place.
• mmcnl 1y ago
  State management is arguably one of the most important problems to solve. That's why we use React and Vue. You can very easily build complex user interfaces at scale with those frameworks. And you can even take web components along for the ride if you want to. They are partially overlapping solutions for different problems.
• ilaksh 1y ago
  some people cheat by using web components but with Lit Elements. https://lit.dev/ https://lit.dev/ . I use it with raw JS without any bundling.
  • owebmaster 1y ago
    Same. Recreating a basic lit framework is like 300 lines of code
• chenster 1y ago
  Microsoft solved this with VIEWSTATE in ASP.NET it's perfect, then industry went with everything Ajax and other over engineered frameworks.
  • TimTheTinker 1y ago
    You don't know how much easier it was at that time (at least for web developers with little prior ASP experience) to: - write a simple web service in C# on top of ASP.NET MVC v1 - build a web frontend on top of it using Prototype.js (or jQuery) and a library of components like ExtJS