Live data from Hacker News

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

daverupert.com

131–140 of 189 posts

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

#131

Earlier quoted context omitted.

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.

> The shadow DOM can inherit styles if you specify the styles that you want to inherit. Ah yes, I've heard about this "mixing CSS into your HTML". The entire point of CSS is that you can write selectors that can affect anything, import it in the header, and you're done. If you're telling me I have to import a new CSS file (or repeat myself and import the same CSS file) inside of every custom element I create, obvious…

> Consider: if I'm distributing a library of web components, which of my users' CSS files that I know nothing about do I include?

If you are distributing a library of web components, wouldn't you provide a CSS api for the things that are supposed to be styleable via CSS custom properties and styleable parts?

Case in point: consider Shoelace.

> a completely useless non-solution

Consider the existing libraries of web components — Shoelace for something generic, RedHat's Patternfly or Adobe's Spectrum for something company-specific. How much of a non-solution are they, really?

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

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

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

#133

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

Thanks for sharing. Is there a non-golfed version of this that is understandable for grugbrained devs like me?

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

#134

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

You don't really need all that stuff. Sanitization is straight forward to implement and only required for user generated strings (since you want to make it HTML-safe). It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects.

As for events, binding is really very easy to do and it's already localised to the component so managing them is trivial.

Loops are also trivial; you can simply use Array.prototype.map function to return a bunch of strings which you can incorporate directly into the main component's template string. In any case, you can always use the native document.createElement and appendChild functions to create elements within the component and add them to its DOM or shadow DOM.

I've built some complex apps with plain HTMLElement as a base class for all my components and found is much simpler than React without any unexpected weirdness and using fewer abstract technical concepts. Code was much more readable and maintainable. I didn't even need a bundler thanks to modern async and defer attributes of script tags among others.

I think the reason why people are using React still is just marketing, hype and inertia. The job market which is gatekept by non-technical recruiters demands React. It's all non-tech people making the big decisions based on buzzwords that they don't understand.

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

#135
post #115

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

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

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.

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

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

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

#137

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

Template Instantiation is suppose to be the answer at least in part, but it’s been held up since 2017[0] The bigger problem is that the web platform stakeholders (IE the committees that industry influence and the browser makers) simply didn’t listen at all to what regular developers have been saying about what they want from the web platform w/r/t better built in platform provided primitives. It’s seems to me like we…

You don't need reactive data binding. You can simply watch for HTMLElement attribute changes and invoke a render method whenever that occurs. It helps to improve your app architecture if you do this. Reactive rendering can be a foot gun and often leads to unnecessary double or triple rendering. It's better to be able to control the rendering explicitly from a single binding which is exactly what HTMLElement offers; you just need to adhere to good architectural principles.

Many modern devs are too deeply involved in the React cult to see past its many over-engineered and flawed abstractions and struggle to see the simpler approach which necessitates adhering to some basic but highly beneficial architectural constraints.

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

#138

Earlier quoted context omitted.

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.

> The shadow DOM can inherit styles if you specify the styles that you want to inherit. Ah yes, I've heard about this "mixing CSS into your HTML". The entire point of CSS is that you can write selectors that can affect anything, import it in the header, and you're done. If you're telling me I have to import a new CSS file (or repeat myself and import the same CSS file) inside of every custom element I create, obvious…

> I'm telling you that's a terrible, awful idea, because it breaks the fundamental way CSS is supposed to work.

The "way CSS is supposed to work" was always a bad idea and is totally unworkable for large projects / teams. Throwing it out and simply inlining all your styles is absolutely the right call.

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

#139

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

You don't really need all that stuff. Sanitization is straight forward to implement and only required for user generated strings (since you want to make it HTML-safe). It could be argued that automatically sanitizing everything including already safe data types like numbers and system-generated content adds an unnecessary performance overhead for certain projects. As for events, binding is really very easy to do and…

Can you share an example?

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

#140

Earlier quoted context omitted.

Template Instantiation is suppose to be the answer at least in part, but it’s been held up since 2017[0] The bigger problem is that the web platform stakeholders (IE the committees that industry influence and the browser makers) simply didn’t listen at all to what regular developers have been saying about what they want from the web platform w/r/t better built in platform provided primitives. It’s seems to me like we…

You don't need reactive data binding. You can simply watch for HTMLElement attribute changes and invoke a render method whenever that occurs. It helps to improve your app architecture if you do this. Reactive rendering can be a foot gun and often leads to unnecessary double or triple rendering. It's better to be able to control the rendering explicitly from a single binding which is exactly what HTMLElement offers; y…

See that's weird, because the parent comments are about using in HTML template binding, and you seem to have suggested instead that a React-like render function model would be better, while simultaneously bashing React.

I am no fan of React, but this comment confuses me.

Post reply on HN