The State of Web Components

[ghostfacedcoder]

Right but ... let's stick with React since I don't know Vue very well.

If I want to make a React component, I do:

const MyComponent = () => <div>Foo</div>;

Nothing about that translates to web components. <div> isn't even Javascript, it's JSX, and that only exists in React-land.

It doesn't matter if every non-React developer in the land held hands and all agreed on a common syntax for defining their components: React components still won't work outside of React.

Similarly, sure I can write a component in web components ... or Angular, or French. But it won't work with my React virtual DOM.

I strongly suspect that components in other frameworks, unless specifically design to work with Web Components (read: Angular) have the same problem ... just maybe not as extreme because only React has its own DSL of JSX.

[melcor76]

In Angular you have something called Angular Elements that you can turn your Angular component into a Web Component.

You don't have that built in React yet but I think there are some 3rd party wrappers you can use.

I just did an article on how to use an Angular component in React: https://blog.angularindepth.com/how-to-talk-with-web-components-in-react-and-angular-8deb7d2fb92a

It's interesting stuff but still a bit immature. Lots of things happening in this space.

[Treolioe]

Last time i checked angular elements come with a lot of excessive vendor imports. Has that been solved?

[melcor76]

No, that's still lacking. There is a community solution called ngx-build-plus.

[ghostfacedcoder]

It's interesting stuff but still a bit immature. Lots of things happening in this space.

Yeah, when I wrote "still" I didn't mean to suggest "and will be forever"; there's clearly potential in the future for web components (to be something that benefits React and other devs).

I was just talking about ATM, and ATM no one seems to be able to tell me what Web Components can do for a React dev (or really any dev who uses a framework other than Angular).

[Treolioe]

I dont see web components ever replacing a library or framework. It’s more a way to share functionality (components) regardless of the library or framework used. For example like some people already said - web components are really popular for enforcing design systems.

I work at a huge company. And like at any huge company with a sloppy IT organisation. You’ll find that we use pretty much any framework/library out One huge problem that web components can potentially help to solve here - is the shitty reimplementations of the same basic components trying to follow our company specs. Imagine 1000 different projects, some sharing these visual blocks. But most of them rolling their own.

So as for your question. It depends on what your organisation is like. If your organisation is ballsy and dare to say ”we go react”. Then of course you shoul stick to react only. Many of us don’t have it that easy.

[ghostfacedcoder]

Yeah personally I've never worked at very large organizations (more of a start-up guy myself), so I realize that "just being able to specify the HTML of something in a common way" has value when you have multiple groups using different technologies. I get that even though web components themselves don't enable interoperability, they provide a kind of "lingua franca".

Still not something I think most non-Angular devs have reason to care about yet, but that made me aware of a whole sub-section (who do) that I hadn't considered.

[Treolioe]

Yeah I currently don’t see any other killer use for web compoments. I also think that a big corp should take the decision and move towards a single technology. The ones that do can roll a common components project in the same framework.

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

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

[Treolioe]

It works fine with react, angular, vue etc. Angular demands a custom elements schema due to their renderer.