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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Custom Elements === HTML Elements
That is the true benefit. They are not opposed to straight up HTML they are a direct extension of it.