18 ms·

If Web Components are so great, why am I not using them?

195 points by emegeve83 3y ago

8chanAnon 3y ago
I have no idea what Web Components are or why I should care. Is that the problem?
- superkuh 3y ago
  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 3y ago
    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 3y ago
      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.
      - no_wizard 3y ago
        This is what everyone in userland clamors for as a baseline. Decade plus old arguments about this. I have little hope this will happen
      - verisimilidude 3y ago
        Fully agreed.
      - lenkite 3y ago
        We had HTML imports and they got rid of it. No JS means No Ads.
        no_wizard 3y ago
        It means less invasive tracking really, not no ads. Ironically it was Firefox that killed it, not Google. Google was all in on HTML imports. It would have also given a non JS way to dynamically load HTML. Streaming would have been great with this.
        adjav 3y ago
        HTML imports required JS to be used - otherwise all you had was a `link`ed DOM tree that you couldn't access. No one has really proposed a way to dynamically load anything without JS AFAIK.
  - dmazzoni 3y ago
    FWIW, all the major screen readers fully support JavaScript. There's nothing inherently inaccessible about a website that uses JavaScript. In fact, the screen readers don't actually interpret the JavaScript at all - they just react to the page dynamically changing, it doesn't matter how it's accomplished.
    - superkuh 3y ago
      There's nothing inherent no, just that javascript webpages, if some CDN doesn't load fast enough, or the dev uses some bleeding edge function not in all browsers, etc, will not end up having the text in the page. Whereas actually having the text in the page always has the text in the page. JS sites almost always fail very badly when it fails (a relatively common event). Text sites cannot fail even when they fail.
- cogman10 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
      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.
      - err4nt 3y ago
        HTML is supported natively in the browser, and custom HTML elements and their properties work at the same level as all other HTML elements as far as JavaScript, DOM, and dev tools are concerned. React, while it may provide similar functionality to the programmer, is not natively understood, and while it can run in browsers, the 'components' in React are not handled in the same way in the browser as native HTML elements, JavaScript and its APIs don't know about them as HTML elements, DOM isn't aware of them (only their parts), and dev tools can't offer much insight because the app that's running is an unpredictable black-box to the browser.
- err4nt 3y ago
  Author-defined custom HTML elements, with all of the behaviour and interactivity defined in a way the browser natively understands.
- _jal 3y ago
  If you default to js off, you'll spot them quickly. I generally just head to the next site on my list/search results.
deleted 3y ago
[deleted]
andrewmcwatters 3y ago
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 https://github.com/andrewmcwatters/custom-elements
- tailspin2019 3y ago
  The latter doesn’t have any dependencies or a build step though right? That’s a big win that can be easily overlooked. But it depends what you’re optimising for…
  - eropple 3y ago
    I don't know many (any?) people who are greenfielding just-JavaScript, though. If you're using JavaScript in anger, you should probably be using TypeScript, and now you've got a build step regardless. Which is not a bad thing. Incremental builds have gotten much better and much easier to deal with.
slibhb 3y ago
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 3y ago
  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.
- dmix 3y ago
  Modern JS frameworks are heavily mixing mostly static with limited amounts of interactive components but all in one system. Where everything can still be the same component architecture, the same UI systems, same CSS/JS packages, same build systems, etc but you selectively choose which components (or small sections of a page) are interactive and require hydration. I don't really see how Web components fill that picture as cleanly. You would basically still forced to choose between component overhead/custom code OR static HTML, creating a formal discintion rather than a boolean or flag or whatever. Why create that distinction just because it's "native" to the browser? The DOM is sufficient when your default is static and components are always SSR in the same DOM model. It basically only makes sense if you're not building a "holistic" single frontend framework driven site and rather are mixing various server side view systems and occasionally adding a couple components. Basically the sort of thing better suited for major legacy sites like Google rather than something you'd ever choose from the ground up.
- no_wizard 3y ago
  This is a half truth. Their are big problems with this approach, as I think a lot of folks are finding out the hard way, namely: - You cede rendering control from your framework to the web component, if it does anything like conditional children etc. meaning it can be hard to optimize or you get stuck using refs, which is suboptimal and in some frameworks makes optimizations hard to achieve - it’s de facto CSS in JS and to boot your styles are also locked to shadow dom. Yes I know this isn’t true in an absolute sense but in practice all the web component implementations leverage this. This makes styling harder, can have performance impacts etc. also means you can’t leverage CDN caching and distribution for your styles - FOUC is a real problem with web components as it exists today. - Interop varies and can have gotchas, especially with custom events that may be emitted by components - You can’t get fine grained optimizations in some frameworks using them because web components in practice often contain some kind of logic one way or another. - to use slot you must use shadow dom, and that means your app needs to be rendering against a shadow root of some sort, which can be real clunky
nektro 3y ago
good article except for the firefox shade
- btreecat 3y ago
  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/ 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.
  - WorldMaker 3y ago
    Things like HTML (and JSON) imports in ES modules, among other things, have been waiting on some safety signalling mechanics currently named "Import Attributes". Import Attributes are currently in Stage 3 [0]. The basic security story is that browsers never care about file extensions, they care about MIME types. A developer might add an import to a third-party HTML or JSON file somewhere and expect one "safe" behavior, but the third-party could just return a MIME type of "text/javascript" and inject an entire script and the browser is supposed to respect that MIME type. To keep things safe, browsers want a way to signal that an import is supposed to JSON (or HTML or CSS) rather than JS and error if it gets back something "wrong" from a server request. That's one of the proposed uses for Import Attributes to suggest expected MIME types for non-JS modules in ES module imports. Unfortunately, there are other proposed uses for Import Attributes (things like including hashes for integrity checks) and so there have been quite a few revisions (and multiple names) for Import Attributes trying to best support as many of the proposed uses as possible, and that has slowed progress on it a lot more than some people would wish. [0] https://github.com/tc39/proposal-import-attributes https://github.com/tc39/proposal-import-attributes
    - btreecat 3y ago
      Thank you, interesting!
- brianzelip 3y ago
Rodeoclash 3y ago
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).
- qbasic_forever 3y ago
  Web components are really only useful for stuff that's dynamic, like a sortable table that fetches data from an AJAX request. They require javascript and have no fallback or graceful degradation in functionality at all, which means using web components for all your bog standard buttons, text content, headers, etc. could be a very bad idea (not to mention it would trash the SEO and potentially accessibility of your site). IMHO you probably want to look at design tokens or other ways to centralize your visual styles--it's really more of a workflow problem and not just something to throw more javascript at with web components.
  - throwawaymaths 3y ago
    > we'd like to have a shared set visual components between them I think what gp wants is css!
    - Rodeoclash 3y ago
      Well, ideally css which belongs to the component that is using it. CSS modules and other encapsulation techniques have been pretty beneficial. I'd like to keep that going vs. trying to manage the "cascading" part of stylesheets over multiple sites.
  - verisimilidude 3y ago
    > They require javascript and have no fallback or graceful degradation in functionality at all This is false. Use <template> and <slot>. First-class progressive enhancement.
