4 ms·

Having worked with internal company web components, I despise them. In a bureaucracy, bad and buggy web components are a blight because, unlike a bad React comp

by j-bos 2y ago

Having worked with internal company web components, I despise them. In a bureaucracy, bad and buggy web components are a blight because, unlike a bad React component,ad hoc fixing them requires a mess of searching and tons of boilerplate. I accept this news with mourning.

kristiandupont 2y ago
I haven't used them. Why does "ad hoc fixing" require searching and boilerplate?
- toasted-subs 2y ago
  It shouldn't there's a lot of ways to use web components anyone with years of experience with objective programming should feel extremely at home. Where as react requires a lot of unnecessary overhead associated with security risks.
  - kristiandupont 2y ago
    >Where as react requires a lot of unnecessary overhead associated with security risks. Such as what?
mmcclure 2y ago
I'm not following, what makes a poorly written React component better than a poorly written web component?
- j-bos 2y ago
  When your company requires using them, it's more straightforward adjust the styles and event handling of a react component than a web component.
toasted-subs 2y ago
Oh please. If we are going to complain about anything free and built into the standard it would be server side events which barely work at best. Personally I wouldn't mind server rendered features like what react does but in the setting of not javascript.
dylanjha 2y ago
(author here) I think the problem might be more around bureaucracy mixed with bad & buggy code than it is a specific problem with web components. Can you expand on that?
- j-bos 2y ago
  Thanks, I think you're 100% right, it's the red tape more than the tech. My issue is that when an in house React component is poorly coded, it's trivial to inject css overrides or select internal elements of the component to change it's behavior. With web components, the events emitted are locked in, each sub element or worse sub web component is nested away and only accessible via the shadow dom making edge case or hot fix solutions that much more trouble to deal with. In both cases the ideal would be for the internal library maintainers to fix the issues or support the required features, but with ever long lead times, it's often necessary to work something out at the project level. The working out is much more abrasive with web components though. In practice, this update is great for usability. But it's a sign that web components are still relevant, extending my time dealing with poorly built ones.
  - dylanjha 2y ago
    I see. Particularly with CSS there's more of an enforced contract around how the element internals get exposed for styling. If the element hasn't exposed `parts` or slots it's hard to hack around it. More broadly speaking I have found myself getting thrashed by the ever evolving "best practices" in the React ecosystem. First: write everything using class components, and then a couple years later everything should be written with hooks. I think the benefit of web components (for certain things) is that the APIs and the standards move slowly. Something you write today isn't going to feel obsolete in only a couple years.
  - mst 2y ago
    > select internal elements of the component If you need an equivalent Expedient Field Hack for a web component, remember it's an HTMLElement subclass and ends up in the DOM. So you can get the object back out of the DOM as 'just another internal element' and gutwrench it from there (or, depending, subclass it and register your subclass, or insert an extra entry into its prototype chain, or ...). I mean, yes, those are all horrible, but so's digging into the guts of a react component you don't own, sometimes taking a dependency on the internals of somebody else's code is the least horrible option. ... it occurs to me that given a JS Function's .toString() returns the source code, on an e.g. lit-html component you could probably even grab the render function, yank the html`...` call out of it, regexp that to tweak the mark up, and then use an indirect eval to stuff it back in. But really, I think "you now have the element object, monkey patch it to taste" is probably quite sufficient and far, far less ridiculous than that last paragraph, I just couldn't resist sharing the horrifying thought :)
deergomoo 2y ago
I love the idea of web components, I just wish slots weren't tied to shadow DOM. Anecdotally it feels like they arrived right as headless/self-styled component libraries started to pick up steam, and things inverted to the point that not being able to have your "external" styles easily apply to the component became more of a problem than them being affected by random stray styles.
- fidotron 2y ago
  Maybe I am missing what you mean, but I think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components. I wonder if that is the true reason OLE type systems have failed on the web, as there aren’t enough agreed upon preexisting widgets for it not to descend into an inconsistent horror show.
  - dylanjha 2y ago
    > think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components This is the inherent tension. It requires good web component authoring to expose: 1. `part`s that can be accessed by application-level CSS 2. slots for the application developer to inject html 3. CSS custom properties (--variable) -- these pierce the shadow DOM The web component authors have to be very intentional about these things. There are good examples and bad examples and I think people are still learning how to do this well.
    - fidotron 2y ago
      Isn’t the problem that this is recursive? i.e. if you use a component which itself contains a component that contains a button and that button should be styled should the intermediate components be worrying about it? And does the end consuming application need to care when new widgets are added to components nested two deep? It is almost like the need for styling necessitates all the old dependency injection and factory gunk that older frameworks became notorious for.
bobby_table 2y ago
Having worked with both internal company web components and internal company jquery-based components, I vastly prefer the former. Yes, ad-hoc fixing styles and behavior from the outside is nice. But when every internal style/class/element is technically part of the API surface, you quickly end up with extremely brittle code. Suddenly every tiny change (bug fixes, refactors, new feature) in the component library has the potential to break the app in unexpected ways, and the result is an inability to upgrade. Happens all the time. With shadow DOM, this problem basically go away (depending on how it’s implemented)
wordofx 2y ago
I would rather take web components than deal with react any day of the week. Never seen a good react implementation. The only issue with web components is shadow dom makes styling a pain so you need to work without the shadow dom and implement slots yourself.
CornCobs 2y ago
I'm in a similar boat. I have to use a 3rd party component library written in web components for our react app (esri/calcite-components) and it's a huge pain because * You can't override styles except what is exposed through css variables * They often encapsulate some internal logic which I can't control from React (tbh this could happen with a React library too)

