3 ms·

Web Components solve a number of problems with other component libraries such as React. React components are brittle. The brittleness comes from the global nat

Web Components solve a number of problems with other component libraries such as React. React components are brittle. The brittleness comes from the global nature of HTML, CSS, and JS. The DOM tree inside a React component isn't encapsulated from the rest of the page. This lack of encapsulation means your document stylesheet might accidentally apply to parts inside the widget; your JavaScript might accidentally modify parts inside the widget; your IDs might overlap with IDs inside the component; and so on. This means React components cannot be safely reused. Web Components solve this problem. What's more, you can use JSX with Web Components (to implement Web Components as well as to use Web Components). See here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder

catpolice 9y ago
I was really pumped about Web Components at first, largely because this sort of argument made a lot of sense to me. A few years on, I'm a lot less convinced that these are the problems that need to be solved. Element IDs, for example, are useful if you're doing a kind of old-fashioned select-and-mutate approach to DOM management. But if you're using React idiomatically, you're never running query selectors or ever reading from the DOM at all (modulo trivial things like getClientHeight in lifecycle methods). It's hard to imagine when you'd have an ID conflict with React because it's hard to imagine when you'd need an ID. Similarly, over the past few years I've had maybe two or three cases where CSS leaks due to under-encapsulation were a problem, and I was able to pick up on them and solve them with very little effort. Over the same period I've devoted much, much more effort to solving problems with over-encapsulation in cases where I needed to style a supposedly reusable component but some clever attempt at encapsulation (e.g. inline styling) prevented me from doing so and forced me to do a lot of work or re-implement the component wholesale. I've known a few projects that were excited about things like Shadow DOM and went through a lot of work to incorporate them only to end up stripping them out (see Atom: http://blog.atom.io/2016/11/14/removing-shadow-dom-boundary-from-text-editor-elements.html http://blog.atom.io/2016/11/14/removing-shadow-dom-boundary-...) for related reasons. So at this point I see a lot of the touted benefits to things like Web Components as a potentially painful set of solutions to a set of problems I've never really had. I don't really get it, but maybe they scratch some itch I don't have.
- interlocutor 9y ago
  Here's an example of why you need IDs: https://stackoverflow.com/questions/29420835/how-to-generate-unique-ids-for-form-labels-in-react https://stackoverflow.com/questions/29420835/how-to-generate... CSS name clashes are an issue if you have to incorporate independently developed React components.
  - catpolice 9y ago
    I guess I'm not saying that there aren't conceivable situations where you'd need an ID - it's just that they're typically small issues that are easily worked around. A duplicated "for" attribute problem is going to come up when you have two forms on a page and both of them use labels in this way and use conflicting IDs. There's a potential collision, but it's relatively easy to foresee and prevent, I've never seen it come up in practice and the worst outcome when it goes wrong would be something like the user's input focus going somewhere unexpected if they click a label instead of a control. W.r.t. CSS name clashes, yeah they can come up especially in the contexts of independently developed React components. But in my experience over-encapsulation comes up far more often in the same context. I'm almost never in a situation where I want to slot a component in as-is. Instead, I want some find grained control over its styling or behavior, and if that's hidden behind an encapsulation barrier, that makes re-use even harder. I do think the React component paradigm has some issues, but IMO they're the same sort of issues that come up in a lot of OO designs where abstraction and encapsulation happen in the wrong places. I still feel like Web Components solves some re-use problems I rarely if ever see in practice while doubling down on ones that I do.

catpolice 9y ago

I was really pumped about Web Components at first, largely because this sort of argument made a lot of sense to me. A few years on, I'm a lot less convinced that these are the problems that need to be solved. Element IDs, for example, are useful if you're doing a kind of old-fashioned select-and-mutate approach to DOM management. But if you're using React idiomatically, you're never running query selectors or ever reading from the DOM at all (modulo trivial things like getClientHeight in lifecycle methods). It's hard to imagine when you'd have an ID conflict with React because it's hard to imagine when you'd need an ID. Similarly, over the past few years I've had maybe two or three cases where CSS leaks due to under-encapsulation were a problem, and I was able to pick up on them and solve them with very little effort. Over the same period I've devoted much, much more effort to solving problems with over-encapsulation in cases where I needed to style a supposedly reusable component but some clever attempt at encapsulation (e.g. inline styling) prevented me from doing so and forced me to do a lot of work or re-implement the component wholesale. I've known a few projects that were excited about things like Shadow DOM and went through a lot of work to incorporate them only to end up stripping them out (see Atom: http://blog.atom.io/2016/11/14/removing-shadow-dom-boundary-from-text-editor-elements.html http://blog.atom.io/2016/11/14/removing-shadow-dom-boundary-...) for related reasons. So at this point I see a lot of the touted benefits to things like Web Components as a potentially painful set of solutions to a set of problems I've never really had. I don't really get it, but maybe they scratch some itch I don't have.

interlocutor 9y ago
Here's an example of why you need IDs: https://stackoverflow.com/questions/29420835/how-to-generate-unique-ids-for-form-labels-in-react https://stackoverflow.com/questions/29420835/how-to-generate... CSS name clashes are an issue if you have to incorporate independently developed React components.
- catpolice 9y ago
  I guess I'm not saying that there aren't conceivable situations where you'd need an ID - it's just that they're typically small issues that are easily worked around. A duplicated "for" attribute problem is going to come up when you have two forms on a page and both of them use labels in this way and use conflicting IDs. There's a potential collision, but it's relatively easy to foresee and prevent, I've never seen it come up in practice and the worst outcome when it goes wrong would be something like the user's input focus going somewhere unexpected if they click a label instead of a control. W.r.t. CSS name clashes, yeah they can come up especially in the contexts of independently developed React components. But in my experience over-encapsulation comes up far more often in the same context. I'm almost never in a situation where I want to slot a component in as-is. Instead, I want some find grained control over its styling or behavior, and if that's hidden behind an encapsulation barrier, that makes re-use even harder. I do think the React component paradigm has some issues, but IMO they're the same sort of issues that come up in a lot of OO designs where abstraction and encapsulation happen in the wrong places. I still feel like Web Components solves some re-use problems I rarely if ever see in practice while doubling down on ones that I do.