Comment by pkukkapalli | Hacker News Reader

Comment by pkukkapalli | Hacker News Reader

Parent Full thread

Agree with this 100%. It's called Web Components since it's best used for writing individual components that be dropped into larger apps. I did a side project with LitElement recently, and just could not find the value add over React. That's when I realized that was never the intention anyways.

I think the desire to make Web Components a React competitor also comes in part from the movement towards 100% static sites, i.e. no server HTML generation. So if I'm building a shopping app, I would never create an HTML file with the following with proper declarative HTML:

<shop-app> <shop-item name="Nike Air Force 1" price="85" currency="dollars"></shop-item> <shop-item name="Nike Lebron 18" price="130" currency="dollars"></shop-item> <shop-item name="Nike Kobe 8" price="145" currency="dollars"></shop-item> </shop-app>

Then, you can add interactivity with JS events or a JS framework. Instead, you'll just see:

<shop-app></shop-app>

where the data to render the child elements is dependent on an AJAX request that gets the initial data. Creating standalone, declarative, and well-scoped components is just not necessary in this case, since everything is done in JS anyways.

My thoughts exactly. For some reason people tend to think that a web component should stand on its own from high level. But that's just not how HTML works. Something like <shop-app></shop-app> should be seen as an anti-pattern IMO.

I see web components as a compositional approach for dealing with complexity.

Something else that is extremely powerful that people seem to forget is that you can add a src attribute to your web component that links to JSON data, or HTML fragements on a server. It can give you a lot of caching and concurrency opportunities, browser engines are extremely efficient dealing with this. For most people an src attribute feels really obvious for an img tag, but apparently less so in other contexts.

In what way does <shop-app> not deal with complexity through composition? It is a component, composed of other components, which in turn are composed of further components.

At what arbitrary level of complexity should we stop composing?

At the level where the overhead from it exceeds the benefits of componentizing. It's a subjective judgment, sure, but that doesn't make it any less real.

In particular, if something is never going to be re-used, what's the point of componentizing it?

In some contexts, decomposition into easily workable scope of complexity.

As somone who builds large apps via web components, I couldn't disagree more.

I'm able to compose components into higher order screens and get an enormous amount of reusability across projects.

I have a set of components, screens, etc... that I've built up over time and I can mix and match them and whip out an app extraordinarily fast.

Additionally, there are some great design systems and component libraries like Ionic built on top that make this even easier.

I can write a component for a client, and they can use it anywhere in their ecosystem, regardless of technology.

Reply on news.ycombinator.com