4 ms·

I was excited for web components, but the API was lacking (the final tipping point that led me to build Joystick [1]). I just couldn't get on board with a web-s

I was excited for web components, but the API was lacking (the final tipping point that led me to build Joystick [1]). I just couldn't get on board with a web-standard that eschewed HTML in favor of stuff like this [2] where list items are attributes. The hyphenated namespace thing has always made my eye twitch, too (silly, I know). [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick [2] https://github.com/mdn/web-components-examples/blob/main/editable-list/index.html https://github.com/mdn/web-components-examples/blob/main/edi...

spankalee 3y ago
[2] Is just a bad example that you could build with anything, and had nothing to do with the spec. They could have chosen to take data as child elements, or as a JS object. Individual attributes like that is a bizarre choice and shouldn't reflect on web components. The web component APIs are low-level and what you need to achieve interop with the browser. Most developers use something like https://Lit.dev https://Lit.dev
- troupo 3y ago
  > Is just a bad example that you could build with anything This is the go to "defense" I often hear from web component proponents. If even MDN cannot come up with a better example, something's wrong with tech, not with how people use it. > The web component APIs are low-level It's not. It only got labeled low-level after the initial failure to attract any developer mindshare. And then it got rebranded as "aimed at library and framework developers". Though it barely got traction there either because it offers nothing lib and framework developers want. > Most developers use something like https://Lit.dev https://Lit.dev The irony of writing this under "Web Components will outlast your framework"...
  - spankalee 3y ago
    > This is the go to "defense" I often hear from web component proponents. > > If even MDN cannot come up with a better example, something's wrong with tech, not with how people use it. It's not a "defense" it's a very wacky demo and I can't think of a single reason why you'd ever design a component this way. You could also design a React component or Angular component this way, and just like with web components, no one does, because it doesn't make sense. I can't say why MDN decided to do this, but this is literally the only time I've ever seen a list represented as individual attributes. > It's not. It only got labeled low-level after the initial failure to attract any developer mindshare This... just isn't true. Web component APIs are things like customElements.define(), HTMLElement.attachShadow(), HTMLElement.connectedCallback(). These are objectively low-level compared to things that frameworks give you. Branding (whose?) has nothing to do with it.
    - troupo 3y ago
      > It's not a "defense" it's a very wacky demo and I can't think of a single reason why you'd ever design a component this way Because it literally is the example on MDN? > This... just isn't true. Web component APIs are things like Yes, yes they define those APIs. They are both too verbose, badly designed and low-level to use them directly, and they are too high-level, badly designed and useless for most frameworks to use them as the foundation for anything. However, even if we view them as "low-level compared to frameworks" they are still: - extremely high-level (as all DOM APIs) - were lauded as high-level and the end of all frameworks for years before being rebranded as "these are for framework authors akshually" Or, to put it simply, they are as "low level" as React's class-based APIs of yesteryear.
      - fkyoureadthedoc 3y ago
        > were lauded as high-level and the end of all frameworks for years before being rebranded Sources please? I've never met a single person that thought this. > Because it literally is the example on MDN? You're very stuck on this bad example. With even a cursory understanding of how Web Components work you can understand that you can recreate the same component accepting the same props in any popular component based framework. Or using Web Components you could do this example component just as many different ways as you could with another component framework. There are many reasons to not use Web Components. Outside of some specific use cases I wouldn't use them. "A single MDN example weirdly used multiple attributes for list items, instead of child components or one attribute" is not one of them.
        troupo 3y ago
        > Sources please? I've never met a single person that thought this. Web Components are 12 years old this year. They were lauded as the be all end all of web development to replace all frameworks for 4-5 of those years. > You're very stuck on this bad example. Because it literally is in one of the few authoritative places documenting web technologies. It's not w3schools or some personal blog. I go to MDN to lookup or verify information on web technologies.
fkyoureadthedoc 3y ago
<editable-list title="TODO" list-item-0="First item on the list" list-item-1="Second item on the list" list-item-2="Third item on the list" list-item-3="Fourth item on the list" list-item-4="Fifth item on the list" listItem="This will not appear" add-item-text="Add new list item:" > </editable-list> You could easily do this a different way, if you still wanted it to be an attribute <editable-list items='["first", "second"]'> and pass json to a single attribute. Or make child <list-item>'s. One thing about web components though, having shipped web components for an internal design system, is that a lot of people don't understand the difference between html attributes and the properties of the underlying javascript objects. In plain HTML, or most server rendered templates afaik, there's no way to pass non-string data declaratively like you could with say Vue where you can choose property vs attribute to bind data.
- rglover 3y ago
  > You could easily do this a different way Yes, but that you have to make a choice means the design is poor. That's why stuff like React (imo) is a failure: there's a kajillion ways to do the same thing which end up creating dogma and sloppy/inconsistent code (read: bugs). Web Components—as far as I've seen—are making the same mistakes, but even worse, as a standard. As a web standard, Web Components should have been more carefully crafted. There's zero reason the spec couldn't have allowed me to wrap a normal <li> tag in the example above. That it doesn't means, somewhere along the road, a compromise was made that shouldn't have been made. The problem with all of that is when you introduce new web developers (who start by learning vanilla HTML, CSS, and JavaScript), as soon as they get to wanting to build more complex stuff (read: components), they essentially have to "unlearn" much of what they learned. Why does that matter? Paraphrasing Uncle Bob: because the rate of new developers doubles roughly every five years, that means half the programmers in the world have < 5 years experience. If they're learning bad/inconsistent patterns from day one, that means the quality of the software they build (and God help us, the tools they create later) is on a permanent downward slope.
  - spankalee 3y ago
    You could do the same weird attributes thing with props in React. Does that make React's design equally poor? I don't know how you can prevent bad component designs like this.

