[HN Gopher] If Web Components are so great, why am I not using t...
___________________________________________________________________
If Web Components are so great, why am I not using them?
Author : emegeve83
Score : 26 points
Date : 2023-08-02 20:13 UTC (2 hours ago)
(HTM) web link (daverupert.com)
(TXT) w3m dump (daverupert.com)
| [deleted]
| andrewmcwatters wrote:
| Because React is good enough. I think that's mostly why.
|
| Here's legacy React's like_button.js, without JSX, from their old
| documentation: 'use strict'; const
| e = React.createElement; class LikeButton extends
| React.Component { constructor(props) {
| super(props); this.state = { liked: false };
| } render() { if (this.state.liked) {
| return 'You liked this.'; } return
| e( 'button', { onClick: () =>
| this.setState({ liked: true }) }, 'Like'
| ); } } const domContainer =
| document.querySelector('#like_button_container'); const
| root = ReactDOM.createRoot(domContainer);
| root.render(e(LikeButton));
|
| Here's the equivalent using the Web Components specification[1]:
| // https://developer.mozilla.org/en-
| US/docs/Web/API/Web_components/Using_custom_elements //
| Create a class for the element class LikeButton extends
| HTMLElement { static get observedAttributes() { return
| ['liked']; } constructor() { // Always
| call super first in constructor super();
| this.liked = false; // Create a shadow root
| /* const shadow = */ this.attachShadow({mode: 'open'});
| } get liked() { return this.hasAttribute('liked');
| } set liked(state) { this.toggleAttribute('liked',
| Boolean(state)); } attributeChangedCallback(name,
| oldValue, newValue) { this.render(); }
| connectedCallback() { this.render(); }
| render() { const shadow = this.shadowRoot;
| if (this.liked) { shadow.innerHTML = 'You liked
| this.' return; }
| shadow.innerHTML = `<button onclick="this.parentNode.host.liked =
| true;"> Like </button>`; } }
| // Define the new element customElements.define('like-
| button', LikeButton);
|
| The React API is slightly nicer to use, especially with JSX.
|
| [1]: https://github.com/andrewmcwatters/custom-elements
| tailspin2019 wrote:
| * * *
| 8chanAnon wrote:
| I have no idea what Web Components are or why I should care. Is
| that the problem?
| superkuh wrote:
| One part of web components is custom HTML elements which
| basically means HTML elements that mean nothing until
| javascript execution gives them meaning. You differentiate them
| from the normal HTML element naming by using hyphens in the
| names.
|
| When I go to a website and all I see if a bunch of blank gray
| boxes that means they're using web components. It encourages
| developers to not put the text or images in the HTML and
| instead to load them externally after the page is loaded with
| javascript. That's slow, brittle, and stupid for most web
| documents. It's the opposite of progressive enhancement that
| fails gracefully. _Web components just leave blank nothing that
| ruins accessibility for screen readers_.
| verisimilidude wrote:
| When you see this, it's a sign that someone built their web
| components with React/Angular/Vue on the brain.
|
| The tech is fine. You can achieve amazing progressive
| enhancement with web components by understanding and
| effectively using <template> and <slot>. However, many web
| component developers never learn this.
|
| The problem you're describing is a training/marketing issue,
| as discussed in the post.
| arcbyte wrote:
| The browsers really need to make it possible to use
| templates and slots without javascript at all. There's no
| reason I shouldn't be able to define and use a custom
| element using HTML alone.
|
| Until then I don't know if template and slot will take off.
| err4nt wrote:
| Author-defined custom HTML elements, with all of the behaviour
| and interactivity defined in a way the browser natively
| understands.
| cogman10 wrote:
| Nope, not a problem. Because webcomponets fix a problem that
| nobody is having in a way that basically only benefits angular.
|
| They are strong encapsulation around a user defined component.
| So if you wanted to, for example, lock down the styling on your
| widget, you can! (hurray?)
|
| My cynical thoughts of why google pushes this is because it's
| another route to get in front of adblock. Make an ad component
| and now it's a lot harder for an addon to change or remove that
| component (and easier for the website to detect when that
| happens).
| err4nt wrote:
| Even though I've never used Angular, and do not build web
| apps at all, we have put custom HTML elements to great use at
| work. It's also not about locking down styling, but it's a
| neat way to package up _functionality_ and behaviour that
| otherwise would be just defined ad-hoc in JavaScript, and to
| provide a dead simple way to (re)use that functionality in a
| declarative way from HTML.
| pariahHN wrote:
| Similar experience, it makes it easy to integrate
| components into partner pages because they can treat it
| just like any other HTML element and we don't have to worry
| about the vast majority of possible namespace conflicts
| thanks to the shadow DOM.
| cogman10 wrote:
| Right, and that is a separate tech from web components.
| React, for example, does not use web components yet does
| exactly what you are describing.
|
| The problem web components is solving is just the strong
| encapsulation. Closing the escape hatches as it were.
| _jal wrote:
| If you default to js off, you'll spot them quickly.
|
| I generally just head to the next site on my list/search
| results.
| slibhb wrote:
| Web components fill an important niche: creating a library of
| components that can be easily used in react, angular, some other
| framework, no framework, or some framework that someone will
| invent next year. I expect their usage to increase over time.
| gochi wrote:
| I feel the opposite. I feel web components will hit the ceiling
| far faster due to the reduced churn and because their use case
| isn't all that applicable to most. Also why we see that a lot
| of the adoption of WC comes from major organizations with heavy
| design systems, those who do need to make components work
| across frameworks due to internal separation. Whereas most
| smaller teams or solo developers won't be involving themselves
| in that process at all.
|
| It's a solid stable niche, not a growth kind of niche.
| nektro wrote:
| good article except for the firefox shade
| btreecat wrote:
| I thought so too, and tried to dig into the specifics.
|
| I ended up here:
|
| https://hacks.mozilla.org/2014/12/mozilla-and-web-components...
|
| And left very unsatisfied that this is the current answer, only
| because I'd like to better understand how the use of JS modules
| over time has played out wrt html imports.
| Rodeoclash wrote:
| I wouldn't mind a sanity check on using Web Components in this
| context:
|
| We have a bunch of sites written in different frameworks (React,
| Rails + Hotwire, Phoenix + Liveview) that we'd like to have a
| shared set _visual_ components between them. Think things like:
|
| - Buttons - Text spacing - Layout cards - Headers
|
| Pretty low level stuff, the most dynamic behaviour might be
| something like showing / hiding content in an FAQ.
|
| Web Components seems like a reasonable fit to encapsulate the
| design elements and reuse them across all these different
| frameworks (probably coupled with Tailwind CSS on each site to
| enforce consistent colours + spacing).
___________________________________________________________________
(page generated 2023-08-02 23:00 UTC)