[HN Gopher] Facebook just updated its relationship status with W...
___________________________________________________________________
Facebook just updated its relationship status with Web Components
Author : mmcclure
Score : 76 points
Date : 2024-05-07 17:38 UTC (5 hours ago)
(HTM) web link (www.mux.com)
(TXT) w3m dump (www.mux.com)
| j-bos wrote:
| 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 wrote:
| I haven't used them. Why does "ad hoc fixing" require searching
| and boilerplate?
| toasted-subs wrote:
| 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.
| mmcclure wrote:
| I'm not following, what makes a poorly written React component
| better than a poorly written web component?
| j-bos wrote:
| When your company requires using them, it's more
| straightforward adjust the styles and event handling of a
| react component than a web component.
| dylanjha wrote:
| (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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 :)
| dylanjha wrote:
| Yeah, worth noting that there IS an escape hatch for
| monkey-patching (at your own risk). So you're not totally
| out of luck. It is just HTMLElement all the way down
| toasted-subs wrote:
| 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.
| deergomoo wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| dylanjha wrote:
| Styling components nested inside other components can
| still work with either slots or scoping CSS custom
| properties with parent selectors.
|
| .login-form { --button-outline-width: 2px; }
|
| .credit-card-form { --button-outline-width: 2px; }
|
| Of course, the component needs to be authored &
| documented in a way that supports this.
|
| For example, shoelace has a "Drawer" component:
| https://shoelace.style/components/drawer
|
| By default the drawer component has an "X" button in the
| header to close it. If you want to override that, instead
| of trying to style the nested "X" button you can pass in
| your own header actions with slot="header-actions"
| j-bos wrote:
| Yes, that hits the nail on the head, the tension between
| encapsulation and access.
| danielrhodes wrote:
| It seems like Web Components are ideal for libraries shipping
| pre-built components, which is probably why Mux finds it
| compelling. From Mux's point of view, they want the highest level
| of compatibility with the least amount of framework lock-in. For
| example, they don't want to have to ship a library for React and
| another one for Vue and another one for bare bones JS/HTML.
|
| In terms of building a web app where you control the environment
| end-to-end, I don't think there's any inherent upside to using
| Web Components over React.
| dylanjha wrote:
| (author from Mux here) -- that is correct. For the stuff we
| build for in-house use on mux.com and dashboard.mux.com we have
| a components library written in React.
|
| You nailed it that we are shipping SDKs with visual components
| (like a video player) that need to be compatible across all
| kinds of frontends.
|
| Instead of N number of SDKs to maintain where N is every front
| end framework, we have 2: a web component, and a React wrapper
| around the web component. Maybe in the (near) future we only
| have to maintain 1.
| davekiss wrote:
| The good: this seems like a necessary step towards standards-
| based development
|
| The worrying: we might be setting up for a scenario where newer
| developers are bewildered by mixed paradigms within what was (at
| least once upon a time) a simple library
|
| Full disclosure I work for Mux (OP), so as a team we're web
| component fans, but I'm personally still almost exclusively
| writing React. So...personally, saying this with love, but add
| this to all the new esoteric hooks in React 19 and it feels like
| React might be losing the plot.
| CharlesW wrote:
| Interesting. As a not-React user, it feels like a very positive
| thing that the framework is keeping up with alternatives like
| Vue (https://vuejs.org/guide/extras/web-components) and Svelte
| (https://svelte.dev/docs/custom-elements-api) in terms of
| standards support.
| the_real_cher wrote:
| Im not a front end dev but from what Ive read it seems like ES6
| and native web components solve a lot of the problems react was
| originally trying to solve.
|
| So is react losing the plot or just naturally it's ideas are
| being folded into the browser natively?
| sesm wrote:
| The number 1 problem React was created to solve is
| synchronizing state with UI (FB chat originally). Web
| Components don't provide any solution to this problem.
| troupo wrote:
| > this seems like a necessary step towards standards-based
| development
|
| Which standards?
|
| I keep saying: even web components people finally admitted that
| they need 20 more standards to solve issues (largely caused by
| web components themselves) that literally no other framework
| has: https://w3c.github.io/webcomponents-cg/2022.html
|
| There's a reason very few frameworks (including the new ones)
| target web components by default and do their own thing. And
| their authors have been very clear as to why (think Svelte,
| Vue, Solid etc.).
| dbbk wrote:
| In 18 years I have never once actually used a Web Component. What
| is the point?
| dylanjha wrote:
| Not everyone has to use everything.
|
| In my 13 years there are a lot of technologies I've never used.
| Maybe there was opportunities where you could have, or maybe
| things are working just fine for the problems you're solving
| and you don't need it, which is fine too.
| daxfohl wrote:
| Embrace, extend, extinguish?
___________________________________________________________________
(page generated 2024-05-07 23:00 UTC)