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 is great and, imo, the perfect abstraction.
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
If Web Components are so great, why am I not using them?
51–60 of 189 posts
Re: If Web Components are so great, why am I not using them?
#52Web components don't solve any of the problems day-to-day devs ACTUALLY care about.
Re: If Web Components are so great, why am I not using them?
#53I 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 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 si…
This is false. Use and . First-class progressive enhancement.
Re: If Web Components are so great, why am I not using them?
#54Web 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.
- 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
Re: If Web Components are so great, why am I not using them?
#55Earlier quoted context omitted.
Nobody (meaning very few) care for Web Components, React or not. Even in frameworks that do support them, they're just not widely used.
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.
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.
Re: If Web Components are so great, why am I not using them?
#56I'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 alt…
Re: If Web Components are so great, why am I not using them?
#57Earlier quoted context omitted.
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 and . However, many web component developers never learn this. The problem you’re describing is a training/marketing issue, as discussed in the post.
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.
Re: If Web Components are so great, why am I not using them?
#58Re: If Web Components are so great, why am I not using them?
#59Re: If Web Components are so great, why am I not using them?
#60I'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 alt…
Web components are extremely useful even without customized built-ins. And Apple is open to alternatives.
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.