Hacker News Reader

Comment by winterthedeep | Hacker News Reader

I worked with Polymer-based components ~2 years ago (an eternity in frontend-land), and I want to share my biggest pain point: you may want to integrate a `<cool-carousel>`, but it does not "look right" in your design (eg white website, but the carousel has a black background). If the author did not set up CSS variables, you have to either try overriding stuff, or fork it. This problem is why every organization (eg GE with Predix or Electronic Arts) had to create their own components, so they can share the same "art style"/design. Can you share your experience about that?

View on HN

No matter the underlying technology, "lightweight, truly reusable UI components" is almost an ideologic dream, at the web scale. (some companies might achieve it on their own scale with a lot of effort, but not sure for how many years)

As the maintainer, you don't want to cave in and add every possible configuration option people ask for so you have to decide what's a good, thin API for your component and it will never be enough for some usages. Styles are that much more subjective and even vary with design trends over the years!

It might be possible for very, very simple components like text inputs but then again, those are also the simplest to code directly in your framework, so you could wonder, why bother with an inferior programming paradigm in the first place?

The sweet spot for web components really seems tiny.

In the instance of Predix (I peripherally worked on that during my time at GE) and likely EA and every other large Web Component ecosystem you're thinking of, that's desired behavior. The real want is a design system such that things look consistent, but as design systems are CSS only, they aren't smart enough for interactions that require JS. So then the need for a design system becomes a need for components of some kind that include the design. You're looking for components with more adaptable design, but that's just not the intention of these ecosystems. If done with that goal, yes CSS vars take you a little bit of the way, but I think we'll see more power coming to help out soon with Shadow Parts/Theme, CSS Modules, and Scoped Stylesheets. But really, just styling a background? If the component author just left the background: none, you could do whatever you wanted from the outside. It just takes planning - even without the Shadow DOM you still need to plan for proper themeing.

"styling a background" is just an example - I admit it is a bad one (glad I don't work in frontend anymore). I will read about CSS Modules and the other stuff you mentioned. Thank you.

Sure thing! Those things are def up and coming, and I'll admit I haven't looked into them so much yet, but they are being designed to solve this very problem. I don't think that Web Components are the tool to solve every problem, but I've been a fan for a while (so much so that I'm writing a book)

As others have already answered styling into Components is still hard, but there are answers coming soon with part/theme and Scoped Stylesheets.

Also, ZephJS, the Web Components library I am championing, has the ability to inherit from another ZephJS element which allows one to add to or even completely replace the styles for the new element without any special css magic. So if I want to style <acme-text-field> I simply inherit from it in my new <my-text-field> and I can style however I want.

https://gist.github.com/arei/8083a6270e704b830c68a2020f3e5e3...

ZephJS looks cool, will try it soon. Thank you!

Web Components are an anti-pattern

Please expand on this point?

Reply on news.ycombinator.com