by j-bos 2y ago

kristiandupont 2y ago

I haven't used them. Why does "ad hoc fixing" require searching and boilerplate?

toasted-subs 2y ago
It shouldn't there's a lot of ways to use web components anyone with years of experience with objective programming should feel extremely at home. Where as react requires a lot of unnecessary overhead associated with security risks.
- kristiandupont 2y ago
  >Where as react requires a lot of unnecessary overhead associated with security risks. Such as what?

mmcclure 2y ago

I'm not following, what makes a poorly written React component better than a poorly written web component?

j-bos 2y ago
When your company requires using them, it's more straightforward adjust the styles and event handling of a react component than a web component.

toasted-subs 2y ago

Oh please. If we are going to complain about anything free and built into the standard it would be server side events which barely work at best. Personally I wouldn't mind server rendered features like what react does but in the setting of not javascript.

dylanjha 2y ago

(author here) I think the problem might be more around bureaucracy mixed with bad & buggy code than it is a specific problem with web components. Can you expand on that?

j-bos 2y ago
Thanks, I think you're 100% right, it's the red tape more than the tech. My issue is that when an in house React component is poorly coded, it's trivial to inject css overrides or select internal elements of the component to change it's behavior. With web components, the events emitted are locked in, each sub element or worse sub web component is nested away and only accessible via the shadow dom making edge case or hot fix solutions that much more trouble to deal with. In both cases the ideal would be for the internal library maintainers to fix the issues or support the required features, but with ever long lead times, it's often necessary to work something out at the project level. The working out is much more abrasive with web components though. In practice, this update is great for usability. But it's a sign that web components are still relevant, extending my time dealing with poorly built ones.
- dylanjha 2y ago
  I see. Particularly with CSS there's more of an enforced contract around how the element internals get exposed for styling. If the element hasn't exposed `parts` or slots it's hard to hack around it. More broadly speaking I have found myself getting thrashed by the ever evolving "best practices" in the React ecosystem. First: write everything using class components, and then a couple years later everything should be written with hooks. I think the benefit of web components (for certain things) is that the APIs and the standards move slowly. Something you write today isn't going to feel obsolete in only a couple years.
- mst 2y ago
  > select internal elements of the component If you need an equivalent Expedient Field Hack for a web component, remember it's an HTMLElement subclass and ends up in the DOM. So you can get the object back out of the DOM as 'just another internal element' and gutwrench it from there (or, depending, subclass it and register your subclass, or insert an extra entry into its prototype chain, or ...). I mean, yes, those are all horrible, but so's digging into the guts of a react component you don't own, sometimes taking a dependency on the internals of somebody else's code is the least horrible option. ... it occurs to me that given a JS Function's .toString() returns the source code, on an e.g. lit-html component you could probably even grab the render function, yank the html`...` call out of it, regexp that to tweak the mark up, and then use an indirect eval to stuff it back in. But really, I think "you now have the element object, monkey patch it to taste" is probably quite sufficient and far, far less ridiculous than that last paragraph, I just couldn't resist sharing the horrifying thought :)

deergomoo 2y ago

I love the idea of web components, I just wish slots weren't tied to shadow DOM. Anecdotally it feels like they arrived right as headless/self-styled component libraries started to pick up steam, and things inverted to the point that not being able to have your "external" styles easily apply to the component became more of a problem than them being affected by random stray styles.

fidotron 2y ago
Maybe I am missing what you mean, but I think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components. I wonder if that is the true reason OLE type systems have failed on the web, as there aren’t enough agreed upon preexisting widgets for it not to descend into an inconsistent horror show.
- dylanjha 2y ago
  > think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components This is the inherent tension. It requires good web component authoring to expose: 1. `part`s that can be accessed by application-level CSS 2. slots for the application developer to inject html 3. CSS custom properties (--variable) -- these pierce the shadow DOM The web component authors have to be very intentional about these things. There are good examples and bad examples and I think people are still learning how to do this well.
  - fidotron 2y ago
    Isn’t the problem that this is recursive? i.e. if you use a component which itself contains a component that contains a button and that button should be styled should the intermediate components be worrying about it? And does the end consuming application need to care when new widgets are added to components nested two deep? It is almost like the need for styling necessitates all the old dependency injection and factory gunk that older frameworks became notorious for.

bobby_table 2y ago

Having worked with both internal company web components and internal company jquery-based components, I vastly prefer the former. Yes, ad-hoc fixing styles and behavior from the outside is nice. But when every internal style/class/element is technically part of the API surface, you quickly end up with extremely brittle code. Suddenly every tiny change (bug fixes, refactors, new feature) in the component library has the potential to break the app in unexpected ways, and the result is an inability to upgrade. Happens all the time. With shadow DOM, this problem basically go away (depending on how it’s implemented)

wordofx 2y ago

I would rather take web components than deal with react any day of the week. Never seen a good react implementation. The only issue with web components is shadow dom makes styling a pain so you need to work without the shadow dom and implement slots yourself.

CornCobs 2y ago

I'm in a similar boat. I have to use a 3rd party component library written in web components for our react app (esri/calcite-components) and it's a huge pain because * You can't override styles except what is exposed through css variables * They often encapsulate some internal logic which I can't control from React (tbh this could happen with a React library too)