Egalitarian. I enjoy the web, empowering people, creative problem solving. Once took a manager's bug and turned it into 7-14 million USD projected annual return.
Progressive enhancement
(any-thing tag)fall-back where needed(/any-thing tag)
use slots, etc for your range of business requirements
Css in, err... JS
FOUC is simply not true unless a solution did not deliver a working solution that addresses this specifically. Consider continuing to become familiar with the technology in the context of an actual business case. There are various ways to manage these issues, which are more relevant to actual solutions. If the target audience is so far legacy that the solution should use HTML without anything modern, including JavaScript, then by all means forego what is both contemporary and a long-term future for the web platform. However it calls into question why the article was written or relevant more generally.
Platform fatigue
Actual use of native Web Components does the opposite: reduces the body of knowledge to maintain and allows a focus on fundamentals. Further the platform is becoming more stable over time (years), not less. Simply look at the information for each browser as well as the MDN docs for any given specific or the platform overall.
Polyfills
I don't understand how using a polyfill is a problem to achieve parity with any framework, feature or otherwise in any actual project. Yes APIs change over time, they evolve, and are needed less and less over time. That's not a case against. There are iterations of React, Angular, etc. If anything it takes all the various moving targets and focuses them, resulting in less work. Less work is good.
Composition
Consider using a well designed and implemented component rather than a poorly implemented or designed component. It would lead to (at least in my experience) a better solution, less work which I personally see as desirable.
Confusion between props and attributes
No properties and attributes are not the same. This has been true a long time and am glad we can together discover the technology we're working with. If anything using native technology like Web Components helps address these common deficits and lack of knowledge. This is a helpful exercise toward discovery.
Leaky design
I don't understand how something "nebulous" or "weird" equates to "leaky". Help me out. It's a callback, not a setter. Please use the features and read the documentation (just Google: MDN attributeChangedCallback).
The DOM is bad
No the DOM is not bad, it's good and useful and performant. We should all use it directly instead of writing wrapping APIs that do it for us instead, at least until we know what we're doing. Not all the APIs are well designed or necessarily obvious without some work. One of the great thing about native technologies is that they have a more rigorous implementation path with higher standards and experience than simply: is good or is bad. This reveals flawed knowledge across this space. We all have things to learn, I certainly do.
Global namespace
So? The registry, parsing, etc are prior work and are entirely acceptable. We don't have some long-hand method for element instantiation: new window.EventTarget.Node.Element.HTMLElement.HTMLDivElement(). Custom elements continue all these patterns--it's how they're supposed to work.
These are all solved problems
Fine. If you don't want the modern iteration of a solution that's totally OK. Enjoy maintaining the various legacy abstractions, build processes perhaps, etc that come with that work.
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.
Progressive enhancement
(any-thing tag)fall-back where needed(/any-thing tag)
use slots, etc for your range of business requirements
Css in, err... JS
FOUC is simply not true unless a solution did not deliver a working solution that addresses this specifically. Consider continuing to become familiar with the technology in the context of an actual business case. There are various ways to manage these issues, which are more relevant to actual solutions. If the target audience is so far legacy that the solution should use HTML without anything modern, including JavaScript, then by all means forego what is both contemporary and a long-term future for the web platform. However it calls into question why the article was written or relevant more generally.
Platform fatigue
Actual use of native Web Components does the opposite: reduces the body of knowledge to maintain and allows a focus on fundamentals. Further the platform is becoming more stable over time (years), not less. Simply look at the information for each browser as well as the MDN docs for any given specific or the platform overall.
Polyfills
I don't understand how using a polyfill is a problem to achieve parity with any framework, feature or otherwise in any actual project. Yes APIs change over time, they evolve, and are needed less and less over time. That's not a case against. There are iterations of React, Angular, etc. If anything it takes all the various moving targets and focuses them, resulting in less work. Less work is good.
Composition
Consider using a well designed and implemented component rather than a poorly implemented or designed component. It would lead to (at least in my experience) a better solution, less work which I personally see as desirable.
Confusion between props and attributes
No properties and attributes are not the same. This has been true a long time and am glad we can together discover the technology we're working with. If anything using native technology like Web Components helps address these common deficits and lack of knowledge. This is a helpful exercise toward discovery.
Leaky design
I don't understand how something "nebulous" or "weird" equates to "leaky". Help me out. It's a callback, not a setter. Please use the features and read the documentation (just Google: MDN attributeChangedCallback).
The DOM is bad
No the DOM is not bad, it's good and useful and performant. We should all use it directly instead of writing wrapping APIs that do it for us instead, at least until we know what we're doing. Not all the APIs are well designed or necessarily obvious without some work. One of the great thing about native technologies is that they have a more rigorous implementation path with higher standards and experience than simply: is good or is bad. This reveals flawed knowledge across this space. We all have things to learn, I certainly do.
Global namespace
So? The registry, parsing, etc are prior work and are entirely acceptable. We don't have some long-hand method for element instantiation:
new window.EventTarget.Node.Element.HTMLElement.HTMLDivElement(). Custom elements continue all these patterns--it's how they're supposed to work.These are all solved problems
Fine. If you don't want the modern iteration of a solution that's totally OK. Enjoy maintaining the various legacy abstractions, build processes perhaps, etc that come with that work.