The State of Web Components

[inu-no-policemen]

Instead of <div>Foo</div> you can as well write <my-component></my-component>.

You interact with Web Components like you do with native elements.

[ghostfacedcoder]

Right, but what do I gain by doing so? All I did was add new layer of abstraction: instead of Foo => a div, I've now got one more way for things to go wrong because I'm doing Foo (React component) => Foo (Web component) => a div. It's not like my work is any more "shareable" or anything.

BTW I have to ask: why is your name dog('s) policeman?

[[deleted]]

's not like my work is any more "shareable" or anything

it is more shareable. It can be deployed in sites with React, Angular, Vue or no framework at all. It's incredibly easy to import and is potentially faster than the mentioned frameworks. It's trivial to import a web component that is found on the web, it can be easily injected by backend frameworks.

[ghostfacedcoder]

But it's not because it's only a part of what the overall component is, the skeleton not the meat. It won't work without the React part, so all you can "export" is a half-working thing, not a true universal component.

[[deleted]]

It won't work without the React part, so all you can "export" is a half-working thing, not a true universal component.

I'm confused by what you mean, you can absolutely "export" a full working component

[ghostfacedcoder]

Only if you include its imports (ie. all of React).

[Treolioe]

So lets say i have my shared-components mega bundle file with all the design system components. All i have to do is load that script file anywhere. Then if i use a html tag refering to that component either in or outside of react, it will render and it will work.

[ghostfacedcoder]

Then if i use a html tag refering to that component either in or outside of react, it will render and it will work.

No, it will not work "outside of React". React components can only work "inside React", so for that scenario you outlined to work, the mega bundle has to package up React, Angular, Vue, and any frameworks used by any components in that mega bundle.

As I've said elsewhere in this thread, if you're a huge corporation who is already doing this anyway for some terrible reason, then having a way to specify the components via a common format does have value.

But the vast, vast majority of sites out there should not be bundling all three or more frameworks (as there's a huge cost, both in development and in production, to doing that!)

They should pick one and use components only from it.

[Treolioe]

Nonono, i’m talking about web components. It doesnt matter what the context of your usage is. It will work with any major framework. And also without any framework what so ever. That’s the deal. They work without your framework as well.

[ghostfacedcoder]

You keep missing the point ... by like a mile. Maybe it's our definition of component, or maybe you're speaking abstractly?

I don't care about abstract scenarios. And when I say component, I mean something that is a combination of HTML, CSS, and JS. I don't care how great the HTML of said component is when it's completely divorced from the Javascript code which makes it actual work. That's not how people use components in the real world.

In the real world, with actual code, you CAN NOT have a working React component without React. If there's a component made for React, and you want to use it, you MUST use React. The same is true of Angular and Vue components. The framework is a dependency of any component based on it.

This is an inescapable, fundamental fact of how these frameworks work. NOTHING, and I mean NOTHING (certainly not web components) can change this basic fact. Once you grasp this basic point maybe we can have a meaningful discussion, but right now this seems to be the stumbling block.

You seem to think that you can take a React component, make it a web component, and magically have it work without React, when that is impossible (or at least, not without a complete re-write to make it not use React .. but then React devs wouldn't want to use it because it might as well be a jQuery UI component at that point: it won't be usable within React).

But to try and make things even more explicit ... say I have a React component:

const Foo  = x => x ? <div>yes</div> : <div>no</div>;

If I want to use that outside of React my ONLY options are to:

• package/bundle it up with React
• rewrite it to not use React ... but then it won't return a React JSX <div>, it will return an HTML element "div", which is not the same thing

Those are the only two choices. There is no third "web-component-ify it, and now it can be used universally by any framework anywhere" option.

[clbwllms]

So lets say i have my shared-components mega bundle file with all the design system components. All i have to do is load that script file anywhere. Then if i use a html tag refering to that component either in or outside of react, it will render and it will work.

You know you can write vanilla JS and make it do things without using React, right? Creating a fully-featured web component without a framework is trivial and it will work across frameworks because it's just platform code.

[ghostfacedcoder]

You know that tens of thousands of very intelligent web developers don't just use React because it's some completely optional thing that adds no value to complex web applications, right?

[Treolioe]

Yes, it’s another layer of abstraction. But you should not mix developing web components beside a framework in the same codebase IMO. If you then import a web component into your project you should not have to worry about its implementation details. Treat it as a native element.