dxchester 3y ago
The main reason is that they're too low-level to use directly. They do a lot, but stop just short of being useful without something of a framework on top. I tried hard to use them directly, but found that it was untenable without sensible template interpolation, and without helpers for event binding. Here's my shot at the smallest possible "framework" atop Web Components that make them workable (and even enjoyable) as an application developer: https://github.com/dchester/yhtml https://github.com/dchester/yhtml It's just ~10 SLOC, admittedly dense, but which make a world of difference in terms of usability. With that in place, now you can write markup in a style not too dissimilar from React or Vue, like... <button @click="increment">${this.count}</button> Whereas without, you need to bind your own events and manage your own template interpolation with sanitizing, handling conditionals, loops, and all the rest. If we could get something in this direction adopted into the spec, it would open up a lot of use cases for Web Components that it just can't address as-is.
- throwaway14356 3y ago
  meanwhile Im like... <button onclick="innerHTML++">1</button>
  - deleted 3y ago
    [deleted]
  - jagged-chisel 3y ago
    GP comment shows a simple example, sure. And obviously it’s overkill just to implement incrementing a displayed value. But trivializing the example doesn’t reduce the “framework” to being pointless.
  - LudwigNagasena 3y ago
    Meanwhile I’m like… That’s a Content Security Policy violation.
    - throwaway14356 3y ago
      2 men are having lunch, one complaints that he always has cheese on his sandwiches. The other says, just ask your wife for something else? He responds: I always make it myself. Content-Security-Policy: script-src 'self'; script-src-attr 'unsafe-hashes' 'sha256-9lIp1merGZMC6sfoM+OcgpSSRJJr18teLzyFangr0FY='
herpdyderp 3y ago
I've been using web components now for years and I will do everything I can to never write frontends in anything else. I totally agree with point 2 though: the Polymer phase was very weird, but, as mentioned, https://lit.dev https://lit.dev is great and, imo, the perfect abstraction.
- benatkin 3y ago
  Lit seems functionally equivalent to Svelte. Might Lit only be better if you have a preference towards declaring classes? Perhaps tracing back to Backbone or React before hooks? Svelte supports custom elements: https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api
  - spankalee 3y ago
    Lit uses standard languages, doesn't require a compiler, is faster, and is smaller as you amortize the library size over a collection of elements. Those are real differences.
    - benatkin 3y ago
      > uses standard languages, doesn't require a compiler It recommends a build step, but yes, you can use it without one. Also, TypeScript isn't a standard language. So if you're using .ts you may as well use .svelte. > is faster I don't know that Svelte has been benchmarked with custom elements. Either way it's plenty fast. > is smaller as you amortize the library size over a collection of elements That's kind of a funny thing to worry about. It has improved in Svelte 4, though. https://svelte.dev/blog/svelte-4 https://svelte.dev/blog/svelte-4 I also don't know that Lit is so small in practice. With Lit you get to use map and the ternary operator and all that jazz, like React. https://lit.dev/docs/templates/conditionals/ https://lit.dev/docs/templates/conditionals/
    - phpnode 3y ago
      When did @click and so on become part of HTML?
  - 3y ago
benatkin 3y ago
The nice thing is that if you're using a library like Lit or Svelte, you won't have to bother with the web component API much at all. https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api https://lit.dev/ https://lit.dev/
afavour 3y ago
IMO the main reason more people aren’t using Web Components is because React doesn’t support them. Preact does it just fine so I have to assume it’s possible but simply not in the interests of the React team. React feels like the enterprise lock-in of 2020s development: if you use it you’re using it top to bottom and it’s very difficult to mix and match with other frameworks. It’s a shame.
- coldtea 3y ago
  Nobody (meaning very few) care for Web Components, React or not. Even in frameworks that do support them, they're just not widely used.
  - afavour 3y ago
    Web Components are just an API, a means to an end. You might as easily say nobody cares for document.createElement() but it’s still used by underlying code all the time. If it were much easier to mix and match components that use different frameworks then people would be using web components whether they know it or not. But we’re in a React monoculture and React folks seem quite content with that.
    - wokwokwok 3y ago
      mm... Web components aren't 'an' api, it's a specific way of using a set of apis, and specifically requires you to use a set of templates in a way that frameworks (which looovvvveeee DSLs) won't accept. The other bits? shadow dom? Custom elements? eh. Those are things a framework will wrap happily enough if they see value in it. Maybe some already do? As you say, you'd never know... ...but those html templates will never fly. They're just crazy bad ergonomics and framework authors will never accept them. That's really the core of the issue; invoking components in your layout requires you to use some kind of layout template, and every framework does it differently. That's why cross framework css solutions (eg. tailwind) are massively successful, because they can be called easily by anyone regardless of the templating; the same is not... and, frankly, seems like it never will, be true of web components.
    - 3y ago
briantakita 3y ago
Astrojs recommends a great way to initialize & light-weight hydrate the UI using web components & custom tags. https://docs.astro.build/en/guides/client-side-scripts/#pass-frontmatter-variables-to-scripts https://docs.astro.build/en/guides/client-side-scripts/#pass...
inopinatus 3y ago
I'm not using them because WebKit (i.e. Apple), in a long-standing vendor pissing contest¹ they've tunnel-vision'd themselves into, still refuses²³ to implement the customized built-in elements⁴ part of the standard, without which the content model for HTML cannot be fully realized (e.g. custom elements inside a table), and to make matters worse, without offering a firm proposal or implementation of an equivalent alternative. (and this is something a polyfill can only partially bridge) [1] https://github.com/WICG/webcomponents/issues/509#issuecomment-222860736 https://github.com/WICG/webcomponents/issues/509#issuecommen... [2] https://bugs.webkit.org/show_bug.cgi?id=182671 https://bugs.webkit.org/show_bug.cgi?id=182671 [3] https://github.com/WebKit/standards-positions/issues/97 https://github.com/WebKit/standards-positions/issues/97 [4] https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-customized-builtin-example https://html.spec.whatwg.org/multipage/custom-elements.html#...
- CharlesW 3y ago
  An apparent polyfill, FWIW: https://github.com/WebReflection/custom-elements-builtin https://github.com/WebReflection/custom-elements-builtin
