I think you're approaching web components from the wrong perspective. They are not yet complete and as such are not yet suited for architecting a vanilla application. They are, however, very useful in small, reusable cross-framework libraries.
I'll address each of your points:
How much progressive enhancement do you need when the app's JS is either not available (disabled) or still being downloaded? I think that CSS' :defined pseudo-class is sufficient for styling the light tree of an element that has—or will have—a shadowRoot. You can also use a fallback design such as <select is="super-list">.
What "problems" does ::part() have?
Um, yeah, let's not move the web platform forward. Drivel.
No one said that you should use web components for a project that supports IE9/etc. You'd have a ton of polyfills already for that target and probably terribly outdated CSS practices if not using terrible CSS polyfills.
Using existing web components today would still require some form of a wrapper to nicely handle data wiring, and with that, you'd probably have something to handle templating. In which case, this point is a non-issue.
You don't have to write components this way, but it is nice and complete to be consistent with standard elements. See my thoughts at the very top of this comment.
Maybe it will support private methods when that proposal is stage 4. Not a big deal.
See my thoughts at the very top of this comment.
I can see how this could be an issue for architecting an application. However, see my thoughts at the very top of this comment.
They're solved with tools that are not part of an official specification which serves the entire web community. Such frameworks serve opinionated sub-communities. The web component specification has always been taking the best ideas from these frameworks and will continue to do so until we no longer need any of them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think you're approaching web components from the wrong perspective. They are not yet complete and as such are not yet suited for architecting a vanilla application. They are, however, very useful in small, reusable cross-framework libraries.
I'll address each of your points:
How much progressive enhancement do you need when the app's JS is either not available (disabled) or still being downloaded? I think that CSS'
:definedpseudo-class is sufficient for styling the light tree of an element that has—or will have—ashadowRoot. You can also use a fallback design such as<select is="super-list">.What "problems" does
::part()have?Um, yeah, let's not move the web platform forward. Drivel.
No one said that you should use web components for a project that supports IE9/etc. You'd have a ton of polyfills already for that target and probably terribly outdated CSS practices if not using terrible CSS polyfills.
Using existing web components today would still require some form of a wrapper to nicely handle data wiring, and with that, you'd probably have something to handle templating. In which case, this point is a non-issue.
You don't have to write components this way, but it is nice and complete to be consistent with standard elements. See my thoughts at the very top of this comment.
Maybe it will support private methods when that proposal is stage 4. Not a big deal.
See my thoughts at the very top of this comment.
I can see how this could be an issue for architecting an application. However, see my thoughts at the very top of this comment.
They're solved with tools that are not part of an official specification which serves the entire web community. Such frameworks serve opinionated sub-communities. The web component specification has always been taking the best ideas from these frameworks and will continue to do so until we no longer need any of them.