spankalee 3y ago

[2] Is just a bad example that you could build with anything, and had nothing to do with the spec. They could have chosen to take data as child elements, or as a JS object. Individual attributes like that is a bizarre choice and shouldn't reflect on web components. The web component APIs are low-level and what you need to achieve interop with the browser. Most developers use something like https://Lit.dev https://Lit.dev

troupo 3y ago
> Is just a bad example that you could build with anything This is the go to "defense" I often hear from web component proponents. If even MDN cannot come up with a better example, something's wrong with tech, not with how people use it. > The web component APIs are low-level It's not. It only got labeled low-level after the initial failure to attract any developer mindshare. And then it got rebranded as "aimed at library and framework developers". Though it barely got traction there either because it offers nothing lib and framework developers want. > Most developers use something like https://Lit.dev https://Lit.dev The irony of writing this under "Web Components will outlast your framework"...
- spankalee 3y ago
  > This is the go to "defense" I often hear from web component proponents. > > If even MDN cannot come up with a better example, something's wrong with tech, not with how people use it. It's not a "defense" it's a very wacky demo and I can't think of a single reason why you'd ever design a component this way. You could also design a React component or Angular component this way, and just like with web components, no one does, because it doesn't make sense. I can't say why MDN decided to do this, but this is literally the only time I've ever seen a list represented as individual attributes. > It's not. It only got labeled low-level after the initial failure to attract any developer mindshare This... just isn't true. Web component APIs are things like customElements.define(), HTMLElement.attachShadow(), HTMLElement.connectedCallback(). These are objectively low-level compared to things that frameworks give you. Branding (whose?) has nothing to do with it.
  - troupo 3y ago
    > It's not a "defense" it's a very wacky demo and I can't think of a single reason why you'd ever design a component this way Because it literally is the example on MDN? > This... just isn't true. Web component APIs are things like Yes, yes they define those APIs. They are both too verbose, badly designed and low-level to use them directly, and they are too high-level, badly designed and useless for most frameworks to use them as the foundation for anything. However, even if we view them as "low-level compared to frameworks" they are still: - extremely high-level (as all DOM APIs) - were lauded as high-level and the end of all frameworks for years before being rebranded as "these are for framework authors akshually" Or, to put it simply, they are as "low level" as React's class-based APIs of yesteryear.
    - fkyoureadthedoc 3y ago
      > were lauded as high-level and the end of all frameworks for years before being rebranded Sources please? I've never met a single person that thought this. > Because it literally is the example on MDN? You're very stuck on this bad example. With even a cursory understanding of how Web Components work you can understand that you can recreate the same component accepting the same props in any popular component based framework. Or using Web Components you could do this example component just as many different ways as you could with another component framework. There are many reasons to not use Web Components. Outside of some specific use cases I wouldn't use them. "A single MDN example weirdly used multiple attributes for list items, instead of child components or one attribute" is not one of them.
      - troupo 3y ago
        > Sources please? I've never met a single person that thought this. Web Components are 12 years old this year. They were lauded as the be all end all of web development to replace all frameworks for 4-5 of those years. > You're very stuck on this bad example. Because it literally is in one of the few authoritative places documenting web technologies. It's not w3schools or some personal blog. I go to MDN to lookup or verify information on web technologies.

fkyoureadthedoc 3y ago

<editable-list title="TODO" list-item-0="First item on the list" list-item-1="Second item on the list" list-item-2="Third item on the list" list-item-3="Fourth item on the list" list-item-4="Fifth item on the list" listItem="This will not appear" add-item-text="Add new list item:" > </editable-list> You could easily do this a different way, if you still wanted it to be an attribute <editable-list items='["first", "second"]'> and pass json to a single attribute. Or make child <list-item>'s. One thing about web components though, having shipped web components for an internal design system, is that a lot of people don't understand the difference between html attributes and the properties of the underlying javascript objects. In plain HTML, or most server rendered templates afaik, there's no way to pass non-string data declaratively like you could with say Vue where you can choose property vs attribute to bind data.

rglover 3y ago
> You could easily do this a different way Yes, but that you have to make a choice means the design is poor. That's why stuff like React (imo) is a failure: there's a kajillion ways to do the same thing which end up creating dogma and sloppy/inconsistent code (read: bugs). Web Components—as far as I've seen—are making the same mistakes, but even worse, as a standard. As a web standard, Web Components should have been more carefully crafted. There's zero reason the spec couldn't have allowed me to wrap a normal <li> tag in the example above. That it doesn't means, somewhere along the road, a compromise was made that shouldn't have been made. The problem with all of that is when you introduce new web developers (who start by learning vanilla HTML, CSS, and JavaScript), as soon as they get to wanting to build more complex stuff (read: components), they essentially have to "unlearn" much of what they learned. Why does that matter? Paraphrasing Uncle Bob: because the rate of new developers doubles roughly every five years, that means half the programmers in the world have < 5 years experience. If they're learning bad/inconsistent patterns from day one, that means the quality of the software they build (and God help us, the tools they create later) is on a permanent downward slope.
- spankalee 3y ago
  You could do the same weird attributes thing with props in React. Does that make React's design equally poor? I don't know how you can prevent bad component designs like this.