Live data from Hacker News

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

daverupert.com

51–60 of 189 posts

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

#51

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

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.

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

#53

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 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…

> They require javascript and have no fallback or graceful degradation in functionality at all

This is false. Use and . First-class progressive enhancement.

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

#54
post #9

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.

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

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

#55
post #36
post #34

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

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.

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

#56

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 alt…

Web components are extremely useful even without customized built-ins. And Apple is open to alternatives.

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

#57
post #14

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

This is what everyone in userland clamors for as a baseline. Decade plus old arguments about this. I have little hope this will happen

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

#59
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.

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

#60

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 alt…

Web components are extremely useful even without customized built-ins. And Apple is open to alternatives.

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

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.

Post reply on HN