Discussion on: So, Don't Overreact But... I'm So Over React

[Andrew Bone]

React and web components answer slightly different questions. There certainly has been some blurring of lines over the years.

I'd agree that there is merit in creating reusable gui elements as web components to allow them to work everywhere but I struggle to see any real benefit beyond that.

• You still need JS to load the components
• Encapsulation of app logic is a nono, leading to more complex pages (and more prop drilling).
• With the shadow dom you can't, easily, style from outside leading to multiple variants of the same component.

I really liked web components when they were new and even built a few polymer apps but I just found myself using them less and less and they weren't that useful in practice.

[Danny Engelman]

👎 You still need JS to load the components

🎯 DSD - Declaractive shadowDOM creates Components without JS

👎Encapsulation of app logic is a nono, leading to more complex pages (and more prop drilling).

🎯 Its just POJ (plain old javascript) add any state management library you need

👎With the shadow dom you can't, easily, style from outside leading to multiple variants of the same component.

🎯 RTFM:

1. CSS properties
2. constructed stylesheets
3. ::part and exportparts

[Andrew Bone]

Thanks for your response but none of these really answer my concerns.

Declaractive shadowDOM is no better than just using HTML, you can't have any interactivity, why add the complexity?

The just use JS argument is a little odd, as you can just use React, Preact, Angular or whatever you like, why add the complexity?

Your response to the styling from outside is complex is here are the complex methods you can use to style it from outside.

Whilst I don't have an issue with web components they rarely seem worth the effort (even if they effort really isn't that great).

[Besworks]

why add the complexity?

Encapsulation.

Shadow DOM is not at all required but solves a litany of issues that have plagued the web for years. Personally I think div soup is disgusting and CSS frameworks like bootstrap and it's derivatives were a step backwards.

External styling does not need to be complicated. When designed properly, a Custom Element is just as easy to style as any native element. With CSS you can target the custom element and it's slotted descendants just like any built in element.

your-custom-element.your-class { ... }
your-custom-element > button { ... }

And within your Shadow DOM you can modify internal styles based on the state of the :host.

:host(.your-class) { ... }
:host(.your-class) header { ... }
:host(:not([disabled])) ::slotted(button) { ... }

It's simple, elegant and effective.

[Martin Ledoux]

As for your bullet about prop drilling, I was thinking that you could still make web components that use some sort of state management - just not a State Management library tied to a specific framework like Angular's NgRx. However, at that point you have undermined the portability promise. I suppose you could make plenty of reusable components not tied to such a library (like your own input component or color picker, etc), but if you're using web components to make pages, those would have to be tied to app logic and would not be reusable across other apps and even frameworks. Basically the primitive components would be reusable, but the app specific ones would not.

Point being, you could probably avoid using a framework and use popular patterns found in various frameworks such as dependency, injection, State Management, services, etc - but you would have to be careful to separate your portable web components from the project-specific ones.

[Besworks]

Exactly, state management is a job for the app itself not the components it's built from. You don't expect a form field to manage it's own state beyond the specific features that it provides. You wrap extra logic around it to suit your specific use case then you wrap an app around that. Simple separation of concerns.

[Andrew Bone]

React is a state management library that happens to be able to supply dom elements (with react dom) I think you're more fight against bad react usage rather than react as a whole.

[Besworks]

Actually, I would argue against any bad usage of web technologies regardless of the library or framework involved. The core Web APIs provide a finely-tuned, meticulously-documented, consensus-based framework without the need for any additional libraries.

Browsers are perfectly capable of maintaining state through Session Storage, Local Storage, IndexedDB, cookies, bfcache, and service workers (anything I missed?) each with their own specific use cases. And because of the open nature of the web you can NEVER trust the client anyway, so the one and only true state should be that held by the server itself. With Web Sockets this can be synced in real time to the client. I don't see why a third-party state management solution would ever be necessary.

[Andrew Bone]

100% you can use what ever you want to handle state but it raises the question what wins do the effort of using web components (as opposed to just straight up HTML) get you.

[Besworks]

Custom Elements === HTML Elements

That is the true benefit. They are not opposed to straight up HTML they are a direct extension of it.

[Besworks]

You still need JS to load the components

Actually, that is not entirely true. You can create custom elements through markup and css alone. They will not have any complex logic but JS is not technically required.

Encapsulation of app logic is a nono

Then don't encapsulate your app logic. The point of components is to abstract and encapsulate the parts of your app that should be kept separate. You are building your app on top of the components—using them. Each component should only be responsible for it's specific behavior.

leading to more complex pages

A properly designed app built from web components is actually less complex. The extra complexity generally associated with web components is almost always a byproduct of using them wrong.

With the shadow dom you can't, easily, style from outside

But this is exactly the point of Shadow DOM. To encapsulate your styles away from the host page so that they don't get clobbered by page's CSS or that of another library or component. A properly designed custom element has only bare-bones structure and styling similar to that of a native element that can overridden by standard CSS.

[Andrew Bone]

Actually, that is not entirely true. You can create custom elements through markup and css alone. They will not have any complex logic but JS is not technically required.

I jest I truly didn't know how far creating components without JS had come but I still don't think it's good enough, I'd much rather just have raw HTML/CSS.

Then don't encapsulate your app logic. The point of components is to abstract and encapsulate the parts of your app that should be kept separate. You are building your app on top of the components—using them. Each component should only be responsible for it's specific behavior.

You could imagine having a component that loads in some data, having a loading state until the data is loaded, show the data and then allows you to modify the data again with a loading state as it saves.

This component doesn't need separating as it's all one concern, the form data (or whatever), but to make this work with web components I'd have to jump through some hoops, again not the end of the world but it feels like an extra layer of complexity.

A properly designed app built from web components is actually less complex. The extra complexity generally associated with web components is almost always a byproduct of using them wrong.

OK, that feels like the answer of someone that doesn't have to work in teams of varying skill very often but perhaps it really is that simple 😊

But this is exactly the point of Shadow DOM. To encapsulate your styles away from the host page so that they don't get clobbered by the host page CSS or that of another library or component. A properly designed custom element has only bare-bones structure and styling similar to that of native element that can overridden by standard CSS.

A properly designed app built with CSS in mind doesn't need styles encap.... 😀

I personally use CSS modules to prevent clashes but I know that means a build step which you might want to avoid

---

I should probably say I'm not again web components and think everything has its place and every dev has their preferred way of working. For me the simplicity of react handling state and handling render based on that state allows me to work quicker without having to worry about all that. Sure there are foot gun and misuses of the platform but I'm sure that's true with all app building methodology.

[Besworks]

Using Custom Elements in your project actually helps in a team of varying skill. Because someone with the knowledge to solve a particular problem can do so and share that with the team in the form of an easy to use component. The user of the component only needs to know basic HTML and CSS.

Encapsulation is important because not all apps are built in a homogeneous ecosystem. Polluting the global scope has long since been considered a bad practice in the JS world. Shadow DOM further enforces this and extends the ability to CSS to ensure that third-party libraries or even the work of your own team don't clash. Sure this can be mitigated with careful CSS scoping but you can never be guaranteed that your nicely designed widget won't break some day because of careless changes outside of your control. Why risk it when this problem can be completely avoided?