4 ms·

Good article. This articulates a number of issues that I wasn't able to put into words, particularly around this idea that the DOM can be a really inconvenient

Good article. This articulates a number of issues that I wasn't able to put into words, particularly around this idea that the DOM can be a really inconvenient way to track state. I still kind of feel like I need to sit down and figure out exactly what my issue is with the current spec, but roughly speaking I guess I'd say that the DOM should be a standardized display layer, not a way to store internal application state. Or put it another way, the DOM is for your users, not for your application. I don't think that fully captures the problem, but it's a bit closer. Regardless, I often flail when people ask me why I'm a little skeptical about the way web components are currently designed, so at least now I have something to point them towards.

interlocutor 7y ago
When you use radio buttons, checkboxes and text inputs, they have state and that state is in DOM. Web Components don't change this.
- danShumway 7y ago
  Again, this is tough to articulate, and I'm not sure I'm going to do a good job, but: Good design seeks to limit the amount that we rely on that state in the DOM. Typically speaking, I try to listen for events on input elements. I don't rely on them as a state store. Text inputs in particular here are kind of a good example, because they often get used in combination with validation and autofill. I've seen a lot of bugs and spaghetti code come out of running validation on field update, and using that validation to update or fill in other fields, and needing to track which update will trigger another event, and so on. I'm not saying we should get rid of interactive elements on the web, but I think they fall into something of a grey area that shouldn't necessarily be encouraged. I use inputs to get the current user state, and to respond to user input -- I try very hard not to use them as a state store for application-level data. I kind of think I would still say the same thing about inputs as I would about regular HTML elements -- input elements are for your users, they're not for you. They're not your interface, they're just the way your users communicate with you.

interlocutor 7y ago

When you use radio buttons, checkboxes and text inputs, they have state and that state is in DOM. Web Components don't change this.

danShumway 7y ago
Again, this is tough to articulate, and I'm not sure I'm going to do a good job, but: Good design seeks to limit the amount that we rely on that state in the DOM. Typically speaking, I try to listen for events on input elements. I don't rely on them as a state store. Text inputs in particular here are kind of a good example, because they often get used in combination with validation and autofill. I've seen a lot of bugs and spaghetti code come out of running validation on field update, and using that validation to update or fill in other fields, and needing to track which update will trigger another event, and so on. I'm not saying we should get rid of interactive elements on the web, but I think they fall into something of a grey area that shouldn't necessarily be encouraged. I use inputs to get the current user state, and to respond to user input -- I try very hard not to use them as a state store for application-level data. I kind of think I would still say the same thing about inputs as I would about regular HTML elements -- input elements are for your users, they're not for you. They're not your interface, they're just the way your users communicate with you.