- spankalee 3y ago
  Web components are extremely useful even without customized built-ins. And Apple is open to alternatives.
  - inopinatus 3y ago
    I don't disagree about the first part, but it is nevertheless the reason I'm not using them, since I have a very general use case (c.f. https://github.com/hotwired/turbo/pull/131 https://github.com/hotwired/turbo/pull/131). As for representing Apple's state of mind w.r.t. alternatives; they've had the better part of a decade to shit or get off the pot, so I don't hold a shred of vendor sympathy. In that context, "open to alternatives" just sounds like product manager code for "we have no ideas of our own" and "let's kick the can down the road as much as we possibly can". If anything riles me up, it's the disinterest in developing a substitute capability, and if Apple weren't a steward of the standard it'd matter far less. I'll compare & contrast Cisco's running battles over their own PoE vs the IEEE802.3 standards that they'd had a hand in developing; at least the vendor offered a concrete alternative.
riquito 3y ago
It's been a while, and overall I'd like them to succeed, but here are the first issues I remember. The fact that scoped elements are not yet part of the standard is quite a turn off. Every web component is global and the first one that uses a name wins. Even if you are not competing with third party libraries you will need to have multiple versions of your same component very soon to handle breaking changes. The string only passing is an headache when you'd like to pass object/functions to compare later on. The fact that some CSS properties can bleed in the shadow Dom, while others don't. To introduce them into an existing codebase you need support, and last time I checked the support from React was clunky
- djbusby 3y ago
  I've been able to piece-meal RiotJS components into an existing code base pretty easy. Tools like React, etc al, requires almost doing everything that way. RiotJS fits in for adding a bit to "old-school" web-apps (PHP, Ruby, Perl, ASP3). Legacy backend, slightly more modern frontend.
deleted 3y ago
[deleted]
yCombLinks 3y ago
Web components don't solve any of the problems day-to-day devs ACTUALLY care about.
- foderking 3y ago
  which are?
  - yCombLinks 3y ago
    Shipping features and bug fixes without a headache
- mock-possum 3y ago
  Encapsulation and ease of reusability / configuration? Just as an example - a widget to manage a list of number ranges. Build it up like a form element - it provides a value prop with the type ‘[number,number][]’ You need to display the current collection of min/max pairs, and add / remove / edit the collection - it’s essentially a mini CRUD component. There is no default html element that provides this functionality - you need an ordered list of pairs of number inputs, a confirm changes button, a ‘add new’ and ‘remove this entry’ button - you need a whole collection of stuff to provide the functionality. But once you’ve got it all worked out, wrap it in a web component and you can use it in 8 different places across your admin tool - ‘<ranges-picker />’ and boom, you’re ready to go. Using web components to define a library of common interface elements works just fine.
  - yCombLinks 3y ago
    Right, but react solves the problem as well with similar amount of effort, but everyone is already on react. So switching is cost with little perceived benefits
alserio 3y ago
I've found them really useful to do microfrontends
spankalee 3y ago
Web components are doing really well: they're used on > 18% of Chrome page views, huge apps like Photoshop, parts of Chrome, Chrome OS, and Firefox, more and more of Reddit, and tons of design systems are built with them, and Lit has far more weekly npm downloads than Svelte or Solid.
- pard68 3y ago
  We're a fairly large , publicly traded org that no one has ever heard of but almost everyone interacts with our products. All our frontend products are entirely web-components (Lit). I like them. Used stencil before this at another job and it was also just fine.
shams93 3y ago
You used to need a whole js build system because old browsers were still out there. With the death of IE11 and the death of non blink Edge, basically every current browser finally supports the full api. But this happened when functional js is the big thing and being class based the custom element api isn't as popular as it should be.
jchw 3y ago
I think Web Components added a lot of complexity to the web platform again and we're finally hitting the breaking point where it has gotten to be too much. I don't want to deal with web components or the shadow DOM. I don't want more abstractions in the browser at this point. On one hand, there are some use cases for this new complexity. On the other hand, it's difficult to see how the vast majority of say, React users, would ever benefit from this complexity, given that a lot of them don't seem to have problems that are solved by web components. If we were going to focus on adding even more new browser features, I think it'd be better to focus on stuff that helps close cross-site scripting vulnerabilities, or provide better approaches towards anti-SPAM/anti-abuse than lazy, harmful remote attestation. (I mean hell, I'd love to see some very basic hashcash functionality as part of the browser; Personally, I think that would be an interesting idea for anti-SPAM, and nowhere near as catastrophically harmful as WEI.)
- Falkon1313 3y ago
  I would agree and would rather they had spent more effort on adding support via standard HTML5 elements for more of the standard native form widgets like comboboxes, tree controls, grid controls, etc. - all those things that already exist on almost every platform but keep having to be reinvented in javascript for no good reason. Web Components mostly seem to be just adding complexity for the sake of avoiding simplicity. Certainly there could be some use for custom ones, just as you can make custom native widgets. But there shouldn't be that much need that often if more of the standard functionality was available (and standard). They did add color picker, date picker, range, and the datalist to kind of sort of emulate a combobox, so some credit for that. But unfortunately they're not consistent across browsers and may or may not be consistent with the native platform.
deleted 3y ago
[deleted]
taeric 3y ago
This article doesn't really follow the title? I was expecting some critique of existing software and why someone prefers alternatives. Instead, I got a list of excuses on why people haven't really looked at it. Not that any of the points are bad. As read, they all seem like solid reasons to not use something. Indeed, the fact that frameworks have no reason to use these over user space constructs seems very compelling, all on its own. The rest feels like a thinly veiled rewording of the second point? That is, this feels like advocacy that is blaming the messengers for not successfully convincing us that we should use this superior thing. Which... is still a heavy handed advocacy. :(
kerkeslager 3y ago
Frankly, web components aren't great. I am using them, because I've landed in a few projects where adding a JS build step is too heavyweight for very minimal JS needs. But here are my gripes: 1. Templates are way too complicated to be useful. I have no idea what they were thinking here. 2. The shadow DOM not inheriting styles means I effectively can't use the shadow DOM for anything useful. My ideal use case would be that I could child elements to the current component into the shadow DOM. This allows me to do (for example) things like have a <tab-area> where the user can define <tab-> child elements which in turn can contain arbitrary content: when the user selects a tab I copy the contents of the <tab-> tag into the shadow DOM so that that's what becomes visible. But if I do that, the element content becomes unstyled. There are a bunch of really useful elements that are just completely blocked by this poor design choice. As a result, I just don't use the shadow DOM, but then I have to mutate the tabs to make them visible in place, and that means changes to the HTML of tabs can potentially cause issues for my <tab-area> and vice versa. The first is a missed opportunity, but it's fairly easy to just not use them. The second problem is one of the worst API decisions I've ever seen, which would have been detected very quickly if anyone designing this API had been arsed to try to use their own API.
- jacob019 3y ago
  The shadow DOM can inherit styles if you specify the styles that you want to inherit. Additionally, web components work just fine without the shadow DOM, it's optional, but for a great many custom elements you don't want them inheriting all the styles, because that can break the custom element.
  - vanake 3y ago
    probably what GP meant there is now way to inherit styles without specifing which styles you want to inherit. There should option shadow dom inherit all styles.
  - webstrand 3y ago
    Without the shadow dom, though, what really is the difference from just using `<div>` elements? You can't use slots, you're vulnerable to bad `querySelector`s, events aren't isolated, and you get none of the performance benefits. I've tried to find a workable solution using style inheritance, but it doesn't work everywhere. On code sandbox sites like codepen.io, the stylesheet is generated for you and sometimes updated in-place. You'd have to watch with a MutationObserver and then propagate the change to every instance of a custom element on the page.
synergy20 3y ago
Because react.js, vue.js, angular all had their own version of components and they're the 'mainstream' frontend frameworks.
raggi 3y ago
I use custom elements directly in a bunch of stuff I had roll and I find the composition and reuse advantage nice. I tend to not bother with template elements, they don’t help much. I also don’t bother with shadow dom or element styles, as again, until you are making a mess with a distributed team you don’t actually have css problems. css also got a lot better at not causing problems, with fancier selectors and less problematic layout models. People say they’re slow, but things I’ve hand rolled this way, while none are super complex, I can make thousands of elements and not put a dent in any metrics or lighthouse runs. I tend to bind stuff I’m going to manipulate in the child tree to variables in the constructor, so I never really have the cost of constant lookups, which maybe amortizes well once you’re looking at whole program performance.
ilaksh 3y ago
There doesn't need to be a practical reason for something to not be popular. Popularity and merit are not the same thing. Web components aren't popular because they haven't become popular yet. There is a lack of sufficient network effect moving in that direction. Once they start becoming popular, the issues with them (which are relatively minor) will be resolved quickly and improvements added. Why are most of our cities and cars still designed with fundamentals basically the same as in the 1930s? Not because there aren't better designs. It's just momentum. High technology is like that still even though nothing physical needs to be changed. Humans are herd animals. And the rationalization for behavior comes after the behavior not before. We subconsciously copy what other people are doing. People use React or whatever flavor-of-the-month. Give it a couple of years and many of the flavor-of-the-month frameworks will probably be built on top of web components.
- sbergot 3y ago
  The design of cars has evolved a lot, mainly because of security regulations. Cities is another topic. They change slowly because of the required investment but in europe at least there is definitely a trend toward walkable blocks which changes a lot of urbanisation guidelines. I agree with your first sentence: things are unpopular by default. However I disagree with your assumption: web components won't become magically popular overtime without a good reason for them to be used over all the other options. Your "flavor-of-the-month" take ignores the fact that react is now 10 years old and is boring tech. It is still one of the most widely used frontend framework.
bastawhiz 3y ago
My hot take: they're a pain in the ass to use for very much. Compared to frameworks in userland, they're cumbersome and don't add value. Frameworks make other things better (besides the problems web components solve), making web components an implementation detail. If you're using React, you have no reason to consider web components. In my entire career, I've had one use case that web components were perfect for: framework agnostic component interfaces. I specced the use case for a product at Stripe [0] and it was wildly successful. What it solved was avoiding the need to ship a library for each framework to embed our components: you just used HTML. Web components are perfect for this, because they are the lowest common denominator that everyone supports. Even if you're not using a framework, you can still embed the components with no real effort. That's the best I can say about web components, though. [0] https://stripe.com/docs/connect/get-started-connect-embedded-components https://stripe.com/docs/connect/get-started-connect-embedded...
dmazzoni 3y ago
Web components have had accessibility gaps since the beginning. I spent years working on specs and implementations to close the gap, It's insanely frustrating just how slow standardization work can be. I'm partially relieved that web components never became that popular, because that would have made accessibility on the web worse.
kermire 3y ago
The main limitation of web components for me is that all data needs to be passed to the component attributes as strings. Wish we could pass objects and arrays without JSON.stringify-ing them.
_xivi 3y ago
I heard about web components a lot for years and was looking forward for an opportunity to try them. But for some reason, this is the first time I learn that it's completely reliant on JS. My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way. Instead, turns out it's doubling down on JS to create elements, and was actually targeted towards these framework in the first place.
- zelphirkalt 3y ago
  If I recall correctly, there was or is a web component concept or inplementation that does not originate frome those frameworks and I think I read about it on MDN or so. It is only that frontend devs push their frameworks so much, that most people associate web components with React and similar frameworks.
- reustle 3y ago
  > My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way. Curious what you feel defining a custom component in the browser would look like, if not with JS?
  - _xivi 3y ago
    Well, my impression was that it's a revolutionary hot technology that only recent browsers support. Something like the browser doing the "SSR" natively on the fly before rendering the page DOM. Anyway like I mentioned, I didn't get the chance to play with it and understand its purpose. Misconception -> higher expectations -> disappointment.
- xtracto 3y ago
  I read about web components a couple of years ago. What excited me was the prospect of having libraries of ready made UI elements that I could use. Those of us who programmed in say VB6 or .NET winforms back in the day may remember that you could purchase some "ready made" grid-table editor with lots of functionality and pretty. But I haven't seen that open source nor commercial. It's amazing how much the current web frontend dev have to reinvent over and over again.
fidgitkid 3y ago
[dead]
cientifico 3y ago
Google teached me over the years that they can deprecate or remove support from one day to another, and I don't matter to them, neither as user, developer, or company owner. So even if I love web components since it got released (and have used them in some toy apps) I can't count on them yet thanks to Google. You can't trust anything coming from Google. There is no assurance that they announce tomorrow that they remove support for them in chrome. Or even worse, they will remove support in 6 month (killing all the developers market and destroying any production app). To announce in 3 years that they will continue the effort of removing them... It's just sad. </Rant>
epolanski 3y ago
My experience why I use them less than I wish I did: they are really not plug and play in any website. There's plenty of css properties that pierce through the shadow dom.
zoom6628 3y ago
Too little too late. My bet is WASM being the Great Leap Forward because everything else that has been done in JavaScript is just layer on layer of abstraction, obfuscation and horrendous complexity. I would rather develop in a mature language and have that transpiled to WASM rather than fight the frameworks (I still remember when Angula 5 was a 15,000 file desktop mom install !). JavaScript has fulfilled an important role as the COBOL of the web. Low barrier to entry - anybody can do something useful without education or expense. Now the web needs move forward to become the first choice desktop. That will take tools that can really do the whole stack, like C, Go, Java, Zig, Virgil productively. Industry has been busy on the JS bandwagon and adding vast amounts of complexity to browsers and web infrastructure when maybe (happy for opinions to be voiced on this) we should be just adding more language runtimes to browsers.
- styren 3y ago
  How would WASM alleviate any of the issues that has led to complex frameworks in JS-land?
nathias 3y ago
I am currently in a process of rewriting the most monstrous frontend I've ever seen, it's written in Lit and web components. I don't recommend them to anyone, they are a relic and have failed to achieve their purpose, as now any code written in any of the popular frontend frameworks is much more interchangable than web components....
globalise83 3y ago
If you haven't tried Stencil.js, might be worth giving it a go. I found it a dream for working with web components since it takes care of almost all the tooling, bundling, code-splitting, etc. out of the box, and has full support for Typescript, TSX and React-style props.
sneas 3y ago
Four years ago, I found a small niche for a tiny project. Not that there were no solutions yet, but all the existing solutions lacked accessibility aspects, so I decided to develop my own, introducing the accessibility flavor [0]. The scope and limitations I had: - Should be framework-agnostic - Should require the minimum effort in installing - Should not conflict with anything on the page So, Web Component was the perfect candidate for the lib. The framework-less approach felt overwhelming, and lit-html smelled like Polymer. So, initially, I picked up Stencil. It is still fantastic for creating component libraries, but it happened to be overkill for a tiny component. So in a few years, I rewrote my WC without Stencil, and now it feels just right. I developed several more Web Components professionally in the past few years. I saw them as a perfect fit for the problems I had to solve. The scopes of problems were similar: - Should be framework-agnostic - Should require the minimum effort in installing - Should not conflict with anything on the page [0] https://github.com/sneas/img-comparison-slider https://github.com/sneas/img-comparison-slider
incrudible 3y ago
"Web Components are slow. The last thing that’s held Web Components back is that they’re slow… slow, like brisket I like to say. Slow isn’t always a bad thing." Yes it is, it is always a bad thing. It's not necessarily a dealbreaker, but it's never good or even neutral. I already have a mental model of the incredibly slow DOM, I don't need another dimension of performance cliffs to think about. Instead of more convoluted web standards, I want fewer, simpler and faster APIs - and may the best abstractions win.
reverseblade2 3y ago
Built with lit web components, and F# no shadow root https://funpizzashop.azurewebsites.net/ https://funpizzashop.azurewebsites.net/ Source: https://github.com/OnurGumus/FunPizzaShop https://github.com/OnurGumus/FunPizzaShop
nmalaguti 3y ago
> Kill Firefox before they could kill HTML Imports I’m not sure I understand the hostility here. Isn’t the point of the web to be open standards that reach consensus?
tsp 3y ago
I used Lit in a client project, which still seems to be the most common way to author web components. Styling and composition was really hard, much harder than in typical React, Vue or Svelte projects. It is future proof to build the atoms of a design system as web components (e.g. sliders, buttons and so on), but component composition is better done in a proper framework (e.g. Vue). This way companies could more easily start new projects with their existing design system, independent of the framework. I wouldn’t consider building a complex applications with Lit again, just the design system atoms.
dannye 3y ago
<textarea> <input> <video> ARE all Web Components, and have been for many moons so Browser vendors could implement their own UI. So everyone using a Browser *IS* using Web Components. It just took some years for the technology to be opened up with the Custom Elements API to us mortals here in Userland.

195 points by emegeve83 3y ago

8chanAnon 3y ago

I have no idea what Web Components are or why I should care. Is that the problem?

superkuh 3y ago
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 3y ago
  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 3y ago
    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.
    - no_wizard 3y ago
      This is what everyone in userland clamors for as a baseline. Decade plus old arguments about this. I have little hope this will happen
    - verisimilidude 3y ago
      Fully agreed.
    - lenkite 3y ago
      We had HTML imports and they got rid of it. No JS means No Ads.
      - no_wizard 3y ago
        It means less invasive tracking really, not no ads. Ironically it was Firefox that killed it, not Google. Google was all in on HTML imports. It would have also given a non JS way to dynamically load HTML. Streaming would have been great with this.
        adjav 3y ago
        HTML imports required JS to be used - otherwise all you had was a `link`ed DOM tree that you couldn't access. No one has really proposed a way to dynamically load anything without JS AFAIK.
- dmazzoni 3y ago
  FWIW, all the major screen readers fully support JavaScript. There's nothing inherently inaccessible about a website that uses JavaScript. In fact, the screen readers don't actually interpret the JavaScript at all - they just react to the page dynamically changing, it doesn't matter how it's accomplished.
  - superkuh 3y ago
    There's nothing inherent no, just that javascript webpages, if some CDN doesn't load fast enough, or the dev uses some bleeding edge function not in all browsers, etc, will not end up having the text in the page. Whereas actually having the text in the page always has the text in the page. JS sites almost always fail very badly when it fails (a relatively common event). Text sites cannot fail even when they fail.
cogman10 3y ago
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 3y ago
  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 3y ago
    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 3y ago
    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.
    - err4nt 3y ago
      HTML is supported natively in the browser, and custom HTML elements and their properties work at the same level as all other HTML elements as far as JavaScript, DOM, and dev tools are concerned. React, while it may provide similar functionality to the programmer, is not natively understood, and while it can run in browsers, the 'components' in React are not handled in the same way in the browser as native HTML elements, JavaScript and its APIs don't know about them as HTML elements, DOM isn't aware of them (only their parts), and dev tools can't offer much insight because the app that's running is an unpredictable black-box to the browser.
err4nt 3y ago
Author-defined custom HTML elements, with all of the behaviour and interactivity defined in a way the browser natively understands.
_jal 3y ago
If you default to js off, you'll spot them quickly. I generally just head to the next site on my list/search results.

deleted 3y ago

[deleted]

andrewmcwatters 3y ago

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 https://github.com/andrewmcwatters/custom-elements

tailspin2019 3y ago
The latter doesn’t have any dependencies or a build step though right? That’s a big win that can be easily overlooked. But it depends what you’re optimising for…
- eropple 3y ago
  I don't know many (any?) people who are greenfielding just-JavaScript, though. If you're using JavaScript in anger, you should probably be using TypeScript, and now you've got a build step regardless. Which is not a bad thing. Incremental builds have gotten much better and much easier to deal with.

slibhb 3y ago

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 3y ago
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.
dmix 3y ago
Modern JS frameworks are heavily mixing mostly static with limited amounts of interactive components but all in one system. Where everything can still be the same component architecture, the same UI systems, same CSS/JS packages, same build systems, etc but you selectively choose which components (or small sections of a page) are interactive and require hydration. I don't really see how Web components fill that picture as cleanly. You would basically still forced to choose between component overhead/custom code OR static HTML, creating a formal discintion rather than a boolean or flag or whatever. Why create that distinction just because it's "native" to the browser? The DOM is sufficient when your default is static and components are always SSR in the same DOM model. It basically only makes sense if you're not building a "holistic" single frontend framework driven site and rather are mixing various server side view systems and occasionally adding a couple components. Basically the sort of thing better suited for major legacy sites like Google rather than something you'd ever choose from the ground up.
no_wizard 3y ago
This is a half truth. Their are big problems with this approach, as I think a lot of folks are finding out the hard way, namely: - You cede rendering control from your framework to the web component, if it does anything like conditional children etc. meaning it can be hard to optimize or you get stuck using refs, which is suboptimal and in some frameworks makes optimizations hard to achieve - it’s de facto CSS in JS and to boot your styles are also locked to shadow dom. Yes I know this isn’t true in an absolute sense but in practice all the web component implementations leverage this. This makes styling harder, can have performance impacts etc. also means you can’t leverage CDN caching and distribution for your styles - FOUC is a real problem with web components as it exists today. - Interop varies and can have gotchas, especially with custom events that may be emitted by components - You can’t get fine grained optimizations in some frameworks using them because web components in practice often contain some kind of logic one way or another. - to use slot you must use shadow dom, and that means your app needs to be rendering against a shadow root of some sort, which can be real clunky

nektro 3y ago

good article except for the firefox shade

btreecat 3y ago
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/ 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.
- WorldMaker 3y ago
  Things like HTML (and JSON) imports in ES modules, among other things, have been waiting on some safety signalling mechanics currently named "Import Attributes". Import Attributes are currently in Stage 3 [0]. The basic security story is that browsers never care about file extensions, they care about MIME types. A developer might add an import to a third-party HTML or JSON file somewhere and expect one "safe" behavior, but the third-party could just return a MIME type of "text/javascript" and inject an entire script and the browser is supposed to respect that MIME type. To keep things safe, browsers want a way to signal that an import is supposed to JSON (or HTML or CSS) rather than JS and error if it gets back something "wrong" from a server request. That's one of the proposed uses for Import Attributes to suggest expected MIME types for non-JS modules in ES module imports. Unfortunately, there are other proposed uses for Import Attributes (things like including hashes for integrity checks) and so there have been quite a few revisions (and multiple names) for Import Attributes trying to best support as many of the proposed uses as possible, and that has slowed progress on it a lot more than some people would wish. [0] https://github.com/tc39/proposal-import-attributes https://github.com/tc39/proposal-import-attributes
  - btreecat 3y ago
    Thank you, interesting!
brianzelip 3y ago

Rodeoclash 3y ago

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).

qbasic_forever 3y ago
Web components are really only useful for stuff that's dynamic, like a sortable table that fetches data from an AJAX request. They require javascript and have no fallback or graceful degradation in functionality at all, which means using web components for all your bog standard buttons, text content, headers, etc. could be a very bad idea (not to mention it would trash the SEO and potentially accessibility of your site). IMHO you probably want to look at design tokens or other ways to centralize your visual styles--it's really more of a workflow problem and not just something to throw more javascript at with web components.
- throwawaymaths 3y ago
  > we'd like to have a shared set visual components between them I think what gp wants is css!
  - Rodeoclash 3y ago
    Well, ideally css which belongs to the component that is using it. CSS modules and other encapsulation techniques have been pretty beneficial. I'd like to keep that going vs. trying to manage the "cascading" part of stylesheets over multiple sites.
- verisimilidude 3y ago
  > They require javascript and have no fallback or graceful degradation in functionality at all This is false. Use <template> and <slot>. First-class progressive enhancement.

dxchester 3y ago

The main reason is that they're too low-level to use directly. They do a lot, but stop just short of being useful without something of a framework on top. I tried hard to use them directly, but found that it was untenable without sensible template interpolation, and without helpers for event binding. Here's my shot at the smallest possible "framework" atop Web Components that make them workable (and even enjoyable) as an application developer: https://github.com/dchester/yhtml https://github.com/dchester/yhtml It's just ~10 SLOC, admittedly dense, but which make a world of difference in terms of usability. With that in place, now you can write markup in a style not too dissimilar from React or Vue, like... <button @click="increment">${this.count}</button> Whereas without, you need to bind your own events and manage your own template interpolation with sanitizing, handling conditionals, loops, and all the rest. If we could get something in this direction adopted into the spec, it would open up a lot of use cases for Web Components that it just can't address as-is.

throwaway14356 3y ago
meanwhile Im like... <button onclick="innerHTML++">1</button>
- deleted 3y ago
  [deleted]
- jagged-chisel 3y ago
  GP comment shows a simple example, sure. And obviously it’s overkill just to implement incrementing a displayed value. But trivializing the example doesn’t reduce the “framework” to being pointless.
- LudwigNagasena 3y ago
  Meanwhile I’m like… That’s a Content Security Policy violation.
  - throwaway14356 3y ago
    2 men are having lunch, one complaints that he always has cheese on his sandwiches. The other says, just ask your wife for something else? He responds: I always make it myself. Content-Security-Policy: script-src 'self'; script-src-attr 'unsafe-hashes' 'sha256-9lIp1merGZMC6sfoM+OcgpSSRJJr18teLzyFangr0FY='

herpdyderp 3y ago

I've been using web components now for years and I will do everything I can to never write frontends in anything else. I totally agree with point 2 though: the Polymer phase was very weird, but, as mentioned, https://lit.dev https://lit.dev is great and, imo, the perfect abstraction.

benatkin 3y ago
Lit seems functionally equivalent to Svelte. Might Lit only be better if you have a preference towards declaring classes? Perhaps tracing back to Backbone or React before hooks? Svelte supports custom elements: https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api
- spankalee 3y ago
  Lit uses standard languages, doesn't require a compiler, is faster, and is smaller as you amortize the library size over a collection of elements. Those are real differences.
  - benatkin 3y ago
    > uses standard languages, doesn't require a compiler It recommends a build step, but yes, you can use it without one. Also, TypeScript isn't a standard language. So if you're using .ts you may as well use .svelte. > is faster I don't know that Svelte has been benchmarked with custom elements. Either way it's plenty fast. > is smaller as you amortize the library size over a collection of elements That's kind of a funny thing to worry about. It has improved in Svelte 4, though. https://svelte.dev/blog/svelte-4 https://svelte.dev/blog/svelte-4 I also don't know that Lit is so small in practice. With Lit you get to use map and the ternary operator and all that jazz, like React. https://lit.dev/docs/templates/conditionals/ https://lit.dev/docs/templates/conditionals/
  - phpnode 3y ago
    When did @click and so on become part of HTML?
- 3y ago

benatkin 3y ago

The nice thing is that if you're using a library like Lit or Svelte, you won't have to bother with the web component API much at all. https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api https://lit.dev/ https://lit.dev/

afavour 3y ago

IMO the main reason more people aren’t using Web Components is because React doesn’t support them. Preact does it just fine so I have to assume it’s possible but simply not in the interests of the React team. React feels like the enterprise lock-in of 2020s development: if you use it you’re using it top to bottom and it’s very difficult to mix and match with other frameworks. It’s a shame.

coldtea 3y ago
Nobody (meaning very few) care for Web Components, React or not. Even in frameworks that do support them, they're just not widely used.
- afavour 3y ago
  Web Components are just an API, a means to an end. You might as easily say nobody cares for document.createElement() but it’s still used by underlying code all the time. If it were much easier to mix and match components that use different frameworks then people would be using web components whether they know it or not. But we’re in a React monoculture and React folks seem quite content with that.
  - wokwokwok 3y ago
    mm... Web components aren't 'an' api, it's a specific way of using a set of apis, and specifically requires you to use a set of templates in a way that frameworks (which looovvvveeee DSLs) won't accept. The other bits? shadow dom? Custom elements? eh. Those are things a framework will wrap happily enough if they see value in it. Maybe some already do? As you say, you'd never know... ...but those html templates will never fly. They're just crazy bad ergonomics and framework authors will never accept them. That's really the core of the issue; invoking components in your layout requires you to use some kind of layout template, and every framework does it differently. That's why cross framework css solutions (eg. tailwind) are massively successful, because they can be called easily by anyone regardless of the templating; the same is not... and, frankly, seems like it never will, be true of web components.
  - 3y ago

briantakita 3y ago

Astrojs recommends a great way to initialize & light-weight hydrate the UI using web components & custom tags. https://docs.astro.build/en/guides/client-side-scripts/#pass-frontmatter-variables-to-scripts https://docs.astro.build/en/guides/client-side-scripts/#pass...

inopinatus 3y ago

I'm not using them because WebKit (i.e. Apple), in a long-standing vendor pissing contest¹ they've tunnel-vision'd themselves into, still refuses²³ to implement the customized built-in elements⁴ part of the standard, without which the content model for HTML cannot be fully realized (e.g. custom elements inside a table), and to make matters worse, without offering a firm proposal or implementation of an equivalent alternative. (and this is something a polyfill can only partially bridge) [1] https://github.com/WICG/webcomponents/issues/509#issuecomment-222860736 https://github.com/WICG/webcomponents/issues/509#issuecommen... [2] https://bugs.webkit.org/show_bug.cgi?id=182671 https://bugs.webkit.org/show_bug.cgi?id=182671 [3] https://github.com/WebKit/standards-positions/issues/97 https://github.com/WebKit/standards-positions/issues/97 [4] https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-customized-builtin-example https://html.spec.whatwg.org/multipage/custom-elements.html#...

CharlesW 3y ago
An apparent polyfill, FWIW: https://github.com/WebReflection/custom-elements-builtin https://github.com/WebReflection/custom-elements-builtin
spankalee 3y ago
Web components are extremely useful even without customized built-ins. And Apple is open to alternatives.
- inopinatus 3y ago
  I don't disagree about the first part, but it is nevertheless the reason I'm not using them, since I have a very general use case (c.f. https://github.com/hotwired/turbo/pull/131 https://github.com/hotwired/turbo/pull/131). As for representing Apple's state of mind w.r.t. alternatives; they've had the better part of a decade to shit or get off the pot, so I don't hold a shred of vendor sympathy. In that context, "open to alternatives" just sounds like product manager code for "we have no ideas of our own" and "let's kick the can down the road as much as we possibly can". If anything riles me up, it's the disinterest in developing a substitute capability, and if Apple weren't a steward of the standard it'd matter far less. I'll compare & contrast Cisco's running battles over their own PoE vs the IEEE802.3 standards that they'd had a hand in developing; at least the vendor offered a concrete alternative.

riquito 3y ago

It's been a while, and overall I'd like them to succeed, but here are the first issues I remember. The fact that scoped elements are not yet part of the standard is quite a turn off. Every web component is global and the first one that uses a name wins. Even if you are not competing with third party libraries you will need to have multiple versions of your same component very soon to handle breaking changes. The string only passing is an headache when you'd like to pass object/functions to compare later on. The fact that some CSS properties can bleed in the shadow Dom, while others don't. To introduce them into an existing codebase you need support, and last time I checked the support from React was clunky

djbusby 3y ago
I've been able to piece-meal RiotJS components into an existing code base pretty easy. Tools like React, etc al, requires almost doing everything that way. RiotJS fits in for adding a bit to "old-school" web-apps (PHP, Ruby, Perl, ASP3). Legacy backend, slightly more modern frontend.

deleted 3y ago

[deleted]

yCombLinks 3y ago

Web components don't solve any of the problems day-to-day devs ACTUALLY care about.

foderking 3y ago
which are?
- yCombLinks 3y ago
  Shipping features and bug fixes without a headache
mock-possum 3y ago
Encapsulation and ease of reusability / configuration? Just as an example - a widget to manage a list of number ranges. Build it up like a form element - it provides a value prop with the type ‘[number,number][]’ You need to display the current collection of min/max pairs, and add / remove / edit the collection - it’s essentially a mini CRUD component. There is no default html element that provides this functionality - you need an ordered list of pairs of number inputs, a confirm changes button, a ‘add new’ and ‘remove this entry’ button - you need a whole collection of stuff to provide the functionality. But once you’ve got it all worked out, wrap it in a web component and you can use it in 8 different places across your admin tool - ‘<ranges-picker />’ and boom, you’re ready to go. Using web components to define a library of common interface elements works just fine.
- yCombLinks 3y ago
  Right, but react solves the problem as well with similar amount of effort, but everyone is already on react. So switching is cost with little perceived benefits

alserio 3y ago

I've found them really useful to do microfrontends

spankalee 3y ago

Web components are doing really well: they're used on > 18% of Chrome page views, huge apps like Photoshop, parts of Chrome, Chrome OS, and Firefox, more and more of Reddit, and tons of design systems are built with them, and Lit has far more weekly npm downloads than Svelte or Solid.

pard68 3y ago
We're a fairly large , publicly traded org that no one has ever heard of but almost everyone interacts with our products. All our frontend products are entirely web-components (Lit). I like them. Used stencil before this at another job and it was also just fine.

shams93 3y ago

You used to need a whole js build system because old browsers were still out there. With the death of IE11 and the death of non blink Edge, basically every current browser finally supports the full api. But this happened when functional js is the big thing and being class based the custom element api isn't as popular as it should be.

jchw 3y ago

I think Web Components added a lot of complexity to the web platform again and we're finally hitting the breaking point where it has gotten to be too much. I don't want to deal with web components or the shadow DOM. I don't want more abstractions in the browser at this point. On one hand, there are some use cases for this new complexity. On the other hand, it's difficult to see how the vast majority of say, React users, would ever benefit from this complexity, given that a lot of them don't seem to have problems that are solved by web components. If we were going to focus on adding even more new browser features, I think it'd be better to focus on stuff that helps close cross-site scripting vulnerabilities, or provide better approaches towards anti-SPAM/anti-abuse than lazy, harmful remote attestation. (I mean hell, I'd love to see some very basic hashcash functionality as part of the browser; Personally, I think that would be an interesting idea for anti-SPAM, and nowhere near as catastrophically harmful as WEI.)

Falkon1313 3y ago
I would agree and would rather they had spent more effort on adding support via standard HTML5 elements for more of the standard native form widgets like comboboxes, tree controls, grid controls, etc. - all those things that already exist on almost every platform but keep having to be reinvented in javascript for no good reason. Web Components mostly seem to be just adding complexity for the sake of avoiding simplicity. Certainly there could be some use for custom ones, just as you can make custom native widgets. But there shouldn't be that much need that often if more of the standard functionality was available (and standard). They did add color picker, date picker, range, and the datalist to kind of sort of emulate a combobox, so some credit for that. But unfortunately they're not consistent across browsers and may or may not be consistent with the native platform.

deleted 3y ago

[deleted]

taeric 3y ago

This article doesn't really follow the title? I was expecting some critique of existing software and why someone prefers alternatives. Instead, I got a list of excuses on why people haven't really looked at it. Not that any of the points are bad. As read, they all seem like solid reasons to not use something. Indeed, the fact that frameworks have no reason to use these over user space constructs seems very compelling, all on its own. The rest feels like a thinly veiled rewording of the second point? That is, this feels like advocacy that is blaming the messengers for not successfully convincing us that we should use this superior thing. Which... is still a heavy handed advocacy. :(

kerkeslager 3y ago

Frankly, web components aren't great. I am using them, because I've landed in a few projects where adding a JS build step is too heavyweight for very minimal JS needs. But here are my gripes: 1. Templates are way too complicated to be useful. I have no idea what they were thinking here. 2. The shadow DOM not inheriting styles means I effectively can't use the shadow DOM for anything useful. My ideal use case would be that I could child elements to the current component into the shadow DOM. This allows me to do (for example) things like have a <tab-area> where the user can define <tab-> child elements which in turn can contain arbitrary content: when the user selects a tab I copy the contents of the <tab-> tag into the shadow DOM so that that's what becomes visible. But if I do that, the element content becomes unstyled. There are a bunch of really useful elements that are just completely blocked by this poor design choice. As a result, I just don't use the shadow DOM, but then I have to mutate the tabs to make them visible in place, and that means changes to the HTML of tabs can potentially cause issues for my <tab-area> and vice versa. The first is a missed opportunity, but it's fairly easy to just not use them. The second problem is one of the worst API decisions I've ever seen, which would have been detected very quickly if anyone designing this API had been arsed to try to use their own API.

jacob019 3y ago
The shadow DOM can inherit styles if you specify the styles that you want to inherit. Additionally, web components work just fine without the shadow DOM, it's optional, but for a great many custom elements you don't want them inheriting all the styles, because that can break the custom element.
- vanake 3y ago
  probably what GP meant there is now way to inherit styles without specifing which styles you want to inherit. There should option shadow dom inherit all styles.
- webstrand 3y ago
  Without the shadow dom, though, what really is the difference from just using `<div>` elements? You can't use slots, you're vulnerable to bad `querySelector`s, events aren't isolated, and you get none of the performance benefits. I've tried to find a workable solution using style inheritance, but it doesn't work everywhere. On code sandbox sites like codepen.io, the stylesheet is generated for you and sometimes updated in-place. You'd have to watch with a MutationObserver and then propagate the change to every instance of a custom element on the page.

synergy20 3y ago

Because react.js, vue.js, angular all had their own version of components and they're the 'mainstream' frontend frameworks.

raggi 3y ago

I use custom elements directly in a bunch of stuff I had roll and I find the composition and reuse advantage nice. I tend to not bother with template elements, they don’t help much. I also don’t bother with shadow dom or element styles, as again, until you are making a mess with a distributed team you don’t actually have css problems. css also got a lot better at not causing problems, with fancier selectors and less problematic layout models. People say they’re slow, but things I’ve hand rolled this way, while none are super complex, I can make thousands of elements and not put a dent in any metrics or lighthouse runs. I tend to bind stuff I’m going to manipulate in the child tree to variables in the constructor, so I never really have the cost of constant lookups, which maybe amortizes well once you’re looking at whole program performance.

ilaksh 3y ago

There doesn't need to be a practical reason for something to not be popular. Popularity and merit are not the same thing. Web components aren't popular because they haven't become popular yet. There is a lack of sufficient network effect moving in that direction. Once they start becoming popular, the issues with them (which are relatively minor) will be resolved quickly and improvements added. Why are most of our cities and cars still designed with fundamentals basically the same as in the 1930s? Not because there aren't better designs. It's just momentum. High technology is like that still even though nothing physical needs to be changed. Humans are herd animals. And the rationalization for behavior comes after the behavior not before. We subconsciously copy what other people are doing. People use React or whatever flavor-of-the-month. Give it a couple of years and many of the flavor-of-the-month frameworks will probably be built on top of web components.

sbergot 3y ago
The design of cars has evolved a lot, mainly because of security regulations. Cities is another topic. They change slowly because of the required investment but in europe at least there is definitely a trend toward walkable blocks which changes a lot of urbanisation guidelines. I agree with your first sentence: things are unpopular by default. However I disagree with your assumption: web components won't become magically popular overtime without a good reason for them to be used over all the other options. Your "flavor-of-the-month" take ignores the fact that react is now 10 years old and is boring tech. It is still one of the most widely used frontend framework.

bastawhiz 3y ago

My hot take: they're a pain in the ass to use for very much. Compared to frameworks in userland, they're cumbersome and don't add value. Frameworks make other things better (besides the problems web components solve), making web components an implementation detail. If you're using React, you have no reason to consider web components. In my entire career, I've had one use case that web components were perfect for: framework agnostic component interfaces. I specced the use case for a product at Stripe [0] and it was wildly successful. What it solved was avoiding the need to ship a library for each framework to embed our components: you just used HTML. Web components are perfect for this, because they are the lowest common denominator that everyone supports. Even if you're not using a framework, you can still embed the components with no real effort. That's the best I can say about web components, though. [0] https://stripe.com/docs/connect/get-started-connect-embedded-components https://stripe.com/docs/connect/get-started-connect-embedded...

dmazzoni 3y ago

Web components have had accessibility gaps since the beginning. I spent years working on specs and implementations to close the gap, It's insanely frustrating just how slow standardization work can be. I'm partially relieved that web components never became that popular, because that would have made accessibility on the web worse.

kermire 3y ago

The main limitation of web components for me is that all data needs to be passed to the component attributes as strings. Wish we could pass objects and arrays without JSON.stringify-ing them.

_xivi 3y ago

I heard about web components a lot for years and was looking forward for an opportunity to try them. But for some reason, this is the first time I learn that it's completely reliant on JS. My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way. Instead, turns out it's doubling down on JS to create elements, and was actually targeted towards these framework in the first place.

zelphirkalt 3y ago
If I recall correctly, there was or is a web component concept or inplementation that does not originate frome those frameworks and I think I read about it on MDN or so. It is only that frontend devs push their frameworks so much, that most people associate web components with React and similar frameworks.
reustle 3y ago
> My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way. Curious what you feel defining a custom component in the browser would look like, if not with JS?
- _xivi 3y ago
  Well, my impression was that it's a revolutionary hot technology that only recent browsers support. Something like the browser doing the "SSR" natively on the fly before rendering the page DOM. Anyway like I mentioned, I didn't get the chance to play with it and understand its purpose. Misconception -> higher expectations -> disappointment.
xtracto 3y ago
I read about web components a couple of years ago. What excited me was the prospect of having libraries of ready made UI elements that I could use. Those of us who programmed in say VB6 or .NET winforms back in the day may remember that you could purchase some "ready made" grid-table editor with lots of functionality and pretty. But I haven't seen that open source nor commercial. It's amazing how much the current web frontend dev have to reinvent over and over again.

fidgitkid 3y ago

[dead]

cientifico 3y ago

Google teached me over the years that they can deprecate or remove support from one day to another, and I don't matter to them, neither as user, developer, or company owner. So even if I love web components since it got released (and have used them in some toy apps) I can't count on them yet thanks to Google. You can't trust anything coming from Google. There is no assurance that they announce tomorrow that they remove support for them in chrome. Or even worse, they will remove support in 6 month (killing all the developers market and destroying any production app). To announce in 3 years that they will continue the effort of removing them... It's just sad. </Rant>

epolanski 3y ago

My experience why I use them less than I wish I did: they are really not plug and play in any website. There's plenty of css properties that pierce through the shadow dom.

zoom6628 3y ago

Too little too late. My bet is WASM being the Great Leap Forward because everything else that has been done in JavaScript is just layer on layer of abstraction, obfuscation and horrendous complexity. I would rather develop in a mature language and have that transpiled to WASM rather than fight the frameworks (I still remember when Angula 5 was a 15,000 file desktop mom install !). JavaScript has fulfilled an important role as the COBOL of the web. Low barrier to entry - anybody can do something useful without education or expense. Now the web needs move forward to become the first choice desktop. That will take tools that can really do the whole stack, like C, Go, Java, Zig, Virgil productively. Industry has been busy on the JS bandwagon and adding vast amounts of complexity to browsers and web infrastructure when maybe (happy for opinions to be voiced on this) we should be just adding more language runtimes to browsers.

styren 3y ago
How would WASM alleviate any of the issues that has led to complex frameworks in JS-land?

nathias 3y ago

I am currently in a process of rewriting the most monstrous frontend I've ever seen, it's written in Lit and web components. I don't recommend them to anyone, they are a relic and have failed to achieve their purpose, as now any code written in any of the popular frontend frameworks is much more interchangable than web components....

globalise83 3y ago

If you haven't tried Stencil.js, might be worth giving it a go. I found it a dream for working with web components since it takes care of almost all the tooling, bundling, code-splitting, etc. out of the box, and has full support for Typescript, TSX and React-style props.

sneas 3y ago

Four years ago, I found a small niche for a tiny project. Not that there were no solutions yet, but all the existing solutions lacked accessibility aspects, so I decided to develop my own, introducing the accessibility flavor [0]. The scope and limitations I had: - Should be framework-agnostic - Should require the minimum effort in installing - Should not conflict with anything on the page So, Web Component was the perfect candidate for the lib. The framework-less approach felt overwhelming, and lit-html smelled like Polymer. So, initially, I picked up Stencil. It is still fantastic for creating component libraries, but it happened to be overkill for a tiny component. So in a few years, I rewrote my WC without Stencil, and now it feels just right. I developed several more Web Components professionally in the past few years. I saw them as a perfect fit for the problems I had to solve. The scopes of problems were similar: - Should be framework-agnostic - Should require the minimum effort in installing - Should not conflict with anything on the page [0] https://github.com/sneas/img-comparison-slider https://github.com/sneas/img-comparison-slider

incrudible 3y ago

"Web Components are slow. The last thing that’s held Web Components back is that they’re slow… slow, like brisket I like to say. Slow isn’t always a bad thing." Yes it is, it is always a bad thing. It's not necessarily a dealbreaker, but it's never good or even neutral. I already have a mental model of the incredibly slow DOM, I don't need another dimension of performance cliffs to think about. Instead of more convoluted web standards, I want fewer, simpler and faster APIs - and may the best abstractions win.

reverseblade2 3y ago

Built with lit web components, and F# no shadow root https://funpizzashop.azurewebsites.net/ https://funpizzashop.azurewebsites.net/ Source: https://github.com/OnurGumus/FunPizzaShop https://github.com/OnurGumus/FunPizzaShop

nmalaguti 3y ago

> Kill Firefox before they could kill HTML Imports I’m not sure I understand the hostility here. Isn’t the point of the web to be open standards that reach consensus?

tsp 3y ago

I used Lit in a client project, which still seems to be the most common way to author web components. Styling and composition was really hard, much harder than in typical React, Vue or Svelte projects. It is future proof to build the atoms of a design system as web components (e.g. sliders, buttons and so on), but component composition is better done in a proper framework (e.g. Vue). This way companies could more easily start new projects with their existing design system, independent of the framework. I wouldn’t consider building a complex applications with Lit again, just the design system atoms.

dannye 3y ago

<textarea> <input> <video> ARE all Web Components, and have been for many moons so Browser vendors could implement their own UI. So everyone using a Browser *IS* using Web Components. It just took some years for the technology to be opened up with the Custom Elements API to us mortals here in Userland.